ARIN PPC at NANOG 62 Transcript - 07 October 2014 [Archived]

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

Opening and Announcements

John Curran: Okay. Good morning, everyone. Please come in and be settled. We’ll get started. I’m John Curran. I’m the president and CEO of ARIN. I’d like to welcome everyone to ARIN’s Public Policy Consultation at NANOG. We’re going to be considering quite a few policies today and having discussions to help guide the AC.

So there’s an open discussion of the Internet Number Resource policy held by ARIN for facilitated in‑person and remote participation. We facilitate this so that you, the community, can help develop policy.

It can be held at an ARIN Public Policy Meeting, we do one at every ARIN Public Policy Meeting, but also other forums such as NANOG as approved by the Board of Trustees.

I’d like to welcome our remote participants. Remote participants are equal participants in this process. They have access to all the materials, including webcasts, live transcript, a chat room. In the chat room, they can participate including in the show of hands for support. So it’s everyone in the room and remote participants in this process.

I’d like to remind everyone there’s no chair today. I’m actually our chair. Our ARIN chair and vice chair couldn’t be here. But I will make ‑‑ I will do the moderation of this to make sure that everyone can participate. When you come up to the microphone, please state your name and your affiliation and comply with the courtesies in your guide. You have a blue Discussion Guide with a large Baltimore crab at the front. Please, there’s rules and courtesies in that guide if you have questions.

At the head table is myself; John Sweeting, who is the chair of the ARIN Advisory Council; Daniel Alexander, AC vice chair; and our jabber volunteer, who is Andrew this time around.

Agenda. We’ll do a quick update on AC activities which John Sweeting will give. We’ll consider 10 Draft Policies. One of them is a Recommended Draft Policy. Recommended Draft Policies can be advanced to the Board of Trustees if they’re advanced by the community. This might be the last time you’ll see them. Realistically you’re likely to see this this week, but the fact is that a Recommended Draft Policy is a policy that potentially the AC has deemed suitable for adoption. It meets all the requirements.

The others are Draft Policies, which means the AC is looking for discussion to help refine the policy, make it more suitable, and that you will see it again, either at another PPC, such as this, or at a full ARIN meeting, one way or the other.

So with that I’d like to now have John Sweeting come up and we’ll give the AC update.

Update on Advisory Council Activities

John Sweeting: Good morning, everyone. Welcome to Baltimore. This is going to be the first time I see these slides so I’ll try to do my best. Einar, thank you very much for preparing them.

Okay. So the role of the Advisory Council in the Policy Development Process, charges us to go through the ‑‑ we’re the primary facilitators. We’re member elected. There’s 15 of us on the Advisory Council, five go up for election every year. There’s five spots and it’s a three‑year term.

The AC members here today: Dan Alexander, Kevin, Owen, Andrew, David, Scott, Heather, R.S., John Springer, and myself. Could you all just stand up. Tina is here as well.

So these are the people you want to find and talk to if you have any policy questions or opinions that you want heard by the AC.

As John pointed out, on our docket we have one Recommended Draft Policy. That means the AC has agreed and voted through to recommended the status, this policy. And what we’re looking for is confirmation from the community that, hey, yeah, this is a good policy, it needs to be put in place.

Right after the PPM, we have a meeting on Friday where our intent is to move this to last call and get the last call comments and then see what happens there as well as what we hear today and at the PPM on Thursday.

John Curran: Which one is that?

John Sweeting: That is 2014‑9. It’s taking the RSA and NRPM and kind of making them equal. It’s removing the words “aggregate” and “reclaim” from the NRPM, to put it in compliance or to make it compatible with the RSA.

We have nine Draft Policies. So for the Draft Policies the shepherds are going to come up and present them and be open with you guys and tell you: Hey, here’s what the AC has been thinking about these and here’s where we think we’re going with these, but we want to hear what your viewpoints are and if you think that’s the right direction or what we have to do to make them either good Draft Policies that will make it to recommended status or possibly it might be they need to be abandoned. We need to hear that.

And one proposal that just was submitted last week and we’ve just got shepherds assigned yesterday.

There is a policy breakout room that will be opened ‑‑ we have it all today? ‑‑ all day today. It is where?

Unidentified Speaker: If people want to come to (indiscernible).

John Sweeting: Okay. So if there’s people that want to discuss policy with the AC, then come and find me or any one of the ACs or Einar. We’ll get to that room and sit down and discuss policy. That’s it.

Let’s get into the meat of the meeting.

Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements

John Curran: Thank you, John. Okay. So let’s start going through these policies. And first one up is Recommended Draft Policy ARIN 2014‑9, which is Resolve Conflict Between RSA and 8.2 Utilization Requirements.

Now, this is a recommended draft. So I’m actually going to introduce it just so you have the history of it.

So Recommended Draft Policy 2014‑9 started out as a policy proposal. Anyone can submit policy proposals. It was submitted in January 2014. The AC assigned shepherds. These are AC members who specifically work on a policy proposal and help advance it through the process, work with the submitter, work with the community to revise it. That was Heather Schiller and Scott Leibrand.

It was presented at the PPC at NANOG 60. The AC accepted it as a Draft Policy in March. It’s accepted as a Draft Policy when we understand it has a fairly clear problem statement. So we know it’s applicable. Someone’s identified a part of the number policy in the region that needs to be changed. We may not know how it’s going to be changed, but we know it’s identified as something to be worked on.

And then it was presented at ARIN 33. It was revised in May after the Chicago meeting, ARIN 33. It was presented as a Public Policy Consultation at NANOG 61.

The AC advanced it to a Recommended Draft Policy in July, meaning they believe that the policy text that’s proposed to replace the existing text is equitable and fair in terms of administration of Number Resources. It’s clear. It can be implemented by the community. It doesn’t pose any particular problems in terms of implementation. It’s understandable.

So they have advanced this to the Draft Policy. Now they’re trying to confirm community support for it.

And the text is online and in the Discussion Guide.

I’m now going to call up ‑‑ so staff understanding. Slow down, Scott. Staff understanding.

So we ‑‑ the Recommended Draft Policy revises NRPM 8.2 Mergers and Acquisition section by removing aggregation and reclamation of resources as methods to restore compliance with current policy.

So the current policy text indicates that after merger and acquisition parties should engage in one of several methods including return and a transfer, reclamation and aggregation to bring themselves back into compliance after a merger or acquisition.

Removing this terminology makes sense, given that we’ve retired the policies that would allow someone to do aggregation. Removing the reclamation terminology may encourage more people to complete 8.2 transfers, because reclamation is no longer part of the policy.

Some people get a little nervous about they see an 8.2 transfer and they note that it says at the end of that process they may have to engage in ‑‑ we may engage in reclamation. We don’t do that. So this makes it a little clearer that we don’t.

The problem statement does not specify which version and date of the RSA. But this is a reconciliation issue between the policy and the RSA, the current version. The current version of the RSA 11 and the LRSA both materially have the same language. So it does not propose any material legal issues.

Looks like a cleanup that addresses something that makes sense.

Now I’ll turn it over to Scott Leibrand.

Scott Leibrand: All right. So the problem statement here is pretty simple and mostly was summarized in the introduction. There are utilization requirements in the 8.2 transfer policy that basically say that if you have a large number of resources that you’re acquiring in an acquisition and you don’t have any need for those resources, you don’t have any use for them, you’re going to be significantly underutilized after the merger or acquisition that you are supposed to do some things to get back into line with current policy.

At the time that the policy was written, it was written to encourage that pretty strongly, and it included the ability for ARIN to reclaim the assets if you didn’t voluntarily engage in one of the other actions to take care of that.

The RSA, since the original text was written, was strengthened to give people the right to ‑‑ not the right ‑‑ but to prohibit ARIN from reclaiming resources solely for lack of utilization.

So once you’ve got resources, you didn’t commit any fraud, you’ve got them for good reason, then there’s nothing in the RSA that allows ARIN to take those back forcefully.

So the conflict there between that and the policy text meant that we really needed to clear that up. The legal language, obviously, controls. But it wasn’t clear to someone going through that process that there actually was no threat here, it was an empty threat of reclamation.

So the concern with No. 1 is that because of that lack of clarity as to what the process actually is, there may be some people who engage in a merger or acquisition and reading through this, they or their lawyers see risk and they say, oh, well, we’ll just use the addresses and not bother to update ARIN, and then the Whois never gets updated, et cetera, et cetera.

I already talked about Section 2, the conflict with the RSA and the RSA controlling. The other part of this is that there was ‑‑ there used to be a policy to allow you to turn in some small blocks and get a larger block for aggregation purposes, or to turn in a bunch of small blocks and get a single larger block that’s still smaller than the others.

Not many people use that, but that was perceived as a method of getting back into line with how much space you needed. That was removed recently because it was basically a loophole for people to get addresses from the free pool before it ran out. So the aggregation thing is no longer available in policy so referencing it makes no sense.

So this is a really simple change. We strike the words “aggregate,” “reclaim,” and we remove the “or” and the commas. You can’t aggregate because there’s no policy text. ARIN can’t reclaim because the RSA says you can’t reclaim. So we’ll strike those two out of the language. Boom. You’re done. That’s the rest of the language in 8.2. Nothing’s changing there.

So if you thought you didn’t see something in 8.2 in the other language, it’s because we’re not changing it.

We talked about the history. There haven’t been any PPML comments. We’re perceiving that as everyone thinks this is great, but we’re bringing it back to the community to get feedback on that: So do you support this Recommended Draft Policy as written? And if you’re opposed, what concerns do you have? And do you have any suggestions?

So with that, I’ll open it up.

John Curran: You can moderate.

Scott Leibrand: I would not be surprised if there’s a lack of input on this, because to date we’ve seen pretty good ‑‑ good.

John Curran: For those looking for the policy that we’re discussing, it’s on page 12 of your Discussion Guide, and you can see the proposal and the Draft Policy text.

Mike Joseph: Mike Joseph, Google. Quick question, maybe clarification from staff. While we’re removing verbs, what verb would be used to describe the action that ARIN staff would take if it was found during a transfer request that the source entity doesn’t have a legitimate successor?

John Curran: You’re saying the source entity doesn’t have the rights to transfer?

Mike Joseph: Well, the destination entity doesn’t ‑‑ because in 8.2 it’s always the destination entity that’s requesting the transfer.

John Curran: Okay. Slow down.

Mike Joseph: Let’s say I try to transfer space from a source entity I don’t have the right to receive assets from because, for example ‑‑

John Curran: You don’t meet the needs test.

Mike Joseph: No, because I’m not a legitimate M&A successor for that entity. It was found that maybe the entity is defunct rather than acquired.

John Curran: Let’s divide the world into source and recipient. Let’s work with source first.

Sources often have gone through multi‑year histories of mergers and acquisitions themselves. And so at the end of that process we have to validate that the final entity is the actual rights holder. If that’s correct, we approve the M&A transfer to the final entity. If that’s not valid, the final entity is not the successor organization, then we don’t approve the transfer. But this language applies after an approval.

Mike Joseph: I was trying to figure out if you don’t approve the transfer because the source entity, say, dissolved and there was no successor entity, what action would ARIN take in that circumstance.

John Curran: So completely independent of what happens due to a transfer request, ARIN does reclaim resources from defunct entities. If we determine that a party is completely defunct, has no successor and we have this happen occasionally, then we will actually pull it back to the free pool, and we’ve done that on occasion.

Mike Joseph: You would use the information obtained during the transfer process to affect that.

John Curran: We use any information we find including that of public information. So, yes, it’s possible that a party that thinks it’s a rights holder that shows up and is not the successor entity to, A, not be designated with that resource and, B, that resource to end up in the free pool.

Mike Joseph: Does anything in this policy proposal inhibit ARIN from doing so?

John Curran: Not at all. You have to be a legal entity to hold the resources; otherwise, we will pull the resources back. Organizations that have gone defunct usually in state registries that have no successor, we will reclaim the resources completely independent of the 8.2 M&A.

Mike Joseph: Thank you. I support the policy.

John Curran: Okay.

Dani Roisman: Dani Roisman with SoftLayer. I have a question. You remove the word “reclaim,” but you keep the word “return.” What’s the difference between “return” and “reclaim”?

Scott Leibrand: It’s a voluntary action that the recipient engages in because they’re a nonprofit and they don’t see it in their mission to transfer addresses for money, things like that. If the organization doesn’t want to transfer addresses, they can give them back to ARIN voluntarily.

John Curran: Even to this day we have parties returning address space. We often stare at them and explain to them at length that they have the rights, these rights can be transferred. There are agreements that say this.

But some parties just say no, I never needed it or we never used it, and here that could happen subsequent to an 8.2. It’s not inhibited as one of the mechanisms that could be used to get back to compliance.

Dani Roisman: So my general statement is I support anything that gets out of the way of successfully completing 8.2s. So I think it’s a good idea. Thank you.

Scott Leibrand: Owen.

Owen DeLong: Owen DeLong, Black Lotus, ARIN AC. I’m not going to speak in favor or opposition at the moment, but I do have one question, which is what will now happen in the case where somebody wants to complete an 8.2 transfer, they don’t have justified need for the resources, and they’re unwilling to return them or transfer them?

John Curran: So when they ‑‑ when we get to the end of the process, when they merge, they’ll qualify based on the combined assets and network infrastructure for some amount of the resources. What’s left, they’ll be told they need to return or transfer to another party.

Now, we can actually go back after a period of time and say: You haven’t done this transfer; you need to come into compliance with policy.

It is possible for us to actually issue reclamation and ‑‑ well, actually, I guess we cannot issue reclamation now subsequent. So a party would be repeatedly encouraged to do the transfer or return the resources.

John Sweeting: They never qualify for free pool or transfer.

John Curran: Right. All we can do is encourage them to transfer or return the sources. Either way, they would end up being useful to the community. If they transfer, a party that needs them would end up with them; if they return them, they would end up going into the pool or soon going into the waiting list.

Owen DeLong: If they sit on them and go, Eh, nothing happens.

John Curran: Theoretically possible.

Owen DeLong: Then I oppose the policy.

Mike Joseph: Mike Joseph, Google. In the previous example, would ARIN effect the transfer to the destination entity prior to requiring them to return or further transfer the resources, or would ARIN have the resources remained held in the name of the source entity until a new destination was selected?

John Curran: So recognize regardless of the policy, we would ‑‑ in either case we would still process the transfer to make sure the records are updated to the current successor organization. We would tell them how much they can transfer, and the remainder would need to be addressed by them.

This doesn’t change the actual outcome because we can’t do reclamation today because under either of the RSA ‑‑ RSA or LRSA, both which recognize the same rights ‑‑ we don’t have the right to reclaim for lack of utilization threshold.

Mike Joseph: But you do have the right to not transfer?

John Curran: We do. We have the right to actually recognize you’re the successor organization, but we’re going to keep your records inaccurate, okay, if that’s what you’re saying, yes.

Mike Joseph: Technically you could reclaim once that other entity was dissolved. But in any case ‑‑

John Curran: If we recognize you as the legal successor organization, you’re saying we have the right to keep the registry inaccurate because you will be motivated to somehow return or transfer addresses?

Mike Joseph: How long does ARIN give a destination entity before they get really mad that they haven’t transferred?

John Curran: Before we get really mad. You understand, most people are very cooperative on this matter.

Mike Joseph: I understand. So are we, but I’m curious what the policy framework would be.

John Curran: Again it doesn’t change. We cannot reclaim ‑‑ a party that signed an RSA or LRSA recognizes we’ll not reclaim for lack of utilization. This doesn’t change the practice even if adopted. It only makes it line up with current practice.

Mike Joseph: So we’re told to transfer whenever.

John Curran: Told to transfer as soon as possible or return the resources.

Mike Joseph: Thank you.

Owen DeLong: Owen DeLong, Black Lotus, ARIN AC. Seems to me that transferring the fraction that are in compliance and holding the remaining resources in limbo would be entirely within the spirit of policy and what has been expressed as the will of the community and that it is perhaps the RSA that needs updating.

Dani Roisman: Dani Roisman again from SoftLayer. I just want to quick note to the Advisory committee while I mentioned that I do support this policy, I just wanted to reserve that I support any policy that reduces inhibitions for transfers and needs‑based assessment.

I think this is a good first step. I think it definitely needs to go further. But if we can get this one through, we can chip away at it the next time. Thanks.

Kevin Blumberg: Kevin Blumberg. Just for clarification: The RSA trumps the NRPM?

John Curran: Absolutely. The RSA is the contract of services with ARIN.

Kevin Blumberg: So this text, while it is the NRPM, has never been effective?

John Curran: The LRSA approximately ‑‑

Kevin Blumberg: Sorry, never is a long time.

John Curran: ‑‑ three years ago was clarified to make plain to legacy holders that they would not have their resources reclaimed for lack of utilization.

The RSA about two years ago was brought in line because it was not felt that this is a right that should be only extended to one party in the region.

So everyone has that. This language was operative until all the parties were being treated the same with the LRSA and RSA updates.

Kevin Blumberg: Thank you. Based on that, I would like to say that I don’t like sticks, big sticks especially, and big sticks that are never going to get used and are irrelevant just scare the community, aren’t good for the community, and I support getting rid of this.

Scott Leibrand: Thank you. I will point out one thing: This policy is cleanup. It doesn’t change anything, as we’ve heard. If you think the current policy and practice is not ideal, there is the policy process to actually change the way that ARIN does transfers. You could introduce a new Policy Proposal and there’s the Consultation and Suggestion Process for suggesting how ARIN might change its business practices particularly with regard to the RSA.

Those are not ‑‑ the RSA changes would not be part of the Policy Development Process, but the ARIN Board of Trustees would take advice from the community into consideration in determining what future versions of the RSA would say.

That said, the question before us is simply whether to clean the NRPM up to make sure that it’s in line with the current RSA and current allowed practice.

So if there’s any more comments on that, speak up; otherwise, I think we can move on.

John, is it appropriate for me to do show of hands stuff, or do you want to do that?

John Curran: Up to you. Do you want a show of hands?

Scott Leibrand: I’d like to do a show of hands.

John Curran: Thank you, Scott.

Okay. At this time we’ll take a show of hands and poll of the remote participants so we understand how the community feels on this. This will be provided to the ARIN AC.

So the question is ‑‑ you have the policy in your guide. I’m going to ask for everyone in favor of advancing the policy as written, and then I’m going to ask for everyone opposed.

When I ask, I want you to raise your hand nice and high. This is NANOG’s exercise component that’s a very small part of the NANOG program, but you should enjoy it and raise your hand high.

Remote participants, when I ask, you should go into the chat room and indicate that you are in favor or opposed as appropriate.

So on the matter ‑‑ whoops. On the matter of Recommended Draft Policy ARIN 2014‑9: Resolve Conflict Between the RSA and 8.2 Utilization Requirements, all those in favor, raise your hand now. Nice and high. Again, remote participants. All those opposed, raise your hand high. Keep your hand up until counted.

Thank you. Thank you, Richard.

On the matter of 2014‑9, number of people in the room, including remote, 62. As written, in favor, 26; against, one.

Okay. This information will be provided to the ARIN AC in their consideration of the policy proposal.

Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]

And we’re going to move on in the Recommended Draft Policy. We’re now going to move on to the next one on our agenda, which is Draft Policy 2014 ‑‑ here we go ‑‑ Draft Policy 2014‑6.

One side note. People were talking about the LRSA and RSA and the fact ‑‑ the Board of Trustees worries about that, and one of the ways you can also influence how decisions like this are made at ARIN is we do these things called elections every year where we actually elect two out of the six elected members every year. We have one of those coming up later on this week. You should all pay attention to that, because obviously the trustees do make a difference in terms of oversight of the fiduciary duties of ARIN.

Okay. So I’m now going to move on to the next policy. It’s Draft Policy ARIN 2014‑6: Remove NRPM Section 7.1. And this is Rob Seastrom.

Come on up, Rob.

Rob Seastrom: 2014‑6 involves removing NRPM Section 7.1, which is the part that talks about running IN‑ADDR.ARPA, and the companion section talks about running IPv6.ARPA.

The author asserts that this is strictly operational and should not be in NRPM. This was presented at the same time as 2014‑5, which was passed along, which involved lame delegations. One might profitably wonder why 2014‑5 has moved along and why 2014‑6 has not.

And the reason is that 2014‑5 codified existing practice and just said, you know, we never actually put in anything about lame delegations into practice so it really just ought not be there. And that was fairly straightforward.

The discussion involving removing 7.1 and 6.5.6 in their entirety has circled around, well, it’s something that we actually do today. We run IN‑ADDR.ARPA, and that ought to be documented somewhere and specified somewhere, perhaps in the BCP document.

However, the ARIN staff has taken that under advisement. We’ve had discussions about that document, but the document has not materialized yet. I assume it’s being appropriately prioritized.

Well, you have to keep the lights on, right? There are certainly plenty of other things that might very reasonably take precedence over that.

So the question is: Are we interested in keeping this on our docket until such time as this document comes along? Are we happy with removing this text from the NRPM right now without that document, on the theory that, well, you know, running IN‑ADDR.ARPA is pretty straightforward and ARIN has a pretty good track record for doing the right thing in the absence of specific demands in the policy document? Is this something that we want to go ahead and move along, or do we want to leave it as is in the NRPM?

So here’s the text as it stands involving IN‑ADDR.ARPA delegation.

I’m going to move on to the IPv6 IN‑ADDR.ARPA. The text is in your Discussion Guide. Pretty straightforward.

So discussion. I invite people who might have an opinion one way or the other ‑‑ move it forward, keep it on the docket, do something else with it ‑‑ to please step up to the microphone.

John Curran: For those looking for it in the guide, it’s on page 11. Please maintain an orderly queue at the mics. No jostling.

Scott Leibrand: I only have one personality this morning.

Rob Seastrom: Have you yielded to everyone before you?

Scott Leibrand: I only have one personality this morning.

(Laughter.)

Scott Leibrand: Scott Leibrand. I’ll speak for myself.

It seems to me that this text doesn’t do much and that the documentation of this, while useful, would not seem to me a dependency for removing this text. I have no problem with moving this forward with or without any BCP or BCOP having been completed first.

I believe those should move ahead, but I don’t see any reason to hold this up for those. So that’s my personal opinion.

Rob Seastrom: So to read back your position to you, you’re in favor of moving it forward in the interest of general cleanup of the NRPM?

Scott Leibrand: Correct.

Rob Seastrom: Thank you.

Owen DeLong: Owen DeLong, Black Lotus Communications. I’ll speak in opposition of the policy. This is not strictly operational text. It is actually in fact text about the obligations of a service provider to provide certain classes of service to their clients and how those obligations are carried with receiving an allocation under the community policies set forth.

And as such, I think it does belong in the Policy Manual. I think it is important, and I think it should be preserved. I would support the abandonment of this proposal.

Rob Seastrom: Thank you. Anybody else?

Dani Roisman: Dani Roisman from SoftLayer. One quick question. In the previous slide you mentioned 6.5.6. Could you explain, the policy is trying to do away with 7.1 and retain 6.5.6?

Rob Seastrom: No, the policy was simply to originally get rid of 7.1. And the AC owns the policy after it is submitted. And we added in 6.5.6 on the theory this is the exact same reverse service for two separate classes of Internet Number Resource.

And the logic was that the discussion really ought to center around both of them. If you believe they’re separable in some way, I’d love to hear that, because that’s an argument that we’ve not heard so far.

Dani Roisman: The proposal is to eliminate both 7.1 and 6.5.6?

Rob Seastrom: Correct. We did not change the title of the policy, which makes it a little bit misleading, but the proposal, as it stands, is to get rid of both of them.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. If you could go back to the 4.x. The other slide. Will ARIN be providing IN‑ARPA support for blocks larger than 16 if this text is removed? Will ARIN be providing IN‑ARPA at all if this text is removed?

John Curran: So ARIN isn’t changing its services with respect to this one way or the other. The only question is whether or not currently 7.1 indicates that ISPs have an obligation for all ISPs receiving blocks smaller than a 16 and segment of a larger block smaller than 16, ARIN maintains IN‑ADDR. All ISPs retaining ‑‑ or, excuse me, one or more /16, ARIN will be responsible for maintaining all IN‑ADDR records for their respective customers.

So we’re not changing our practice. Currently reverse DNS service is a service that we provide, just like we provide the Whois service.

There’s no portion of NRPM that says provide Whois service. Okay. So the question is whether or not this policy text is meaningful, it’s actually a service obligation, not a policy on management of address space.

I do think that ARIN needs a service document that says what services we provide to the community. That’s presently not in your RSA, by the way. Your RSA says we’ll provide some services, which we don’t mention anywhere, other than the services.

It would be nice for the community to have a community‑owned service document that says what services ARIN provides.

Rob Seastrom: Can I provide a clarification. That text has always sounded odd to me as a technical person because the way it sounds is as if ARIN is hosting IN‑ADDR.ARPA records for people who have delegations. And to the best of my knowledge, ARIN has never done zone transfers from customers and hosted those IN‑ADDR.ARPA records. IN‑ADDR.ARPA has always been delegation only.

John Curran: Is Mark here? Mark, we don’t zone transfer. How do we generate IN‑ADDR.ARPA? Do we always delegate to a customer who has their own reverse DNS server, or does the customer have a choice of whether or not we’ll host the records?

Mark Kosters: It’s delegation only.

John Curran: It’s delegation only in all cases.

Mark Kosters: In all cases.

John Curran: Including in a /24, we delegate ‑‑ we delegate to your NS ‑‑ we put NS records into your servers. If you don’t have servers, we don’t have any records other than NS records.

So in which case the language is actually probably materially wrong of what’s in this text. More than being a service definition, it’s also an incorrect service definition.

Kevin Blumberg: I support this policy, thank you.

Jason Schiller: Jason Schiller, Google. I just wanted to follow up on the conversation with Dani Roisman. If you can go back to what this proposal is proposing.

Rob Seastrom: Which slide?

Jason Schiller: The one that’s saying it’s removing 7.1 and 6.5.6.

What I understand from the previous conversation is what’s printed in our packet, which is remove 7.1, and what’s on the website, which is remove 7.1, are both misprints and it should read remove 7.1 and 6.5.6 in their entirety. Is that correct?

John Curran: Do you guys update this after we got it to ‑‑ Einar?

Rob Seastrom: It’s been updated for months.

John Curran: I apologize. And the website ‑‑ hold on. Let’s pull it up. The website just says 7.1. Ah.

Unidentified Speaker: In fact, it says 7.1 on the ground but it doesn’t cover v6.

Unidentified Speaker: It never got updated.

John Curran: Ah. When you ‑‑ occasionally we have a miscommunication between AC and staff. 98 percent of the time it’s staff. So since that’s me, I screwed up.

Okay. So the current text removes 7.1 and 6.5.6. Please note that we’re discussing the removal of 7.1 and 6.5.6. The full NRPM is in your guide. The Section 7.1 is on page 47. 7.6.5.6 is on page 44. And it’s a paragraph entitled “Reverse Lookup.” This policy proposal would remove both of those photographs.

Unidentified Speaker: This is just a Draft Policy, so when we move it to recommended ‑‑ move this to recommended, we would change the text, post it back out on PPML as that, get feedback, and then move it to recommended after another staff and legal review because of the change in the text of the policy.

Rob Seastrom: Yeah, the question at hand is whether we move this to recommended draft.

John Curran: Right. This is also why ‑‑ the 6.5.6 text is why I indicated that it actually has obligations on ARIN’s customers in here, which is unclear. It’s unclear whether or not the community out there, each organization should properly manage its reverse lookup. Okay. And what does ARIN do if you don’t?

This is an interesting language to show up in an NRPM because theoretically failure to maintain, follow address policy, such as an obligation for reverse lookup, is actually something that we could act on someone for. We can’t act on someone for lack of utilization, but we can act on someone for failure to follow policy.

Rob Seastrom: I’ll make popcorn if you ever do that.

(Laughter.)

Mike Joseph: Mike Joseph, Google. Does ARIN currently maintain an information page describing the IN‑ADDR service they offer? And if not, would ARIN likely create one should this policy be adopted and all information about IN‑ADDR therefore removed from ARIN’s website?

John Curran: Between now and the next meeting, either, we’ll need to have a Web page describing all of our services or we need to have a community‑owned document describing all of our services.

Mike Joseph: You would want a community‑owned document that describes what services ARIN will provide? I’m supportive of that, I just don’t know ‑‑

(Laughter.)

John Curran: The reason I say “or” is because I want to be very clear. ARIN’s your organization, not mine. Okay. I think it’s a great idea. However, the budget’s owned by the Board of Trustees that you guys elect. And so community‑owned is interesting in that respect. One or the other is definitely desirable, though.

Mike Joseph: Is that a commitment to produce something for the next meeting?

John Curran: I said one or the other is definitely desirable.

Rob Seastrom: With the clarification and lack thereof in some cases that you have received, are you currently trending in favor or not?

Mike Joseph: I support this (indiscernible) lack of a service document.

(Laughter.)

John Curran: Mike, let me try to commit. In the absence of a community‑owned service document, ARIN will document all of its services that it does offer.

Mike Joseph: Thank you.

Owen DeLong: Owen DeLong, Black Lotus. Still getting used to the name.

So I love the idea of a community‑owned service document. How would the community go about beginning that process?

John Curran: Once I’m allowed to ‑‑ once I’m in the position to turn around and engage the community on that, something we might talk about later on this week in a member meeting, then we could make some progress. But until such time, it’s probably cart before the horse.

Right now we do have the situation that it’s recognized that we offer a set of services not clearly documented. At a minimum, ARIN should fix that. One way of fixing that would be to let you folks document those rather than having us do it.

Owen DeLong: Fair enough. Getting back to the policy matter, there are many things in policies which place obligations on the recipients of address space. That is, in my opinion, an entirely appropriate thing for the community to do in terms of how ARIN manages resources on behalf of the community.

And I think that expecting service providers and such who receive delegations to have an obligation to, when making assignments at the very least, delegate the authority over those assignments to their customers is a perfectly reasonable thing to have in policy.

I think taking it out of policy would be very, very detrimental, because there are a lot of ISPs that I know that would love to not allow their customers to maintain their own IN‑ADDRs.

One particular ISP I deal with on a particularly regular basis is a case in point where it has been a struggle with them until I beat them about the head and shoulders repeatedly with the NRPM and said: If you don’t do this, I’m going to try to get your resources revoked. Then they delegated my IN‑ADDRs for me.

I think removing this policy would be very bad juju for the community.

Rob Seastrom: Thank you, Owen. Anybody else?

Can we get a sense of the room, please?

John Curran: Is that what you want?

Rob Seastrom: Yes, please.

No? Okay. Never mind.

Unidentified Speaker: We’re going to continue working on it. We’ve heard the comments. There’s not really any way to judge.

John Curran: This will be discussed later on in the week at the ARIN meeting.

Thank you.

Andrew Dul: Sorry, I just had a last‑minute comment remotely, if I might read it. From Kevin Otte. He opposes the policy as written and agrees with Mr. DeLong that delegation is appropriate to have the delegation in policy: I think striking for blocks smaller than /16 and for the segment of larger blocks smaller than a /16, ARIN (indiscernible) IN‑ADDRs would make this policy clearer.

John Curran: Something for the community to think about is even if we describe the services that ARIN offers, clearly, or have you describe in a document the services we offer, one of the things we’re moving quickly into is what obligations you guys are making to each other. And that is not very clear to ARIN. Like are you all committing to using a routing registry to each other somewhere? Are you all committing to maintaining reverse DNS? Do you all commit to show your delegation somewhere?

Because, quite frankly, none of that has to do with address management. That’s all commitments you’re making to each other.

And I don’t know if you want to try to explain what those commitments are and explain how you all will deal with your failure, because it’s actually not address management.

And so I want to put on the table here once you get out of, it’s not what ARIN’s providing, it’s what you folks have to do. Be very clear whether or not you think it’s address management policy, because it isn’t about the management of the numbers and who gets how many, it’s cross‑commitments you guys are making to each other.

We’re happy to record those somewhere, but you need to think very hard about how to set them and what the consequences of them not being followed or not followed.

Draft Policy ARIN-2014-15: Allow Inter-RIR ASN Transfers

I’m going to move on to the next policy. The next policy we have is Draft Policy ARIN 2014‑15: Allow Inter‑RIR ASN Transfer. And this is going to be Scott Leibrand.

Scott Leibrand: This one is kind of interesting. We thought it was pretty simple. The problem statement was straightforward. We allow ASN transfers between people and the region. Recently APNIC said we allow ASN transfers to people within our region, and if anybody wants to transfer them to or from other regions, that’s great too.

So the problem statement is, well, yeah, if we allow them in region and APNIC allows them in their region and they allow them between regions, we should do the same.

So the history of this is a little longer than that because we had originally tried to pass the proposal to allow inter‑RIR ASN transfers before APNIC did their thing, and the community basically said: Why? There’s nobody else doing this. We don’t know if anybody ever will do this. Don’t bother.

We abandoned that 2013‑1 for that reason. Then after APNIC adopted Proposal 107, this was brought back.

But then this last bullet point is interesting. After some discussion it was brought up that this might have impact on the RPKI. I’ll get to that in a second.

The text change is pretty simple. ASNs to be transferred are added to the list of things that can be transferred. And there’s some text here making sure that if you transfer ASNs, it doesn’t preclude you from getting v4 and vice versa.

But here’s where it gets interesting. Staff said there’s at least a moderate impact over the medium term because there are additional requirements and specifications necessary for RPKI support of inter‑RIR and ASN transfers.

Sorry, I’m talking too fast like I normally do.

That will extend into the future in terms of requiring coordination between the RIRs and IANA in order to transfer ASNs through the IANA with regard to RPKI.

So if you guys have technical questions about what those requirements are, I’m sure we have some people who can speak to those. But the discussion points, once we get those clarified, are with regard to whether the benefits of doing inter‑RIR ASN transfers outweigh the cost of doing so.

There is not quite such a clear supply‑and‑demand problem with ASNs as there is with IPv4 addresses. So it’s not clear whether transferring them between regions is necessary or if just allowing transfers within the region, which we do today, would be sufficient.

So I think I’ll actually start out with a question to John ‑‑ or to Mark. Sorry. Would you mind grabbing a mic and explaining what the technical issue is here? I could try, but you don’t want that.

Mark Kosters: The issue here is if we go to a model where the IANA is a global trust anchor, they basically have ‑‑ they sign a certificate saying here are the resources that ARIN has. Single certificate. And within that single certificate they say here are all the Autonomous System Numbers that ARIN gives out, here are all the IP addresses that ARIN gives out, and we in turn allocate those to you guys.

If there’s a transfer from region to region with those Autonomous System Numbers, that means that there needs to be a recertification from the top down on both sides of the chain, both for the receiving and for the other party.

So what we’re trying to do is we’re trying to reduce ‑‑ from an engineering perspective, we’re trying to reduce the number of interactions at that level in RPKI land. We don’t want to have to re‑roll certs that often. Every time we do, it actually may cause an introduction of some sort of error. So we want to keep that to a minimum.

So out of those ‑‑ if you go to the earlier slide ‑‑ no. Yeah, this one.

This particular ‑‑ if we go to that particular scenario where we have the sort of ERX for Autonomous System Numbers it actually goes away.

And we know how to handle it and it’s all good. But that’s something that we would have to do internally and all the regional registries would have to agree as well as IANA.

Any questions about that?

Kevin Blumberg: One question. Kevin Blumberg, The Wire, ARIN AC. So I left my operator hat on outside unfortunately. I’ve got the policy hat on here. But what’s the difference between an IP number and an ASN when it comes to RPKI?

Mark Kosters: You want me to explain the difference from an operator perspective?

Kevin Blumberg: No ‑‑

(Laughter.)

Kevin Blumberg: ‑‑ as in ‑‑ as in why are you having to re‑roll for ASNs and not IP addresses, or do you have ‑‑

Mark Kosters: You have to do it for both.

Kevin Blumberg: So you’re transferring ‑‑

Mark Kosters: Okay. So with numbers right now we have ERX.

Unidentified Speaker: What’s ERX?

Mark Kosters: Okay. That’s a good question. So, Geoff, do you want to explain it?

Geoff Huston: I can offer you a shovel.

(Laughter.)

Geoff Huston: Or I can try and fill in the hole.

In the IP address registries, IANA record what it did when it handed out a /8. When the RIRs moved stuff between each other, IANA was not involved.

In the AS number registry, we kind of got confused. And at some point in the recent past, about four or five years ago, we started telling IANA when AS numbers moved between RIRs.

And if you look at the AS number registry, it doesn’t have blocks of 1024 numbers ‑‑ this to ARIN, this to APNIC, et cetera ‑‑ it has all the little bitsies of movement. Interestingly, we only do that for the low 16 bits.

Movement in the extended AS numbers, which ARIN don’t use anyway, happens between the RIRs without informing the IANA.

Your problem is very real, because if we persist in recording all the micro movements of AS numbers in the IANA registry, then moving 2‑byte AS numbers is a unique problem that doesn’t happen anywhere else. It’s a unique problem that involves the route and IP address 406 or AS numbers don’t.

So that’s what Mark is saying. Why did this happen? I don’t know. Just one day the registry became a lot bigger. Whatever. But that’s why we are where we are.

Mark Kosters: Thank you, Geoff.

Kevin Blumberg: Sorry, Geoff, but why don’t we just leave IANA and ‑‑ not leave IANA. Leave IANA out of it ‑‑ sorry, clarification ‑‑ leave IANA out of it and do it the same way we’re doing IPv4 transfers today?

Geoff Huston: We could do this, but then reading the IANA 2‑byte AS number registry would be a confusing exercise because, quite frankly, it wouldn’t tell you where that AS number is. It would tell you where it was at some vague point in the past.

We’re very confused about the AS number registry. My advice to the community is a discussion needs to happen, possibly with the IETF and definitely with IANA, about what is a registry and what should be in it. And we could clean up what IANA has and say this block, that block, that block, the RIRs look after it, and you wouldn’t have this problem.

That conversation hasn’t happened, and hence the issue.

Scott Leibrand: Is the work going to happen anyway? This might be a question for John. My question is the cleanup work that seems to be necessary here, is that likely to happen in the absence of a policy requiring this, or are we going to muddle along with the current practice?

John Curran: So it’s a finite number of resources and a larger number of projects at any given moment. Will we expend resources on a project that no one will notice or care about unless it’s necessary? No.

So you call it cleanup work, but quite frankly you’re all using AS numbers successfully, I presume ‑‑ maybe 2‑byte ones; hopefully 4‑byte ones someday. But, no, we’re not going to put any effort into addressing this unless the community feels it’s an issue to be addressed.

And even if we address the registry structure of the ASN system, that doesn’t mean we’ll do the specifications of how ASN inter‑RIR transfers should happen unless there’s a policy that provides for RIR inter‑ASN transfer.

It can be done. This is not rocket science. Although the folks who engage in RPKI will often tell me it’s very close to it. But it is work. There’s real specification and testing and coding to be done to support inter‑RIR ASN transfers with RPKI.

David Farmer: David Farmer, ARIN AC, University of Minnesota. So how big of a suggestion do we need to clean this up? Do we need to leave it on the docket? Do we need to move it forward and make it into a policy that sits in limbo until it gets ‑‑ until the work gets done? The policy question I’m trying to figure out.

John Curran: Presently there’s no possibility of inter‑RIR ASN transfers. So there will be no work on implementing inter‑RIR transfers of ASNs. If you adopt the policy, we’ll figure out the amount of work and prioritize it. But at present there’s no effort to be done here.

David Huberman: David Huberman from Microsoft. The author of this policy proposal works on a network which operates on six continents and for all I know operates in Antarctica and gives CDN to penguins. I represent the Microsoft Corporation which also operates on six continents. Not Antarctica. Penguins don’t need cloud yet.

This is a real issue for large multi‑continental legacy networks. There are regulatory issues in other countries and very specifically China which require object number registrations to be made in specific RIRs.

China Unicom and China Telecom, which are your only transit providers, will not route stuff if it’s not in CNNIC period. And if you happen to be using an AS number that’s maybe three digits or two digits that is from ARIN, you’re SOL for now.

My point is even though this affects my network and even though this affects the policy authors’ network and even though this may affect some really, really large multi‑continental networks, there aren’t that many of us, and if it’s going to be this much work for specifications to make RPKI work to cut down on the number of key rolls, then I would support abandoning this proposal for now and we’ll just eat the engineering time it takes to relabel with different ASs.

Scott Leibrand: That’s essentially my question to the rest of the community. I just heard an excellent response to the last question. If anyone feels differently, if anyone feels there are benefits other than what David suggested or if the benefits David suggested are worth the implementation effort, I’d like to hear that.

Since these RPKI issues have been brought up, I’ve not heard anyone say: This is still worth it. We should still do that.

If you still think that, please get to the microphone now.

Given the resounding silence, my intention Friday would be to make a motion to abandon this Draft Policy. If you think that’s a bad idea, please get to the microphone. Otherwise, thank you.

All right. Thank you.

Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers

John Curran: Okay. Next up we have ARIN Draft Policy 2014‑14: Removing the Needs Test From Small IPv4 Transfers. John Springer of the ARIN AC will come up and handle the discussion.

John Springer: Thank you, John. So how is everybody? If any of you were in Bellevue, you will find that the experience you’re about to have is going to be substantially similar.

Let’s see. So in our meeting in Chicago, ARIN staff came forward and says that there’s been kind of a staff review of address transfer requests and general potential resource issues with operations.

A member of the community came forward and said that ‑‑ essentially this, that ARIN staff could move faster on transfer policies and allocations in general. And this policy seeks to assist them in that.

The way that the Policy Development Process works these days, for a proposal to advance to a Draft Policy, it needs to meet two criteria. It needs to be ‑‑ to have a clear problem statement. And this is the problem statement. The Advisory Council decided that that was clear. And it needs to be in scope for the Advisory Council’s mandate. And the AC decided that that was the case as well.

So here we are. This is a Draft Policy.

The question before us today is: What do we do next? We have a couple of options. One is we can move to the next step, take this Draft Policy to Recommended Draft Policy, or we can abandon it.

Actually, we have a third option. We can keep working on it. I could read you what’s on the screen, it’s in your manuals as well, if you didn’t have one. Essentially we’re going to modify 8.3 and 8.4 according to this method. The two statements are crafted to be as nearly identical as possible.

There have been some suggestions on PPML that this is duplicative. And so there may be some wordsmithing possible which essentially says what I just said involving this. But for now part one and part two are exceptionally similar on purpose.

Essentially what does this mean? What are we suggesting here? We’re suggesting that, first of all, there’s a boundary in number policy allocations as regards transfers that may be drawn at the 16 ‑‑ /16 boundary, and we’re going to call everything smaller than that small and everything bigger than that not small.

And there’s some interesting mathematics involved with this, which I am not really going to delve into now, but it turns out that that’s arguably fairly reasonable.

There’s been a lot of discussion about needs basis around the world in RIRs for quite a long time. There’s been a lot of concerns on the part of the community. Hoarding and speculation are possible outcomes of eliminating it. That could be good or bad depending on your perspective.

A point that’s often overlooked is that those people who would speculate are actually citizens of this community and they actually have the right to come to the meetings and they have the right to speak and they have the right to suggest policy and they have the right for those policies to be considered rationally. And if they’re to be discarded, they should be discarded on the basis of regional objections and not innuendo and bogeymen.

The proposal and the proposal author seeks ‑‑ yes, Kevin?

Kevin Blumberg: No, I’m waiting. I’m just in line.

John Springer: The proposal seeks a middle ground between outright abandonment of needs basis and number policy and continuation of the status quo.

Normally staff and legal review are ‑‑ we wait until something is actually a Recommended Draft Policy to do it, but there’s been a considerable amount of interest in this subject. So I elected to go ahead and ask for staff and legal review for this Draft Policy for this meeting and the meeting that will take place later in this week.

It’s in the manual. I urge you to read it. But essentially ARIN Council finds the 16 boundary to be a nonhazardous area in terms of legal exposure.

Also, ARIN staff has characterized an interesting number. In terms of the amount of transfers to date, which information is on the ARIN website, 85 percent of the transfers that have been made to date fall below the 16 boundary. The number of transfers.

Now, Owen recently did some analysis that we’ll probably be making public sooner or later with his permission, but it’s interesting to note that the very vast majority of the actual numbers that have been transferred fall above that line.

So we’ve got a situation where we’ve got the very great majority of the numbers are actually larger than 16 and would be unaffected by the policy, but the number of transfers, the very large majority of the transfers fall below the line.

So we could potentially, wherever we draw the line, whether it’s 16, 17, 20, whatever ‑‑ we can effect a very large result on ARIN staff time while not impacting the numbers that are being transferred. Hope everybody understands that.

So where are we at? Three things we can do with this: abandon it, move it to Recommended Draft Policy, or keep working on it.

For us to take it to Recommended Draft Policy, we need to meet three things. It needs to ‑‑ we need to ‑‑ as an Advisory Council, we need to vote as a majority that it enables fair and impartial number resource administration, it’s technically sound, and it’s supported by the community.

The converse also works. If we don’t feel that it’s unsupported, unsound, and unfair, then we can consider moving it along. That’s actually what I intend to do.

An argument can be made that it is not unsupported. This doesn’t require a plurality. It doesn’t require a majority. It requires support in the community.

It’s been very narrowly crafted. There’s nothing technically unsound about it, it’s not going to break stuff, staff and legal opine, and it appears to be fair.

A member of the community that has a right to suggest incremental change is doing so. If you don’t agree with any of that, tell me now.

Kevin Blumberg: I have a technical question. Kevin Blumberg, The Wire, ARIN AC. If you could go to the slide with the policy statement changes, “for recipients who have completed a needs‑free transfer,” is “needs free” defined in Section 4? How would somebody be able to do a needs‑free transfer, or is the expectation that the community knows in Section 8 what needs free is?

John Springer: Needs free is self‑referential in this policy in the grand old tradition of self‑referential things on the Internet.

Kevin Blumberg: Staff would see it the same way?

John Curran: Staff would see it the same way.

Dani Roisman: Dani Roisman, SoftLayer. As I mentioned before, I’m in favor of any policy that actually removes any inhibitions for transfers to occur successfully. I think this is a great baby step. I like the fact that we’re recognizing that we can reduce the workload on ARIN staff as long as there is good legal documentation showing the transfer can occur, rightful parties, recipients, et cetera.

I would prefer that we actually not put a limit on it of /16 and we allow all transfers to complete without needs‑based, but if we can at least get to a starting point and help get the community comfortable with up to a /16, get some precedent, get some experience behind this, and maybe the next time around we can limit all needs‑based. I would be in favor of that.

But I’m interested in getting feedback as to whether or not it makes sense to take one step to /16 and then discuss eliminating all needs‑based for 8.2 and 8.3 or does it make sense to charge right on through and just focus on removing all needs‑based.

John Springer: If that’s the question, I’ll speak to it. The community has expressed over the years a distaste for giant bites.

There have been a number of attempts to accomplish a great deal at once in a meaningful way, and they don’t work well. Incremental change is far more palatable.

And certainly the IP brokerage community has been unsuccessful in trying to get large changes happening at once. And at least in the author’s opinion and in my opinion, it’s more prudent to attempt things incrementally.

Dani Roisman: Just one more clarification. Trying to understand once you complete a needs‑free transfer in the prior year ‑‑ so really every ‑‑ you have an opportunity to return every 12 months for another needs‑free transfer?

John Springer: Correct.

Dani Roisman: Without having to go through the process of 24‑month justification?

John Springer: Correct.

Owen DeLong: Owen DeLong, Black Lotus, ARIN AC. So you’re welcome to make my spreadsheet public, or I can post it on PPML if people are interested.

John Springer: That would be probably best.

Owen DeLong: To provide additional data points, it turns out if you look at not just 8.3 but also 8.4, the number jumps up to 89 percent of all transfers and 17.47 percent of the total address space covered at 16 and longer.

If you go at 20 and longer, you still get 62.1 percent of all transfers completed, but it’s only 1.29 percent of the address space.

And so I think that it makes a lot more sense to take a lot less risk and do this more incrementally and put the boundary at /20 than to keep the boundary as proposed in this policy at 16.

Currently, there are no needs‑free transfers. This is a tremendous experiment, and it is one where it will be very difficult to close the barn door if it turns out to be a bad thing. Those transfers will have already occurred, and there will be nothing we can do about them.

So I would express a need for caution and for doing this in an incremental way because we have no data on what effect this will really have if it is adopted. We’ve never experimented with needs‑free transfers before, and I’d like to see us be much more cautious than opening the floodgates to a 16.

There is enough money on the table at /16 to make it completely worthwhile since there’s no restriction on the number of outbound transfers an organization can engage in under this policy for somebody who has, for example, a /8 to do 256 needs‑free transactions to 256 stood‑up shell corporations to transfer a /8 to a single entity without needs basis.

John Springer: Thank you, Owen. And thank you very much for the analytical work. I think it will be very helpful when the community has access to that.

And I will point out that there is a break in the numbers that everybody should look out for as you progress looking down the various places where this boundary could be. And it actually happens between 16 and 17. The incremental changes from 24 up to 17 are relatively small. And then there’s quite a jump between 17 and 16.

So at this point it’s like the old anecdote that’s falsely attributed to Churchill: We’re now to the point where we’re arguing about the number.

Mr. Joseph.

Mike Joseph: Mike Joseph, Google. I oppose this policy. I think there are a number of reasons why this is unsound policy. But I’ll name a few. For one thing, this creates ‑‑ this creates a slippery slope. Not just in terms of direction of policy, but even within any prefix size, it opens the door to essentially limitless transfer.

It creates a situation which not only, as Owen described, almost unlimited amount of address space could be transferred to an entity with enough subsidiaries or shell companies ‑‑ and, quite frankly, this is not just nefarious shell companies, because there’s no justification, many large companies already have enough subsidiary companies to be able to effect a transfer of almost any amount of address space under this proposed policy ‑‑ but more to the point, we’re going to start to see ‑‑ if we adopt this, we’re going to see websites and auctions pop up all over the place with “buy it now” buttons for a /24.

And they’re going to facilitate the transfer for you, it’s going to be one‑click shopping, and we’re going to see the number of PI /24s increase exponentially, we’re going to see a /8 deaggregated to 24s under this because there will be absolutely no barrier to an organization moving forward.

Additionally, one of the ‑‑ two of the justifications for this policy seem to be flawed to me. First, the policy asserts that ARIN staff is overwhelmed and we must pass policy to lighten their load.

Well, I think that’s a red herring. ARIN staff ought to be able to do their job. I believe ARIN staff and RSD can do their job. And I believe that if RSD is overloaded and unable to do their job, I’m confident that John and his team will let the community and the Board know that they need more funding.

But I don’t think that we ought to hold up red herrings like ARIN staff being overloaded as acceptable justification for policies like this.

John Curran: I just want to echo that remark. To the extent that we believe that we need more staff to accommodate workload, we seek staff and we have no problem with that. The community should make policy that it believes makes for proper Number Resource administration in the region. If that requires more staff, I’ll go get it.

It’s true we sometimes have disagreements as to whether or not the service levels are appropriate. So, for example, right now we have a surge because of the runout of v4 and people who are trying to get resources and people who are trying to get transfers. Do we staff up for what is a surge, or do we live with what might be response times that are of five‑ or six‑day turnaround over two or three? That’s a question we’re going to talk about in the ARIN meeting later this week.

But we’re still keeping up with the workload. We’re not accumulating a backlog. So right now we’ve decided to stay the course.

I guess the short answer is please make good resource policy. We will always staff accordingly.

Mike Joseph: I would ask, as we consider in justifying policy, we don’t throw out there arbitrary statements about overloading of ARIN staff as a way to try to slip policy through.

Further, the other reason I think this is unnecessary is that it purports that it’s next to impossible for a small entity to get a transfer through. And I just haven’t seen any credible justification for that. I see a lot of people on PPML complaining about the onerous process of filing a request with ARIN, but as somebody who files many requests with ARIN ‑‑ and, yes, certainly I have experienced it, but I’ve never seen any suggestion that it’s so onerous to file a request with ARIN to complete a transfer that we need to throw all of our justification out the door.

Businesses file all kinds of documents with all kinds of entities often. And the amount of paperwork and transaction costs of doing this kind of transfer with ARIN just isn’t that high in my opinion.

So I think that to throw that up as a justification for eliminating needs basis is a little bit absurd as well. I think if we feel that ARIN’s process is not running smoothly enough, we ought to work with ARIN to improve their process.

But, again, I think this is unnecessary, and I think it creates a really unfortunate precedent and in itself will open the floodgates to essentially limitless /24s popping up here and there.

Oppose.

John Springer: Thanks, Mike.

Sean Kennedy: Sean Kennedy, XO Communications. I would encourage the AC to keep working on this policy. I’m not ‑‑ I’m not for or against it at this point. But I have concerns about the /16, considering that.

The other thing I’d like the AC to consider is whether we limit these needs‑free transfers to the original allocation size. And I think that would address some of the issues that came up in this, and it would focus it on the transfer of what were originally small blocks to start off with, whether we set that boundary at a 16, 18, 20, whatever comes up as a final number, where it’s supported by the community.

But at least I would recommend that the AC keep working on it and refine it.

John Springer: One comment that I’ll make. One of the objections to this is the idea that there could be a humongous or other characterization of unacceptably large number of some allocation size, often a /24, show up. There have been 172, I think, of these transfers that have taken place to date since 2009.

What ‑‑ what ‑‑ you might want to think about what damage would look like. So let’s say if this were to happen and we got 100 percent increase in the number of those, another couple hundred of prefixes in the global routing table ain’t going to shatter it at our feet.

1000 percent, 1500, 10,000 percent, 15,000, 100,000 percent rise in the numbers in the allocation table only raises it 150,000 additional entries in the routing table. So think to yourselves: What does damage look like.

Rob Seastrom: Rob Seastrom, ARIN Advisory Council, TWC, and personally a legacy resource holder. When I got those resources, there was no needs basis, and so I do not have a religious thing for needs basis. The purpose of needs basis is that it was put in to prevent the free pool from prematurely evaporating.

So I’m okay with a return to that, but like with so many other things in the past, like the transfer market, when we decided that, yes, there was going to be a transfer market, I was a strong advocate for getting it running before we needed it so that we could see what the results were going to be.

All of this discussion about deleterious effects is strictly speculation. So we need to think about how to limit the deleterious effects while we find out what that’s all about.

I would be in favor of this because I believe that the hoarding issue is a bigger concern than the routing table growth size to which you just explained. I would be in favor of this if the amount of space that could be transferred while we get a feel for how it’s going to work would be the minimum allocation size, which in this case is a /24.

And then we can have the discussion about whether we ought to get rid of it: Hey, that wasn’t such a great idea, or, hey, maybe it should be a 22. Maybe it should be a 20. Maybe it should be something larger than that.

So I would be in favor of the aims of this, but I’m in favor of measured cautious baby steps and a /24.

David Huberman: David Huberman from Microsoft. I’d like to bring some different viewpoints to this. So I have ‑‑ the Microsoft Corporation has a department that has been studying the market on a weekly, monthly basis for two years to the best of our ability to determine exactly what inventory is out there, exactly what price points exist, and exactly who is doing what.

There is no speculation. There’s one or two fraudsters who are fairly well known who are trying to do some stuff. But there are no speculators right now that we can find. And we’re looking everywhere.

The comments that folks have made about this opens up the floodgates ignore the reality that in order for an 8.3 transfer to happen, the first thing you need to do is you need to buy the IP addresses.

So you can go out right now buy a /8 for a certain number of dollars for IP address. Well, you have to do that before you can issue /16s to 256 different shell corps. So you’re really talking $100 million. That money is going to get spent whether ARIN policy allows it or not, even to a speculator.

Because here’s why. Because if you’re speculating on it, you go out, buy, spend $100 million, you buy a /8, then you set up a “buy it now” button on the Internet, then you sell it for double that and you’re going to try and make $200 million in revenue.

You’re going to get the transfers through at ARIN, or you’re not ‑‑ sometimes they don’t care, by the way, the buyers. Those transfers will still go through because you’ll find a way to get through the policy. But it doesn’t change the fact that there’s speculation. There could be speculation whether this policy changes or not. You have to still buy the IP addresses.

If you want a /16 for your small company for a really legitimate purpose, you’ve got to go out and spend half a million dollars. That’s not small beans for most folks. Okay.

If you are going and spending half a million dollars, it’s because you want the IP addresses probably to use because you can gain revenue from your product that needs IP addresses. And I don’t understand why we would want policy to stand in that way.

Secondly, I was an ARIN hostmaster for a very long time. I’m very well aware of the statistics that show that over many‑year periods ARIN transfers of 8.2s have been abandoned at larger than a 50 percent rate.

Now, understand what an 8.2 transfer is. It’s: Hi, I’m Microsoft. I bought Owen DeLong’s company. I bought his company. He sold it to me. I bought his network infrastructure. I bought his IP addresses.

That’s what most 8.2 transfers are. A couple every once in a while where that didn’t happen, but you’re talking minuscule.

More than 50 percent of those got abandoned. They got abandoned because the process is too hard, they got abandoned because the language is scary, and they got abandoned because of ignorance and misinformation that says John Curran and ARIN is this really scary thing that’s going to take away my IP addresses if I tell them that I bought this company because, oh, my God, I don’t know what their utilization is, or actually they’re underutilized, but I know I’m going to utilize them, but they’re underutilized now. Is ARIN going to take it away?

The process is actually hard. It’s easy for me, easy for you, most of us in this room, because we do it for a living, but it’s not representative for those who come to ARIN and ask for transfers.

So the counterarguments don’t hold weight for me because the speculation is going to happen regardless of what happens at ARIN. The market really does work. People buy. People sell. People transfer. However they want to do. They’ll play within ARIN’s rules when it meets their ‑‑ when they can, when they want it to, and they’re going to ignore it otherwise.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I have to take issue with a comment R.S. made about he got legacy resources without any need.

There was need.

Rob Seastrom: That was not what I said.

David Farmer: Okay.

Rob Seastrom: No needs requirement.

David Farmer: No needs requirement.

Rob Seastrom: There was a need for it or I would not have submitted a request.

David Farmer: Okay. And I would say that there was a needs requirement is that you were going to use it. There’s an implied need. There was always an implied need. You just recognized it.

Rob Seastrom: You need to be careful. You’re in dangerous territory there, because in fact when I applied for it, I said that I was not going to advertise it for the ARPA.

David Farmer: Yes. But you were going to put it in an operational network. But ‑‑

John Springer: Get a room, guys.

Unidentified Speaker: Back on point.

(Laughter.)

David Farmer: Yep. Yes. But that is the point. The point is that there’s always been a need. The definition of need has changed over time. The fact that it’s now different doesn’t mean there wasn’t one before. And it’s not a bad thing for us to change back to what it used to be. And we’ll just leave it at that.

John Springer: Thanks, David.

Mr. Schiller.

Jason Schiller: Jason Schiller, Google and the NRO NC. I oppose. My concern is with regard to the cap. It feels to me that the cap makes it unfair. And the reason why it’s unfair is because if it’s a small organization and your needs for IP addressing for the next 10 years is smaller than the cap, you can threaten go in the market and get yourself a 10‑year supply of addressing.

However, if your 10‑year need or 15‑year need or whatever you think the magic window is for how long it’s going to take to get to widespread v6 adoption, if you’re creating a product and a service and it’s growing and you have a business case that depends on the ability to continue to grow the service and get more IP addresses, you need to plan to have those addresses available until v4 is no longer needed for growth because widespread adoption has happened.

That means you need to really secure the addressing that your product or service is going to need. If you are so large and you are growing so quickly that those addresses are larger than the cap, today, you can do paperwork and you can get what is potentially a two‑year supply based on your last one‑year’s run rate. And your growth is accelerating. So it’s less than a two‑year supply. But if you’re small enough, you can get a 64‑year supply if you can afford it.

This seems to be an inequity. So I think if you want to move this forward, you either need to push out the amount of space a large organization can get on the transfer market in terms of time horizon or you need to bring in where the cap is to remove the inequity.

John Springer: Thank you for the comments.

Andrew Dul: Andrew Dul, speaking as myself, not my Advisory Council hat at the moment. I think one of the things we need to think about ‑‑ and we had the opportunity to see some work from Professor Ben Edelman on the Mailing List about this ‑‑ is to look at what the transfer market we would like to see in the future and what are the limitations around it.

And there are a number of different avenues for us to pursue, one of which is this avenue that we are discussing here today. There are, however, other avenues and a matrix of those avenues that would possibly be more beneficial to the community and the Internet as a whole rather than this specific policy.

I personally do not support the policy as written but believe it possibly could be morphed into something that I could support at some point in the future.

But I believe that needs ‑‑ one of the things that needs to happen is we need to address a lot of the concerns that we have heard here today such that we have a more unified position amongst all of the stakeholders within the community, not just for a specific set of stakeholders.

John Springer: Thanks, Andrew.

John Curran: Question, Andrew. When you say we address the concerns of everyone in the community, are there particular policy changes that you think would make that happen? If so, could you suggest them?

Andrew Dul: I could suggest a number of them. I think there are a number of changes that are possible here to satisfy multiple different stakeholders, including the limit of size, the length of time, a requirement that the blocks be used on an operational network by officer attestation of the organization and other elements like that.

So I believe there are multiple changes here that are probably necessary.

John Curran: Helpful. Thank you.

I’m going to be closing the mics in about two minutes. Somewhere there’s coffee in the building waiting for us. And so the mics are closing. Please approach the mics if you wish to speak.

We’re going to close this policy proposal and take a coffee break, come back and move on to the next one. So if you wish to speak on this policy proposal, please approach the mics.

Heather Schiller: Heather Schiller, Google Fiber. I’m going to make a devil’s argument. There’s an argument that could be made in the other direction in saying that organizations that are requesting a prefix larger than a ‑‑ pick a number ‑‑ 18, 17, 16 could ‑‑ because of the amount of resources that they likely hold already in order to have gotten to the point of holding a 16 and the level of documentation that they’ve had to do could request space without having to justify need and flip it the other way because ‑‑ and part ‑‑ part ‑‑ part of what Jason is saying, but part of it is one of the things people are saying is the amount of documentation for a small organization to get resources is onerous.

Well, the amount of documentation for a large organization who holds potentially hundreds of resources is onerous to do that kind of auditing, and so you can make the same argument in the other direction for large organizations.

I mean, you could, and you could say like an organization that is getting audited by ARIN currently every three months and having to provide reams of documentation every three months, ARIN’s already very familiar with how their resources are being used. It’s an argument one could make.

John Springer: It’s very valid. Now we have both sides of the equation.

John Curran: Please approach the mics. I’m closing them in ten, five, three, two, one.

Last speaker at the mic.

Colin Colbert: Thank you. I was wondering if I would get to talk. I was like, Hello? Can’t hear.

Hello. Colin Colbert. I am not in favor of this proposal. Over the past six months I’ve received v4, v6, ASN allocations, and I’ve been doing this for a few years. And while I have had my requests kicked back a few times, I believe that demonstrating need is necessary.

An allocation of a 16 does seem to be wildly excessive, mainly because I’ve never received more than a /20. And since, when I fill out the forms, ARIN is comprised of members, both ISP and end users, this proposal does not seem to accurately reflect that idea.

John Springer: Thank you.

John Curran: Okay. Thank you, Mr. Springer.

(Applause.)

John Curran: If you go downstairs, we are now on the 11:00 to 11:30 break. We’re going to have a 21‑minute break.

We will see you back here at 11:30. The train shall run on time. See you all at 11:30.

(Break.)

Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

John Curran: I’d like to welcome everyone back. We’ll pick up on the next policy discussions. Next policy is ARIN 2014‑20: Transfer Policy for Slow Start and Simplified Needs Verification.

Come on up, Kevin. Kevin Blumberg.

Kevin Blumberg: Good morning, everyone. This is a policy that’s similar to the last policy but completely different.

(Laughter.)

Kevin Blumberg: It looks at 8.3 and 8.4 transfers, and it comes up with a way to simplify some of the needs without removing necessarily all of the needs that was in the previous policy.

And when I say it’s ‑‑ it’s similar in vein. In fact, when we did a staff and legal review two weeks ago, legal actually co‑joined them in his description of the two policies and sort of looked at it.

So the one thing about this policy ‑‑ and I wish to apologize now ‑‑ is the policy is four pages long.

So we’ll start with the problem statement. As you might be aware, we’re running out of IPv4 space. I heard there’s a lot of v6 space available, but we are running out.

So new organizations will have a difficulty qualifying for slow started space, and new organizations that are growing rapidly will have difficulty by growing under slow start, is obviously a concern in the transfer market. When you could just come back to ARIN, it was easy to deal with slow start ‑‑ well, “easy” is a hard word, but it was possible to just keep coming back to ARIN in the slow start model every three months, every month, whatever the case is, used all my space, used all my space, give me, give me more, give me more.

Well, that giving me more is gone. Going to the transfer market 12 times over an 18‑month period as an example would probably be considered onerous to anybody in this room.

So organizations with regular growth may have difficulty getting the right‑sized block and may require multiple transfers.

Staff have said that’s actually not an issue, if you are approved. And this was ‑‑ again, the staff comments came out very recently. So after text freeze. But basically I believe staff said: You don’t need to worry about this if you get approved for an amount of space, you’re fine; we’ll allow multiple transfers.

Rapid growth, where we need to double. Existing ORGs are going to have a problem with that with unprecedented growth.

So here’s the policy statement. And I’m just going to try to go through this very briefly, and I hope people have had time in advance to read some of it because it is long and there are some nuances.

So the main part of this policy is right now in many respects an 8.x transfer ‑‑ an 8.3, an 8.4 ‑‑ this does not include 8.2, so just ‑‑ very important, 8.2 is not included in this at all. But an 8.3 and an 8.4 is fundamentally based on a 4.x requirement.

So when you go to ARIN today ‑‑ and, John, if I say anything wrong, please, I’m sure you’ll correct me. But when you go to ARIN today, by and large you will say: Based on 4.x policy I need this space and this is my 24‑month run rate versus my three‑month run rate.

And ARIN goes: Based on your MDN or micro allocation or this or that, absolutely, that sounds right, you are now approved in an 8.x transfer.

That puts a lot of requirements on back and forth and back and forth. And the 4.x is a very complicated policy based on the free pool versus the transfer market.

What this policy tries to do is say let’s extricate the two and let’s look at 8.3 and 8.4 as its own section. These are the rules for an 8.3 and an 8.4 transfer. Let’s not think about the 4.x; let’s keep it completely separate. The advantages to that is it’s one clean space for you to look at for an 8.3 and 8.4 transfer.

The one disadvantage is we now have to look at all 4.x section and say: Does this apply, not apply? Does this work the same way? Is this easier? Is this more difficult?

And that’s the one complexity with a policy like that.

There will be definitely some cleanup to the text, because as an example we have identified that MDN and TPIA do need some love in this policy. They are less ‑‑ those two policies potentially are less stringent than what would go in here normally. But that could be added in very easily to allow for MDN and TPIA, those sections in the 4.x, to fall under 8.

So the main change. We now go to replacing out the 24‑month supply of IP addresses. We go to the new sections, 8.31, new ORGs, and if you can demonstrate 50 percent immediate need, you’ll qualify for a minimum assignment of 24.

That was based on previous NRPM. So in the current NRPM, there is no maximum size for an initial allocation that has been defined. That was removed out very recently.

One of the suggestions was if you have a 50 percent immediate need, you can get the space that you need and we take out the sizing of the 24.

That’s where I’d love to get feedback on that: Is there some magic number that we should put in in transfers that don’t exist now today in the free pool 4.x.

So an end user right now says 24 and an ISP says 21. Again, if we collapse them down, those two sections would become one because there would be no distinction between an ISP and an end user really at that point.

For an existing ORG, once you’ve got your 80 percent, again, as measured under Section 4, across all of your aggregate, which is very different from how it works today, across all your aggregate ‑‑ allocated, assigned, reallocated, reassigned ‑‑ you’ve got your 80 percent, then you can go to the next, which is you can be approved for space.

You can complete one or more. So that’s codified now. Staff have said it’s not a problem, you are, but it is now codified. And you won’t exceed what your existing amount is.

So let’s go to stable growth. Organizations may be approved for additional address space equal to the amount of address space they’re holding at the time of approval.

Okay. Is that good? Is that bad? How does that impact your organization? How does that impact the community? Something to think about.

So you’re going to get additional address space equal to everything you’re holding at the time. You’re holding an 18. You can get approved for an 18. You’re holding a 2. Can you get approved for a 2?

John Curran: /2?

Kevin Blumberg: Aggregate. We’re talking aggregate.

Unidentified Speaker: (Indiscernible.)

Kevin Blumberg: I don’t know if somebody does or doesn’t have ‑‑

John Curran: Probably better to use the example of 8. Holding a /8, you can transfer in another in in case the first one runs out.

Kevin Blumberg: Exactly. And then you can go in for something even bigger.

So organizations may be approved for additional address space equal to 24 times the organization’s calculated monthly average use rate.

Again, this is another way of giving you as much as you possibly can without complicating the numbers. And that comes into a rapid growth scenario.

What is a monthly use rate? Okay. You know what, if it’s December, things might be slow. If it’s November, things might be fast. And allowing you, the organization, to define where your run rate was. Hey, pick the last 12 months; that gives you the best indicator of what my monthly run rate is. Or, you know what, things are really picking up. Use the last three months; that’s the best indicator for how things are growing with me.

That’s a lookback window. So that’s actual usage. It’s a real number for everybody here. Right now it says 24 months forward looking. That’s what the transfer policy today is.

So one is based on I think I’m going to need the space versus here is 24 times what my average monthly real use is. Big difference. Okay.

You can return space, if you’re getting space. I don’t know why you would do that. But, hey, we’re giving you the option. You can return space and maybe return out some smaller blocks. Those smaller blocks get added back to your inventory of what you’re allowed to get. And you can get one bigger block if you so choose. Return space is in there.

So the one thing that is important, if you go off and do an 8.2 merger and suddenly everything changes, that gets taken care of.

There’s lots of great stuff here.

And the best part is then we deal with 8.4, and it’s the same as 8.3. One word difference, subtlety, and we’re all good.

So my questions for the community are: This is a lot of text. Can you get behind an omnibus? And an omnibus is more than just one simple change to me or one or two simple changes. Can you get behind an omnibus? Do you want the AC to work on an omnibus?

The second option is do you want us to look at a mask, which is a second way of doing this, which is here are all the things ‑‑ because right now the only mask that we have in 8.3 is 24 months. You see three months; you make it 24. You see three months; you make it 24. That’s the mask that we have now.

Would it be better to say that we’re going to follow 4.x but here are all the things we want to make simpler in 8.3 and come up with just a short list? And if there’s a short list, based on all of the things in here, what are the things you’d like to see in that short list? What are the things you support in this policy or don’t support in the policy?

The last thing before I open the mic is it’s important to note this policy is not contradictory to 14. It is completely different than 14. You can support 14 and go down that path.

From what I saw just at the mic earlier, I think there’s a lot of work that needs to go into 14. There might be very little work that goes into this and we might be able to get this passed right away. This might be the baby step until something like 14 comes along.

So I want to support one and not the other. You can have a preference, but it’s important to note that sometimes it’s easier to reach consensus on the baby steps than on the big steps.

So I want to open up the mic. If you have any questions, by all means please come up.

Sean Kennedy: Sean Kennedy, XO. I just want to take a little bit of issue with what you just said, putting this forward as a baby step, because there is so much language. There’s a lot of stuff in there, like picking a three‑month window versus a 12‑month window. Is that necessarily a good thing? Because a lot of companies, government organizations have money to spend that they need to spend before their budget year is up. So the last quarter of the year they may spend all that money; I’ll turn up a bunch of new customers and have a huge burst in ports that’s not going to be sustained across the following year or the following 24 months.

So I just think that there’s a lot of text for something and a lot of complexity and implementing stuff within a section that, I mean, previously we covered separately, and I don’t necessarily consider that a baby step.

So I would tend to sort of say let’s pick one or the other for the AC to actively work on with the community from the two policies and see that the community is really behind that policy.

Kevin Blumberg: Thank you.

Dani Roisman: I’m opposed to any specific work on this policy. Specifically there’s one section I take issue with which has to do with further codifying the minimum requirements for existing ORGs to complete transfers.

I prefer the work in 8.3.2.1. I understand that 8.3.2.1 is primarily here to document what is probably the practice referring back to some of the 4.x NRPM language.

However, I’m in favor of moving forward with Proposal 14 instead and long‑term actually working towards eliminating all needs‑based assessments ‑‑ historical, future looking ‑‑ for all transfers, 8.2 and 8.3. Thank you.

John Curran: Can I ask a question, Dani? So presuming 14 died for some reason and the community didn’t adopt it because of the discussion here and the work going on, are there changes that could be made to 2014‑20 that would make it acceptable?

Dani Roisman: No, in my opinion, in 14 died and 2014‑20 actually moved forward, then we’d have more work removing language that got introduced in 2014‑20. So ‑‑

John Curran: My question is: What language would that be that would make it acceptable to you?

Dani Roisman: Honestly, any language that further codifies any sort of needs‑based or any utilization assessment ‑‑ forward looking, rear looking ‑‑ for 8.2 or 8.3 I believe needs to be removed entirely.

John Curran: Thanks.

Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. I oppose the policy. At the risk of standing in front of and possibly being run over by the omnibus, I can’t get behind it.

I think when we made 8.3 dependent on Section 4, we did so advisably and with proper intent. There is a lot of work over many years that has gone into Section 4, and I think it is a bad idea to have the policies by which we govern transfers and the policies by which we govern allocations and assignments from the free pool diverge.

I think the extent to which they have already diverged is unfortunate and has proven to be harmful. But I’m in the minority on that. So we live with what we have. But I don’t think making it worse is a good idea.

Jason Schiller: Jason Schiller, Google. As one of the originators of this policy, I’m going to apologize for the omnibus nature of it. And I’m going to keep my comments to just the omnibus nature at this point.

The reason why it is an omnibus is because the policy is trying to do a bunch of things simultaneously. It’s trying to take care of new entrants that are holding no space. How do they work in the transfer market.

It’s trying to deal with this requirement that the paperwork and the justification of need is very difficult. So it’s trying to simplify that. So for those that had space and want more space, there’s this simply double option; show me you’re using what you’ve got and double. I thought that was fairly simple.

But then there’s this third camp, which is people that are rapidly growing, where a doubling of what they’re currently holding is less than a two‑year supply. So we need something for them as well.

So the reason why it’s an omnibus is because it is trying to do three separate things. It’s trying to help people that need to be bootstrapped that have no space, it’s trying to make it easy for people that have space that aren’t growing rapidly, and it’s trying to give people that are growing rapidly an option to grow rapidly without being too painful.

And then the fourth point is this separation from Section 4. It’s unclear to me to what extent today Section 4 applies to transfers. It seems that slow starts doesn’t apply to transfers. It seems to me that if you come in with a 24‑month‑looking future projection of need that is not necessarily supported by being twice what your last one year’s run rate is, that that’s acceptable in transfers today.

So part of the reason why this policy is so long is because it took all of the text for Section 4 and incorporated it here with some minor tweaks. It tried to make immediate need a little bit more difficult and at the same time a little bit easier, and it was trying to give immediate need some teeth.

One of the things that’s different about immediate need in Section 8 is if you can show that you’ve got things to number, those things count. You don’t actually have to get the addresses on the things in 30 days, which is a substantial barrier to entry for larger end sites.

So, again, I apologize for the omnibus nature. We talked about dividing it out. The fear was if we divided it, then maybe only one piece would move forward and not the other and that would be unbalanced and unfair.

Kevin Blumberg: Jason, I think you’ve brought up a very interesting and key point here, which is in the staff comments that came out recently, one of the bullet points is slow start is not used to assess 8.3 transfers.

So when the community is looking at 4.x and what we think, there seems to be a difference or potentially a different understanding as to what is applied in an 8.x transfer.

Mr. Curran?

John Curran: So recognize that we try to make transfers happen, not stand in the way of them. Parties will come to us and say: I wish to transfer address space based on the policy as written for ISPs, the policy as written for end users, the policy based on MDN, multiple discrete networks.

If someone can show us a policy under which they would have been issued space and the only thing that’s changing is the extrapolation to 24 months, then we’ll approve the transfer.

We’re actually not trying to get in the way; we’re actually trying to work with parties to get them through. But it does mean the entire policy body that we use for issuing allocation is available for transfers today, and that means that explaining to someone the requirements for transfers is having to explain every circumstance in which we could possibly issue address spaces and then saying but that on a 24‑month basis. It’s a nontrivial process.

Dani Roisman: Dani Roisman, SoftLayer. After I sat down, I realized you asked a good leading question. To follow up, I represent SoftLayer. We’re attempting to become an active recipient or buyer in the transfer market, and we’re concerned that the ARIN policies in 8.3 are actually going to get in our way.

And in my opinion what I’d like to see happen is if you have a willing recipient and you have a willing giver ‑‑ let’s call it a seller or a buyer if you want ‑‑ if you have two parties that actually ‑‑ again, if the recipient actually has a legal ORG registered with ARIN and is paying their dues and is a good standing member of ARIN and you have a transferrer who shows good chain of custody title and legal representation of the address space they want to transfer, I think the only thing I want ARIN to do is to get the request from them, get the approval from me, update the database, and get out of our way and let us actually grow our business.

Mike Joseph: Mike Joseph, Google. As the other co‑author of this original omnibus proposal ‑‑ I feel like I was thrown under an omnibus recently ‑‑ I would say that it was actually our intention to incorporate most of the qualifying criteria from Section 4.

In fact, if you go to slide where we talk about the 50 percent ‑‑ or the 80 percent use of space, we actually refer ‑‑ under 8.3.2.1 we actually refer to as measured under Section 4.

It was in fact our intent that any amount of space that would be considered used for Section 4 purposes is to also be considered used in this Section 8.3 and 8.4 so that if there’s something we missed there, that would be something we would have hoped to have fixed.

All that said, I would like to follow up on John’s point. You said you actually do purport to use Section 4 as the qualifying criteria for a two‑year supply, but today under Section 4 the primary qualifying criteria is historical utilization. Could you clarify if historical utilization is the primary qualifying criteria under Section 8.3?

John Curran: If you come to us and you say here’s my historical utilization rate, how much I’ve used over time, I’m going through at this rate and now I’d like an additional address block, right now we still have addresses so we actually look and see what we could give you based on a three‑month run rate.

You could say instead I’d like to get that times eight because I want to justify doing a transfer of eight times as much based on that run rate. Okay? So for parties that do have historical utilization because they currently hold address block, we’re quite happy to follow that because that’s in that policy.

Mike Joseph: However, it would seem there are recent comments on PPML that would suggest that ARIN’s interpretation of 8.3 also is inclusive of forward‑looking statements exclusively and certain requests.

John Curran: No, not exclusively ‑‑

Mike Joseph: Well, no, but ‑‑ but that one might exclusively use forward‑looking statements as justification for 8.3.

John Curran: Yes, we do have parties who turn around and say I am intending to use it; here’s my intended use. That more represents what happens more with end users, because end users come in say I need address space, and if you look at the policy for end‑user assignments, it’s based on 25 percent and 50 percent. So it’s a forward‑looking statement and it’s usually an assignment.

Both are applicable if someone comes in and does a transfer. And we’ve had parties justify under either process.

Mike Joseph: Are those transfers approved based on an historical lookback or a forward‑looking statement ‑‑

John Curran: I do not know. I’d have to go generate that.

Back to the policy, do you support the policy as written?

Mike Joseph: Yes. I wrote it.

John Curran: I understand; I’m just asking ‑‑

(Laughter.)

John Curran: Based on what you’ve heard so far, would you suggest any changes to it?

Mike Joseph: I would suggest further clarification of people’s concerns about TPIA and MDN, as Kevin clarified. We have had some discussions about this as our shepherd, but I believe some of them are actually probably addressed here. And if the language isn’t sufficient, I’d like to strengthen that language to further clarify our intent.

I know MDN needs to be worked on, but in general I support the policy for the most part as it’s written.

Kevin Blumberg: To put you on the spot, slow start, that whole portion of it, staff is saying in 4.x they’re not using that for an 8.x. Is your intention that we should continue keeping the entire slow start section that you’ve now put in 8.x or we should extricate that out and not require it?

Mike Joseph: Our intention ‑‑ I speak only for myself, obviously. The lead author is Jason, who I believe is behind me. I would say that the interpretation of a slow start‑like policy that is written into here would be my intent. It’s much more generous than traditional Section 4 slow start.

And it recognizes the limitations of essentially accepting any arbitrary representations of forward‑looking business plans by transfer recipients by requiring an actual demonstrated history while simultaneously limiting the number of transfers that would have to occur.

Andrew Dul: Andrew Dul, ARIN AC. I’d like to thank the authors for approaching an omnibus policy because I think it’s brought to light a number of issues and discussion points that the community needs to have as we move from the free pool having available space to not having available space.

The policy as they have crafted I believe is a very interesting look at how we would live in a post runout world.

However, from my perspective, I believe we’d need a simpler overall policy, not a more complicated policy. Thus, while I support the idea of an omnibus, as you asked to start with, Kevin, I’m hesitant to add the language bulk of what this specific policy is proposing.

I believe what we need to do is look at what we want as a long‑term policy and take elements of which are probably in this proposed policy to create a very simple long‑term approach to what we want our registry to do over the next five to ten years.

Thank you.

Scott Leibrand: Kevin ‑‑ I had a remote.

John Curran: Spare time, is there text you would change to this?

Andrew Dul: Yes.

John Curran: Which text?

Andrew Dul: I would be remiss if I said I had a list at this point, but I believe it is significant and I believe there are good concepts here, but as written now I don’t believe meets the needs of the future community.

Kevin Blumberg: We have a jabber.

Scott Leibrand: I have a remote comment from Kevin Otte from Flying Penguin Technologies who does not operate in Antarctica. The problem statement says: As IPv4 depletion occurs, it will become difficult for organizations to get IP addresses.

He thinks the real problem is that we’re not seeing sufficiently rapid IPv6 deployment. Sadly, it appears that the only way this is going to happen is precisely if IPv4 is difficult to get.

He therefore does not support this policy. Perhaps future IPv4 allocation needs could be tied to IPv6 allocation, maybe even utilization, to act as a stick since the carrot hasn’t been working.

John Curran: I’m closing the microphone soon on this proposal. If you wish to speak, approach the mics.

Jason Schiller: Jason Schiller, Google. I just wanted to clarify the hypothetical we were talking about earlier about someone asking for a transfer of space on a 24‑month future‑looking projection.

So imagine I’m an ISP. I get a /24 from my upstream provider. I number into it. I use it. It’s 80 percent used.

I go to ARIN. I say: I’d like a 24 as an ISP. I’m 80 percent used. The 24 I’ve got I’m going to renumber and return.

I get a /24 from ARIN. It’s 80 percent utilized on the day I get it. I number into it immediately. I come back to ARIN and I say: My /24 is 80 percent used. I’d like more, please.

I get another /24 ‑‑ or a 23 ‑‑

John Curran: 23.

Jason Schiller: Well, it depends what I ask for. I might just ask for a 24. I get a 23. It takes me two years to burn through that 23. I come back in two years and I say: I’m growing at a /24 a year. I would like to transfer in space because I need more space. I’m out. I’m beyond 80 percent utilized.

However, we now offer this whiz‑bang service where instead of just offering Internet service in Antarctica where we’re primarily located, we’re going to do it across the entire United States and Canada and the Caribbean.

And based on what our uptake is in Antarctica and the population of penguins, I believe we’re going to need a /16. And I’ve got VC funding and here’s all the equipment I’m going to buy and here’s all the circuits I’m going to lease, here’s ‑‑ my entire business plan is rock solid and I’ve got the funding. Can I have my 16, please.

John Curran: You’re an ISP. You’re asking for additional address space. You go to Section 4.2.4, ISP Additional Requests, and we have to show that you have 80 percent utilization of your most recent allocation.

You have that, right? Right?

Jason Schiller: Yes.

John Curran: So we’re going to give you the next block. You actually have a 23 ‑‑

Jason Schiller: For a transfer. I want a transfer. Can I transfer a 16?

John Curran: If you attempt to transfer ‑‑

Jason Schiller: I have a solid business case. VC funding.

John Curran: I’m trying to understand. So now you’re not coming in looking for address space; instead you want to do a transfer?

Jason Schiller: That’s right. Of a 16.

John Curran: In theory we can’t handle you under the ISP policy, but you have immediate need because you can demonstrate a business impact if you’re not going to be able to get the addresses in 30 days. And immediate need is an allocation policy that is equally applicable to you under those circumstances.

Jason Schiller: Based on my 24‑month business plan requiring ‑‑

John Curran: No, based on the fact that you said you’re going to have a business impact in 30 days if you don’t get approval.

Jason Schiller: Do I qualify for the 16?

John Curran: Are you qualified under the immediate need policy?

Jason Schiller: I’m not immediately going to have all of those customers, no.

John Curran: Well, then you wouldn’t qualify.

Jason Schiller: I’m going to have them real soon, though.

(Laughter.)

John Curran: Then you wouldn’t qualify. Then you wouldn’t qualify, Jason. Okay?

Jason Schiller: So how much do I ‑‑ how much do I ‑‑ no, no, under current policy, how much do I qualify for?

John Curran: Under current policy. Right. It depends. I have to actually look at the application. We’d have to run it through RSD and have them sit down and go through all the documentation. I do not know.

I can’t do the complete hypothetical validation of a process based on all the parameters you just gave.

My question to you is: Is there text to this policy that would make you support it? Do you support it presently?

(Laughter.)

Jason Schiller: Yes, as the originator of this policy, I support it.

John Curran: Excellent. Good to hear. Thank you.

Okay. Any other comments at the mics? I am going to close the microphone. Last chance. We’ll finish discussion. I see no one else up. We’ll close the discussion.

Thank you, sir.

(Applause.)

Draft Policy ARIN-2014-1: Out of Region Use

John Curran: Okay. We’re going to move ahead. Trying to catch up with our policy discussions. Next one is Draft Policy 2014‑1: Out of Region Use. And come on up, David Farmer.

David Farmer: This is a policy we’ve been working around for a while. Sorry, I’ll adjust the mic. Can you hear me now?

This is a policy we’ve been working on for a little while now. I’m the author. Neither of the shepherds are available for this ‑‑ they’ll be running the show at the main meeting.

Problem statement: Currently, policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. Previous attempts at limiting this have went down in flames.

So maybe the next option is come around from the other direction and can we clearly permit it.

But obviously if we’re going to permit it, what does that mean? And there’s a number of ‑‑ it’s not just, oh, you can do whatever you want.

So summary. Organizations may request Number Resources from ARIN for use outside the region. You can’t request resources from ARIN and use that same justification from another RIR. Only one at a time.

You must report utilization from the same type of resource when requesting resources greater than certain amounts there when you’re requesting resources for out of region use.

When requesting Number Resources from ARIN greater than threshold above, you’ve got to report that. That’s what I was talking about. Utilization must then need the current ARIN number policy for all resources that you’re reporting.

Discussion. There were several concerns raised in staff and legal review. There’s a request for a clarification. There’s questions about ICP‑2 alignment. There’s a number of legal jurisdiction and restriction issues. There’s the warning of a potential additional government oversight.

These go to the crux of the issue, the problem statement. We don’t either clearly forbid or clearly permit. Should we be clearly permitting and how do we rationalize this use with ICP‑2?

In case you’re not familiar with what ICP‑2 is ‑‑ okay, this isn’t the slide I had, but that’s okay ‑‑ ICP‑2 is the policy for creating a new RIR, and the proposed RIRs must operate in an international large geographic organization approximating continental size. And there should be one RIR serving each region established under a single management in one location.

And this is the link to it, and ‑‑ but the point is that this is how you create a new RIR. It’s not clear ‑‑ obviously there’s some intent here about what ‑‑ but it is not very explicit about what this means about the operation of the RIR and a number of these other things.

So mic’s open. Please, in particular, if you have ‑‑ whoops. In particular, if you have comments regarding these discussion items, I’d love to hear them.

John Curran: So the policy in your guide is on page 6. It’s the Draft Policy ARIN 2014‑1: Out of Region Use. And it has a pretty long analysis and staff assessment and the new text.

Dani Roisman: Dani Roisman, SoftLayer again, representing a multi‑national or company with datacenters across the world. I’m definitely in support of a policy which clarifies the use in region and out of region. I definitely agree with the problem statement here.

I’m not exactly very clear, though. While I appreciate that we’re trying to clarify it, I’m reading it and I’m not exactly clear what the end result is going to be.

Are we trying to say that an organization established within the RIR region should be going ‑‑ within the ARIN region should be going to ARIN for all of their IP needs regardless of where they’re used so ARIN is no longer going to be asking the question “Are you intending to use these in region or” ‑‑ I guess that’s my question.

John Curran: Let me try. Current practice, you have to have a legal entity in the region, one capable of contracting with us, but also your utilization has to be based on demand ‑‑ customers and equipment infrastructure ‑‑ in the region.

If you come to us and you have an entity located in LA and you say “My growth is entirely in the Asia‑Pacific region,” when we calculate your growth, we see a zero because we don’t see what’s outside the region.

So we literally will disapprove a transfer coming in because you have no in‑region use. We won’t issue address space and we won’t transfer in.

We talked about should that be incidental use or what if ‑‑ many times we have companies who the majority of the use is here but some of it is outside the region. We know that happens.

So in trying to clarify this, after two attempts to define what should be allowed in region and what should be prohibited, the proposer said: Let’s go the other way. Let’s say it’s all allowed.

So if you ‑‑ under this policy proposal, if someone were to come to us and say I’m incorporated in LA, my usage is entirely in the Asia‑Pacific region, or entirely within the LACNIC region, and here’s my growth rate, we would see that as valid.

Effectively, we would provide them services and provide them ‑‑ allow a transfer, provide them registry services even if they were completely out of region other than the contracting entity.

Dani Roisman: If that’s what this policy is proposing, then I support it, yes.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I don’t support this policy. We couldn’t come up as a community the last time with majority plurality ‑‑ big, large, whatever you want to call it. We couldn’t even define a number. So what do we do? We throw the bath water out with the baby and we say let’s just give up. That’s what we’re going to do.

So I’ve got two fundamental issues. The first issue is that we are asking other regions to dip their cookies in the milk a certain way because that’s how we want it.

We’re going to throw out the whole concept of regionality, completely 100 percent, and you just go along with it, which I have a real problem with.

It opens the floodgate to anybody else coming along saying: You know what? If there’s nothing regional about what you RIRs are doing, let’s just do it ourselves. And we’re giving an excuse the wrong way.

We add unbelievable complexity. Right? Omnibus into itself of complexity related to organizations and how they have to show what they’re doing globally now because we can’t come up with a simple number. And that’s what I think we need to do.

If you’re using X percent outside of region, that’s okay because we understand that that’s real. If you’re using more than that, go to the other region or put it in the other region, or whatever the case may be.

But let’s simplify this or get rid of it, because this is just an albatross.

John Curran: Yes, Kevin. If it turns out that this were to be what we had to work with, is there any change to it that would make it acceptable to you?

Kevin Blumberg: Yes. Cutting it out completely and just putting in a number.

John Curran: That’s not going to change.

Unidentified Speaker: Okay. Thank you.

Jason Schiller: Jason Schiller, Google and the ASO AC. I have three primary concerns, and I think the most important one is a follow‑up from Kevin’s point here.

The way this policy reads, it suggests that if I’m an organization and I hold resources in RIPE and I have a global network and I am primarily in the ARIN service region and I’m primarily using ARIN service region addresses and I run out of space and that space is for use in Europe, I need to disclose my RIPE resources, which I’m perfectly fine with.

But this policy also suggests that my RIPE resources have to be utilized, which I’m also perfectly fine with. This policy suggests that they have to be utilized to ARIN’s standards.

So this community is suggesting that they should tell another regional community how addresses need to be used in order to be ‑‑ in order to qualify to get additional space from ARIN.

That seems problematic to me. It seems problematic on two cases. First, that this community is asserting how another community should use their resources; but, secondly, there’s potentially an interesting corner case here where I may actually be using my RIPE space within the RIPE requirements of use.

But that doesn’t necessarily meet the ARIN requirements of use and I am stuck and unable to get addresses from ARIN because of that.

So I know you’re going to ask me “What would you change?”

John Curran: What would you change to fix that problem?

Jason Schiller: The change I would fix is there’s a statement in the text ‑‑ and if you go back to the language of the text, I could find it ‑‑ that basically says you must disclose resources used in the other region and ensure that they’re used to ARIN standards. Strike the “ensure that they’re used to ARIN standards”; just make it “ensure that they’re utilized.” And then measure them based on the appropriate RIR’s standards.

So that was my first concern. And that is a primary concern.

My second concern is this fact that we’re defining in region and out of region usage. I really want to put on the record a strong cautionary note for people to be very conservative for if the they decide to use this definition in the future for different things.

If you want to bill me differently because of the amount of resources I’m using out of region cause ARIN to do more work in verification, I’m fine with that. But if at some point in the future there’s going to be other policies based on treating in region and out of region differently, I strongly oppose and I think this language is a little bit dangerous.

I’m happy for it to move forward, but I’m noting that at some point in the future that I will stand up and say we should not treat in region and out of region use differently. That’s my second concern.

My third concern is with regard to this incidental usage. It seems kind of unfair that if you’re just taking a small amount of space from other RIRs that you get a free pass on reporting how it’s used.

I think if you’re really small and this is a hardship, you probably don’t have resources in more than one RIR. If you’re big enough to have resources in more than one RIR, it’s really not that difficult to say, oh, yes, and I have a RIPE /21 and here is how it’s being used.

John Curran: Okay.

Jason Schiller: So I think those are all of my objections.

John Curran: Thank you. Folks, please approach the mic if you want to speak. Add yourself to the queue. I’m going to be closing the queue shortly.

Mike Joseph: Mike Joseph, Google. I strongly support this policy and its intent. Although I agree with many of the concerns raised by Jason, I would say that it’s very important that we have a policy that recognizes that there are multi‑national entities already operating, that these entities are often based or have a strong nexus of operation within the ARIN service region, and that it’s important that these entities are able to continue to obtain resources from their home RIR for their global operations.

I echo Jason’s comments that it’s very difficult to adequately classify resources beyond the potential negative downstream effects of doing so. It’s hard to simply do so.

So I would equally caution against trying to distinguish between in region and out of region use. And with all due respect to my colleague Kevin, I do disagree that this throws the RIR system out.

Quite frankly, as John clarified at the beginning of this discussion, this policy does not change the fact that ARIN will serve only entities operating within their service region with the legal base of operations here, and so I don’t see any reason why one multi‑national company should not be able to go to their home RIR. I don’t think that tosses out the RIR system.

And as we’ve said in previous times, when this type of policy has come up for discussion, it’s virtually impossible to say where a /30 is actually used, and I don’t think we really need to get involved in parsing that, quite frankly.

Although I do strongly support this policy, I would equally support a policy that simply said ARIN will issue addresses regardless of location to entities legally able to obtain resources from ARIN.

I actually don’t see any problem with that. I don’t see any problem withholding space held by other RIRs as long as the resources used for those spaces is not also used to justify ARIN’s space. I think that’s relatively easy to tackle in policy.

So I would have absolutely no problem with either this policy, because I think it’s important that we have it, but if not this policy, then I would support a policy that would say you can use space as long as it’s justified based on ARIN criteria wherever you may use it.

I do have one clarifying question for staff. The policy does indicate that staff will apply a test to space that’s used outside of the ARIN region. It’s not clear to me if that test differs from the test that ARIN would currently apply to space used inside the ARIN region.

And specifically what I would like to understand is will RSD ask questions or require justification of a different nature than they would today.

Today if we turn over a complete justification package for address space, just the usual host, enumeration, pool counts, et cetera, if we include global space in that, would that be sufficient to RSD should this policy pass, or is there going to be additional further documentation required for out of region space that is not currently required for in region space.

John Curran: So you ask an interesting question. We currently do have people who justify, and they do include utilization of address space in other regions. That’s what’s led to what is the right ratio of what’s acceptable outside of region. We’ll continue to do that.

Regarding under this policy what we’ll do as one of the policy proponents, I recommend you put language in that tells us what you want us to do.

Jason Schiller: I’m interested in understanding how staff interprets the policy as written.

John Curran: We would continue the current practice. Doesn’t say specifically otherwise.

Unfortunately, Jason notes that it has us applying criteria to address blocks that are issued and managed by other RIRs. If that’s not what you want for practice, you should change the text.

Jason Schiller: I would prefer something else, but I think getting something like this ‑‑

John Curran: Make it more specific, then.

Jason Schiller: As long as we don’t derail this policy. Thank you.

John Curran: Yes.

I’m going to close the mics in ten ‑‑ get to the mics if you’re going to get ‑‑ five, four ‑‑ Jason, I see you ‑‑ three, two, one. Mics are now ‑‑ the queue’s now closed and just the people at the mics.

Go ahead.

Peter: Peter (indiscernible) at ADREX (phonetic). We actually don’t have a position on this policy. We want to provide some clarification and some information.

Currently at RIPE there are dozens ‑‑ and I mean dozens ‑‑ of LIRs that are based in the United States that have space issued to them by RIPE. They’re used solely in the United States. They get them. Absolutely the way that they do it.

So the idea that somehow the other RIRs aren’t doing this, RIPE has ‑‑ and you can (indiscernible) the whole list. You can look at all the LIRs that are in the United States and you can see that they have registration. They maintain it in their US address. And you look at their geolocation; it’s entirely used in the United States.

Many of those were people who refused space by ARIN and just went to RIPE and got it. This is already going on. This is a current practice you guys should be fully aware of.

John Curran: Very much so. That’s why it’s up to this community to figure out what they want the practice for this region to be.

Peter: But it is already being done completely with full transparency in another region.

John Curran: Agreed.

Rhonda McFadden: Rhonda McFadden, Wells Fargo. I feel rather ill‑prepared compared to what everyone else has been saying here. I don’t necessarily have an opinion on pro or against, but I do have some questions or comments about whether or not some thoughts have been taken into consideration.

When we talk about RIRs and the different international locations, I can’t help but think that we’re infringing ‑‑ some of the decisions that we’re thinking about here that we’re not infringing on our RIR peers and whether or not we’ve taken into consideration what their roles are or whether or not a larger governing authority has taken those things into consideration.

So thank you.

Joe Provo: Joe Provo, Google. I support the intent. Strong nod to Jason for actually having parsed out some of the language errors, and I agree with them.

And I just wanted to raise the historical point that in addition to the existing practice of registry shopping, that when putting ‑‑ matching my gray hair to my colleagues here, when we set up this RIRs thing, it was all about where the entities were incorporated, where their locus was, not about deployment end use. And that was utterly orthogonal.

We’ve sort of kind of backed into that existing, and I think it’s a bad thing. So we should clarify it.

John Curran: Joe, don’t get away that easy. Given there’s a policy proposal on the table, are you in favor or against it? And is there anything, if you’re against it, that you could change to make you in favor of it?

Joe Provo: I will be much more clearer than I was. I support the intent. I believe there are language issues and my colleague Mr. Schiller has identified the bulk, if not all, of them.

Jason Schiller: Jason Schiller, Google. If you put up the policy text, the second paragraph ‑‑

David Farmer: I don’t have it on the slides ‑‑

Jason Schiller: Don’t have that? Okay. The thing that concerns me is the last sentence, and I’ll read it: “The report must demonstrate that all resources currently available for use within the requested service region are efficiently utilized based on applicable ARIN policy.”

One possible suggestion to get out of this problem is to change “ARIN” to “RIR.” The other suggestion to get out of this is to completely strike the last sentence and replace it with the inverse of the first sentence of that paragraph.

Not that the first sentence should change. That should stay as well. The first sentence reads: “The services and facilities used to justify the need for ARIN resources that will be used out of region should not also be used to justify resource requests from another RIR.”

If you strike the last sentence, you need the inverse statement of this as well, which is: You will not use these to justify ‑‑ you will not use ‑‑ basically it’s no double counting, but it’s no double counting in both directions.

So I think your options are either simply disclose all of the RIR resources that you’re holding so that we can be sure you’re not double counting, or we will look at all of your resources and make sure that they’re justified per the RIR that issued them. I think those are your two choices out.

John Curran: Jason, do you have a preference for those two approaches?

Jason Schiller: Whichever the community finds more palatable.

John Curran: I want to note when you look at those two approaches, one of them would have ARIN applying other regions’ policies again to resources in another region. So that means that Einar and I would get to become intimately familiar with RIPE, APNIC, LACNIC, and AfriNIC policies to make sure that someone coming to ARIN was also meeting those policies for all of the resources in those regions.

The staff assessment for that particular approach will be an interesting staff assessment.

Jason Schiller: There’s a balance here. The question is how comfortable is the community with the possibility that somebody could, assuming they’re not double counting, because we’ve taken care of that issue ‑‑ how comfortable is the community that someone could go to another RIR, get a block of space and before they’ve actually used it come back to ARIN and ask for a block of space for a different purpose.

Is that problematic? Is it problematic that I go to the well potentially five times and none of them have to be utilized until I come back for my sixth try at the well?

So if that’s really a concern, the only way around it is for either ARIN to do the review or for ARIN to reach out to their colleagues at other RIRs and ask for a go/no go.

John Curran: You should suggest policy changes based on which you prefer.

Jason Schiller: I’d like to hear which would be preferable.

David Farmer: We’re going to continue to discuss this later in the week. If you’re around, please come. Myself, Bill Darte, and Milton Mueller ‑‑ Milton and Bill Darte will be here tomorrow or the next day ‑‑ please talk to us in the hall, around, and give us your opinions. And please talk about this on PPML.

Thank you.

Unidentified Speaker: And just remember there is a room available to us if you want to continue discussion right after this meeting or anytime today. Don’t hesitate to find me or one of the shepherds to line that up if you would like to continue discussing any of these ideas today.

Draft Policy ARIN-2014-16: Section 4.10 Austerity Policy Update

John Curran: Next up is Draft Policy ARIN 2014‑16: Section 4.10 Austerity Policy Update. And we have Dan is coming up.

Dan Alexander: We’re almost there. Only four left.

So I’m going to skip by a couple of these slides in the interest of time because several of the slides just repeat what’s in the Discussion Guide, which it’s on page 16 of the guide for those who want to follow along, which the problem statement and the policy statements cover.

But what I will go through is essentially what this proposal is suggesting is there’s a Section 4.10 of the Policy Manual that carves out a /10 of address space for transition technologies. It’s intended for when we run out of the free pool that there would be blocks remaining behind that organizations could obtain for transition technologies like NAT and 6 to 4, things like that.

What this proposal originally was was it was going to change that particular section and change it into an austerity section where organizations would be able to get small blocks of address space and not necessarily for transition technologies. It was a shift of being limited from transition technologies towards just an austerity allocation for new entrants.

The original draft of this suggested that the whole section be replaced. But the previous meetings, the feedback that was provided was a lot of people disagreed with that and they liked the transition technology section to remain.

So the current version of this draft splits the two out and says, okay, we’re going to retain the transition technologies but we’re also going to create the austerity section. And what it had proposed was it would split that pool into two and provide half for each purpose.

The other aspect of this is in addition to the /10, future allocations from IANA would also go to fund this pool of address space.

So some of the feedback that we’ve received so far was ‑‑ one was just a general cleanup matter of removing the trigger event since that has already passed. So it’s kind of old language that we could clean up, which is not a problem.

But some of the other feedback is a number of people did not care for the pool being split and that the /10 should be retained for the transition technologies.

So interested in more feedback here in the room as far as do people support or oppose this; if so, what kind of changes would be made.

Because right now, given the feedback we’ve seen, we’re considering abandoning this unless there’s a clear voice for the other direction.

So let the discussions commence.

John Curran: Microphones are open. Please don’t rush the microphones. If anyone would like to speak in favor or opposed to this, reasons why it should continue, reasons why it should be jettisoned.

Owen DeLong: Owen DeLong, Black Lotus Communications. I’d jettison it. I don’t think that we want to take away from the transition pool to fund this. I’m not sure if there’s another source of funding available. I’m not entirely opposed to an austerity pool, although I don’t see a lot of purpose to one.

I think we should just recognize that we have a limited free pool and when it runs out, it runs out. And we all should be getting on with v6, a long time ago, actually.

Andrew Dul: Andrew Dul. I’m the author of this proposal. This was created based on discussions we had in Chicago around the need to fix some of the issues in the current policy when the free pool runs out.

Based on what I’ve seen and heard from this community so far, they don’t seem to believe that we need to fix that issue in this way.

And at this point I would not support the second bullet point on the slide to leave the pool reserve for transition technologies only and still have this policy, because this policy would be ineffective without actually having a substantial pool to do anything with.

So unless we’re willing to split the pool, then we should not do this and continue. And from what I have seen on the Mailing List so far is that this policy idea, while hot in Chicago, is no longer hot. So maybe we should just move on.

John Curran: It would appear to be a dull proposal.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I support abandoning this proposal. We have an austerity policy. Get your IPv6. You’ll get your v4. Bootstrap.

If the numbering is a little off, if another region gets your 22 and we’re only at 24 right now maximum, we can talk about that later on when it becomes a sore point.

But we actually do. The community really wanted v6 to be the austerity policy and you will get your v4.

Scott Leibrand: One remote comment. Kevin Otte says: I support abandonment. The wall has been getting bigger in the windshield for years. Removing the airbag isn’t going to help.

(Laughter.)

John Curran: Okay. Any further comments?

Mike Joseph: Mike Joseph, Google. I oppose this policy and seems to have arrived at consensus at that point.

I would clarify that one of the other concerning aspects of the policy is the /28 part of it. I realize that’s in there already for transition technologies, but I think that would be a very bad precedent to set for new assignments and allocations under austerity.

So if this policy by some miracle were to advance, I would suggest that number be adjusted.

John Curran: Understood. Jason, you’re going to come explain why this needs to be saved?

Jason Schiller: Jason Schiller, Google. I support abandoning this policy. If it ‑‑

John Curran: Okay. So ‑‑

Jason Schiller: ‑‑ was not to be abandoned, the thing that would really concern me is that all returned space, either to the IANA or to ARIN, would then go into this pool, and I think that that’s a terrible idea.

John Curran: Okay. Thank you.

I’m going to close the mics if no one else has a comment. Microphones are closed.

Thank you, Dan.

(Applause.)

Draft Policy ARIN-2014-17: Change Utilization Requirements from last-allocation to total-aggregate

John Curran: Okay. Next up is Andrew. ARIN 2014‑17: Change Utilization Requirements from Last Allocation to Total Aggregate.

Andrew Dul: This one hopefully won’t be dull.

Unidentified Speaker: If not dull, at least fast.

Andrew Dul: So this policy is all about fixing an issue that we currently have with small organizations around the three‑month assignment window and one block not being full and not meeting 80 percent but still ‑‑ but you have a need for something a little bit larger but not quite getting there.

I’m trying to run through this really quickly.

So the way that this currently is worded is instead of doing 80 percent in the last block, we do 80 percent overall. That’s how the policy would be changed.

So in this staff and legal review, the staff noted that this has the potential to allow organizations who currently have a lot of space to automatically qualify for a lot more space and that could be a way to drain the free pool very quickly.

Legal noted that there appears to be an inequity between larger and smaller organizations because of the same issue that staff noted.

So how do we potentially fix the issue that staff and legal noted? There are three ideas here. Your feedback is wanted on these three ideas.

The first idea is about delaying the implementation of policy so that the free pool is empty. This really ‑‑ you can’t drain the free pool. So there you go.

The second one is (indiscernible) requirement that any one block be utilized at 50 percent. So the delta here is changed from a gigantic number to 30 percent.

And finally the other, the third option, is to limit the policy to organizations which have less than a /18. And that number is a derived number that is not necessarily of significance.

Jason is having a large question coming my way.

Jason Schiller: Jason Schiller, Google. I think I’m parsing this wrong. The second bullet there means that no block can be under ‑‑ if any block is under 50 percent, you don’t qualify?

Andrew Dul: That’s correct.

Jason Schiller: Okay. Because I don’t think that’s what it says. I think it says that only one block has to be over 50 percent.

Unidentified Speaker: I think that should be just an additional requirement.

Unidentified Speaker: Every block must be ‑‑

Andrew Dul: The wording on the slide is rough. Sorry about that.

Jason Schiller: Got it. Thank you.

Andrew Dul: So the discussion we have about this is: Do you believe that the current utilization requirements need to be changed at all? Do you think this is a problem we need to be working on fixing? Do you see the need to mitigate the issues that have been raised by staff and legal? Or should we just move forward with the known issues? And, of course, do you support any one of those three options and do you support this policy draft?

So let’s get to the discussion.

John Curran: Microphones are open.

Mike Joseph: Mike Joseph, Google. Could you go back to the slide that Jason was asking about a second ago?

I agree that clarifying the 50 percent thing would be beneficial. I have no concerns about a 50 percent requirement, but I’m quite concerned about the third bullet point. I think that creates a horrible inequity, and it’s not clear to me how this policy is meant to hugely advantage larger operators over smaller ones.

I hear that that’s a staff concern and a legal concern, I’m not sure I buy it.

Andrew Dul: In the staff comments there’s an example. Have you looked at the example and you believe their example is not feasible or ‑‑

Mike Joseph: I’m not sure ‑‑ let me take a closer look at that example. But I think in general any ‑‑ I’ll say this. It’s easily proved that any ‑‑ I mean, if the example is the /24 ‑‑ I mean, are you talking about the /24 thing?

Andrew Dul: No.

Mike Joseph: Okay. It’s a different example.

Unidentified Speaker: Is the example in the Discussion Guide?

John Curran: It’s in the Discussion Guide. Let’s see. There’s ‑‑ you’re talking about the 80 percent utilization for smaller ISPs. Staff has seen a situation where a small ISP with a /22 may need to issue a /24 to a customer but not have any available but not be at 80 percent utilization.

Talking about why the need for the policy at all? Or are you talking about the ‑‑

Unidentified Speaker: This part here.

John Curran: Okay. There are two examples in the Discussion Guide under the Staff Comments. One, an ISP close to 100 percent utilization on its multiple prefixes who immediately has 25,000 /24 equivalents and received a /16, even though they just received the 16, because they’re so heavily utilized on their prior holdings, they still qualify again for the Number Resource.

Mike Joseph: Yeah, I get that part. But the challenge I have with that is it’s not actually unfair. We’re penalizing a large operator that has been incredibly efficient at utilizing their address space for simply not having drained the free pool earlier.

Moreover ‑‑

(Laughter.)

Mike Joseph: ‑‑ even if I got that, it would simply be a renumbering exercise for me to then move customers into that block. It’s really just putting an unusual burden on the large provider who has a really efficiently used /8 or what have you in that case.

John Curran: So the Staff Comments notes it’s a possibility of occurrence. It doesn’t put a value judgment on whether or not the provider who has been late to draining the free pool is good or bad. We just note it’s a possibility.

Mike Joseph: Fair enough. I posit that it’s not a bad thing.

Andrew Dul: It’s not an inequity that you believe needs to be remedied.

Mike Joseph: No, I don’t. And I think the /18 point here would be a very bad thing.

In general, however, I support the intent and wording of the policy.

Andrew Dul: Do you support the idea of the first mitigation, the second mitigation, or none of the mitigations?

Mike Joseph: I definitely support the second mitigation. I don’t think I support the first mitigation.

Again, I’m not sure what the value is in adding that. I don’t see this risk that I think others seem to see here.

Unidentified Speaker: You think we need a mitigation (indiscernible).

Mike Joseph: No, I don’t think we need a mitigation for large holders. I think the second one is actually not a mitigation for large holders. I think the second one is a policy clarification.

John Curran: So you don’t believe we need that mitigation. Would you support the policy proposal as provided?

Mike Joseph: I would. I would equally be accepting of the 50 percent change.

John Curran: Thank you.

Owen DeLong: Owen DeLong, Black Lotus Communications. I support the policy as written. I could accept either of the last two mitigations. The first mitigation is something which we are well on our way to achieving merely by delaying this policy yet again, which is why I put forth a motion, which unfortunately went down to defeat on the last or second to last AC call to advance this to Recommended Draft.

We need to move this forward. There are real organizations that are really suffering from the current situation where they have customers that they need addresses for and they can’t get those addresses because the customers that they’re now acquiring have a greater need for address space than what’s left in their available address space, but they’re so small that they can’t get to 80 percent with the utilization that they have and they can’t assign what they’ve got left to the customers they’ve got coming in because those customers are larger than the small chunk they’ve got left.

We need to fix that. We need to make it possible for people to move forward and look at their aggregate utilization as a very good way to do that cleanly. Fragmentation happens. It’s a harder challenge for smaller organizations than it is for larger organizations.

But it’s a challenge all the way around. So whatever we do, let’s do whatever we’re going to do and move this policy forward. Waiting until the free pool is empty is merely a way to say that the people that are currently victims should always be victims.

John Curran: I’m closing the microphones. Please approach the queue if you want to speak on this.

Leif Sawyer: Leif Sawyer, GCI Alaska, AC candidate, and original proposal author. My bad that I didn’t add in the Modification No. 2, but with that in there, I wholeheartedly support this.

John Curran: I’m closing the queues. Ten, five, three, two, one. Okay. That ends our discussion.

Andrew, thank you very much.

(Applause.)

Draft Policy ARIN-2014-18: Simplifying Minimum Allocations and Assignments

John Curran: Okay. We have two more to go through, and we have 11 minutes. I think we can do this.

So the next ‑‑ R.S. is up. And it’s Draft Policy ARIN 2014‑18: Simplifying Minimum Allocations and Assignments.

Rob Seastrom: There we go, okay. Draft Policy 2014‑18: Simplifying Minimum Allocations and Assignments.

So we figured in the interest of making this simple we would put a slide up with the gist of what the proposal is as far as the AC understands it.

We believe that the idea here is to remove the needs test for small allocations of /24, possibly larger, depending on the current state of minimum allocations elsewhere in policy, and impose a rate limit of once a year under this policy.

This is the problem statement, and I will engage in the unusual behavior of actually reading the slide because the print is smaller than I would have liked: “New and small organizations are having a difficult time receiving resource allocations from ARIN because of the economic, administrative, and time burdens of making their way through ARIN’s needs testing process.

“For small allocations, the burdens of needs testing may exceed the value of the resources or may deter small, less well‑funded organizations’ ability to receive an allocation from ARIN.

“As ARIN was created to provide Internet resources to all organizations within its geographic territory, this disparity in the Policy Manual needs to be addressed.

“The problem can be remedied by removing needs testing for any organization that applies to receive the current minimum block size allocation.”

The policy statement is inserted into the NRPM possibly as 4.2.1.7: “A minimum IP allocation size has been defined per Section 4 of the ARIN Number Resource Policy Manual. Regardless of any policy requirements defined in any other active section of the Policy Manual, all organizations may apply and shall automatically qualify for the current minimum IP block application upon completing the normal administrative application process and fee requirements, and all organizations shall be eligible for such an allocation once every 12 months.

“Where this is in conflict with any other section in the Policy Manual, this section shall be controlling.”

So we’ve made some observations so far. First is that there’s some support for loosening needs‑based numbers policy. That’s across the board. This is one of multiple policies to the queue.

The question for people here assembled is: Is this the right approach?

One of the questions that arose, though, immediately is: What’s a minimum allocation anyway? Are we at /24 everywhere?

I paid pretty close attention to this, and I can’t even tell you off the top of my head without referring to the NRPM.

This is likely to have unintended side effects, this ambiguity.

How does this rate‑limited approach interact with other policy? Does order of execution on the requests matter? Can you ask for this and then have it counted later or not counted? Can you ask for your nonjustified after you justify? We don’t understand.

“This section shall be controlling” verbiage might turn out to be a difficulty.

On the Mailing List, we’ve had a little bit of support and a fair amount of opposition.

Speaking as the shepherd on this, I’m inclined to move to drop this policy proposal if there were not some signs of support for it. So particularly if you support this, I’d like to hear from you.

So let’s discuss.

John Curran: Microphones remain open. No one has any opinion about this either way?

Peter: Peter ‑‑ this is Peter (indiscernible), ADREX. I don’t have a position one way or another, but I do want to clarify back to what I pointed out earlier that probably that problem has been going away because many of these small companies are just going to RIPE and they qualify.

And they are getting the space from RIPE. So many of the new members at RIPE who get the final 22 are US companies.

So they’re solving the problem themselves.

Rhonda McFadden: Hello. Rhonda McFadden, Wells Fargo. I just question is this minimum allocation for anybody? I mean somebody like me, with all the 16s I have, I can just come and ask for a new 24 every year? Or is this for new entities?

Rob Seastrom: That was my understanding of the intention, yes; that regardless of justification, previous holdings, et cetera, that you could come and ask for a /24 and that it would be available to you.

This policy proposal does not differentiate between free pool and transfer market. So one would assume that it would apply equally to all of them.

Rhonda McFadden: So, again, just thinking things out ‑‑ and forgive me if I’m lacking some knowledge base here ‑‑

Rob Seastrom: No, please go ahead.

Rhonda McFadden: ‑‑ I would think a policy like this would be primarily intended for the benefit of smaller companies and companies that don’t currently have a presence. I would think that those are the people that you need to get them online and get them involved in the Internet now if they don’t have the resources or money to do IPv6 yet.

And so I would question whether we wouldn’t want to say “new” allocations or whether it’s even worth considering the policy at all.

Rob Seastrom: It does speak about coming back once a year.

Rhonda McFadden: And I do appreciate that. I think that that’s a ‑‑

Rob Seastrom: Would you be opposed to that on the basis that you get your first allocation and that’s it; that from here on out, since now you’re part of the haves, even though it’s a small have, as opposed to the have‑nots?

Rhonda McFadden: I think that that’s worth considering. And that is one of the criteria that I did appreciate in here is you don’t want somebody just dipping in the well, dipping in the well, dipping in the well. You want to encourage people to move to v6.

So that’s where I question a bigger entity, like myself, do I need to be coming back to dip in the /24 pool? Not to say that I might not need that. And I might regret saying this later when I apply for more space. But my point is that we need to encourage those big organizations to move towards v6 and it’s those little organizations that need that step on to the Internet and the opportunity to partake in the availability of services, merchant opportunities.

Rob Seastrom: Thank you.

Unidentified Speaker: I just want to take a quick second to tell Rhonda: Rhonda, you’re definitely part of the knowledge base and exactly the people we’re looking to hear from here. Thank you.

Mike Joseph: Mike Joseph, Google. I strongly oppose this policy. I believe that this obviously is a toss out of needs basis. I think as a community we’ve pretty clearly indicated we want needs basis, particularly from the free pool. And the nature of this policy encourages further fragmentation.

To allude to my previous comment on a different policy, on this one you don’t even need a “buy it now” button; you just need to ask ARIN.

And I think that this will mean that there will be dozens and dozens of 24s showing up every week if this policy were to pass because every organization would simply start asking for them, whether or not they have any use for them.

In fact, there’s no controls in this policy that prevent them from selling them. Obviously, of course, there’s controls on 8.3, but I see little reason to funnel 24s randomly because somebody thinks it’s convenient.

I also question again, as with the previous policy, this one holds out the bogeyman of filing requests with ARIN as being somehow overly onerous or impossible to manage, and I just have never seen evidence that that’s the case. I’m not saying that all my transactions with ARIN go smoothly. Certainly there are challenges from time to time. But for any business that has to operate, dealing with ARIN is likely to be the least of their administrative hassles.

So I oppose this policy and I’m heartened to hear that it sounds like our colleagues at RIPE have solved this for us.

(Laughter.)

Leif Sawyer: Leif Sawyer, GCI, Alaska. I think this could be rewritten as ‑‑

Unidentified Speaker: So you’re volunteering?

Leif Sawyer: ‑‑ as ARIN will automatically hand every member a free /x at Christmastime and it would be equivalent.

Unidentified Speaker: (Indiscernible.)

Leif Sawyer: Hanukkah. Sure.

(Laughter.)

Leif Sawyer: I move to abandon.

Rob Seastrom: Not quite to that point yet, but thank you.

Owen.

Owen DeLong: Owen DeLong, Black Lotus Communications, ARIN AC. I support abandonment of this proposal. I take issue with the problem statement. The claim that ARIN’s process is so onerous that getting a 24 is more difficult than what the 24 is worth is patently absurd in my opinion.

I have done many applications for many very small businesses over the years and gotten many /24s and 22s and whatnot from ARIN on their behalf without any tremendous difficulty in the process.

And even under the current framework, which is more difficult than it’s ever been in the past as a result of paranoia over exhausting the free pool, which I think will be more of a relief at this point than anything else, it’s still not that hard. It’s just not that hard. Especially if you’re just trying to get a /24.

In answer to your question about what is the minimum size, yes, that was ambiguous until about the middle of September. But with the publication of the latest NRPM, it is in fact a /24 throughout all of Section 4.

Rob Seastrom: And one hopes it would not change out from under us as we were to be implementing it.

Scott Leibrand: I have a remote. Marla Azinger from Frontier Communications says she disagrees: Both small and large companies need to be pushed onto IPv6 equally and given IPv4 on an equal basis. It’s just as hard for a large entity to go IPv6 as it is a small company due to money and complexity. Also, it doesn’t help a large entity convert to IPv6 if all the smaller companies they provide service to are only using IPv4.

She’s not in support of this policy.

Jason Schiller: Jason Schiller, Google. Oppose. I want to follow up on Owen’s point how hard it is to get a /24. I want to point out this policy was originated prior to what happened in September, making the minimum a 24. I think part of the originator’s concerns in this case was this dance they had to do to get to upstream providers and get an ASN and show that they’re multi‑home in order to qualify to ask for a 24 and then get their 24 and then cancel their other upstream and stop using their ASN.

And I think a lot of this changed in September when the minimum became a 24. And my read of PPML is that most of the people that were pushing for this policy backed away after the events in September.

So I think there’s probably very little need for it at this point because of the minimum being lowered to a 24. At least that’s my read on PPML. And I’d like to hear from anyone who believes that to be different.

Rob Seastrom: Any other comments, specifically dissenting comments, maybe in favor?

John Curran: I’ll be closing the microphones soon. If you want to speak on this or respond to Jason’s question, please approach the mics.

Okay. Microphones are closed.

Thank you, R.S.

(Applause.)

Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization

John Curran: Andrew, come on up. We have our last policy, and it is Draft Policy 2014‑19: New MDN Allocation Based on Past Utilization.

And this is now officially lunch. Go ahead, Andrew.

Andrew Dul: Okay. Power of lunch. Okay. So we recently updated the MDN policy to clarify some questions that staff had. And based upon the new policy, we have a requested change to the recent change.

The idea here is the previous policy proposed two methods for determining site sizes for MDNs, and we’re adding a new method to determine the site size.

Currently the only way you can get an allocation for a site is via immediate need. But it’s not always possible for organizations to complete that within the 30‑day timeframe for what they need. So this policy is proposing a different method.

The method is at the bottom of the slide in bold: A three‑month supply if there is an applicable one‑year utilization rate specific to the use to be covered by the new MDN on which to base a three‑month supply. So that is the change. All the rest of the text is basically the same. There’s a little formatting difference, but basically the same.

And so the questions we have for you today is do you support this new change to add a third option for justifying a new MDN site and if you have any comments on this new text.

John Curran: Microphones are open.

Martin Hannigan: Martin Hannigan, Akamai Technologies. Thank you, Andrew, but I’m curious: Where did you get the terminology “Regions” in the examples?

Andrew Dul: Regions in the examples.

Martin Hannigan: So in the text it says ‑‑ in your problem statement you use terms ‑‑ so you say stuff like “It is also anticipated that half of Region 4 will be shifted to Region 5.”

Andrew Dul: I believe that’s an example that the author proposed for reason to justify why this is necessary.

Martin Hannigan: Who is the author, if you don’t mind me asking?

Andrew Dul: Jason is the author.

Martin Hannigan: Okay. The second question that I have is ‑‑ again, we’ve had this argument multiple times, but do you care to elaborate on what “evidence of deployment” is? And are you really saying that companies or networks should go deploy equipment without any belief that they’ll get addresses and potentially they won’t get the addresses and they just wasted their capital deploying significant amount of equipment to provide evidence that may not even result in the issuance of addresses?

Andrew Dul: The intent of this is to make it easier for organizations to work with ARIN so they get the space they need when they need it, and “evidence of deployment” was the language that was agreed upon in the last policy change.

Martin Hannigan: It was agreed by some folks. I was at the PPC where we discussed this, and there was quite a bit of disagreement on the term and the definitions.

Andrew Dul: I would agree there was a discussion about that, but the AC believed we had come to consensus on the term and moved that policy into the text now.

Martin Hannigan: I’m done talking. I’m opposed to the proposal, and I am extremely concerned. The theme recently from the ARIN AC seems to be about limiting and limiting our growth and our ability to grow our networks. So it’s very concerning.

John Curran: Martin, this is John. Got a question. Would there be a change to this policy? Is there a change to this policy that would make it acceptable?

Martin Hannigan: No.

John Curran: Okay. Thank you.

Jason Schiller: Jason Schiller, Google and the originator. I’ll try to answer your question, Marty. The question was with respect to “Region.” Region was a construct that was part of the original MDN policy. There was an issue where an ISP had fragmented their network topologically into different regions that were growing at different rates. So they wanted each region to be looked at independently.

But there was also a concern from the community that there might be a number of regions that are underutilized, and it would be hard to top up a growing region when there’s a bunch that’s underutilized because really you just screwed up your IP allocation plan and you need to renumber some stuff.

So the original MDN policy was sort of a compromise to recognize that there could be topologically significant regions within a network, that they might have different growth criteria, and that if you’ve done your work well enough, you should be at least 50 percent utilized on average before you need to top up any one region.

So that’s the pre‑existing MDN policy. That’s the pre‑existing use of the word “Region.”

The way it was intended here is in that same use. The point I was trying to make was there might be cases where you have an existing MDN regionalized network with years of growth behind it and you might be creating a new MDN, new region. You might actually have data to back up how much address space you’ll need over the next quarter.

And that might be more than what you can get under the other choices, which is the minimum allocation size under 14.1.5 or the immediate need under 14.1.6.

So did I answer your question?

Martin Hannigan: Yes.

Owen DeLong: Owen DeLong, Black Lotus Communications. I support the policy as written. I am confused by Mr. Hannigan’s comments in that I think this is seeking to make it easier for people to get addresses for a new discrete network rather than harder. I think it’s harder to lower the thresholds and challenges, and I don’t see it as trying to restrict growth or restrict people’s utilization.

I think the lack of IPv4 address will do a good enough job on its own as we move forward and that’s why people need to get to v6.

But in terms of this policy, I think the proposal is helpful. I think it solves a real problem, as Jason has described, and I think that it supports further growth rather than inhibiting it.

Unidentified Speaker: Remote participant.

Martin Hannigan: Owen, I don’t disagree with you at all. My concern, though ‑‑ and then my experience with ARIN is that when there are vague terms in policy, that there are creative applications and implementations of the policy.

So I would urge you, if anything, first to bend to this and forget it; but, second, if you won’t, which I don’t expect you will, that you should be extremely careful with the vague term “evidence” and what that means and what that means to operating a network. Thank you.

Andrew Dul: Marty, question for you. As the current phrase “evidence of deployment” is already in the policy now, in the Policy Manual now, what would you suggest in terms of changing that language?

Martin Hannigan: So to be clear, I opposed the language in the first place, before it was inserted. I want to reiterate that.

Secondly, if you operate a network, you understand that it costs money to deploy routers and machines and sign contracts for datacenters and enter into agreements for capacity.

And without some expectation that if you follow the process, you will get the addresses, it’s a hard task to deploy, for example, in my case, millions of dollars of capital and only to find at the end of that endeavor that there’s no light at the end of the rainbow or no pot at the end of the rainbow, so to speak.

John Curran: Just to respond to be clear. The policy that we’re talking about actually took effect September ‑‑ is Leslie here?

Martin Hannigan: That’s right. And that doesn’t mean that I can’t continue to oppose that language since it’s come up here.

John Curran: I understand. What I’m saying is to my knowledge I don’t think anyone’s been processed under the language “evidence of deployment.” It actually is more precise than we were prior being required to do, which is we were in the situation of not being able to say what we were looking for.

Now, rather than actually asking for whatever arbitrarily might come to mind, we’re asking for evidence of deployment, which in almost every case we’ve already been provided by people under MDN policy. It’s just we didn’t have a phrase that encompassed it.

People who bought equipment or have done POP contracts or have done upstream contracts or have done colocation contracts have evidence of deployment.

And so I’m all in favor of tighter definition of what that term means, but I guess I don’t know of any ‑‑ we haven’t had anyone actually complain about the use of the term yet.

Martin Hannigan: Second time around. Thanks.

John Curran: Could you suggest a policy to improve that language? Because it’s only been in effect a month. That’s what I’m trying to get at.

Martin Hannigan: I understand, but how many times do you have to object?

John Curran: Well, if you can provide language of what you want us to look at during an application, that would help.

Mike Joseph: Mike Joseph, Google. Marty’s concern about the existing language notwithstanding I support this policy and would like to highlight to the community that this policy is simply about splitting an MDN.

You have some number of MDNs; you want to split one; this policy quite simply describes how you would do so and determine the size of the prefix to which that new MDN is entitled.

It doesn’t change anything about evidence. Doesn’t add restrictions. In fact, as Owen points out, it makes it easier. And there are networks out there with MDNs who already have run rates, and there’s no question about deploying new equipment.

Without knowing the users there, this is ‑‑ you have equipment. You have users. You want to split it. And this policy makes that easy to do, and I support it.

Jason Schiller: Jason Schiller, Google. I want to point out that this is not a Recommended Draft. So it’s not moving forward in this cycle. So the text will unfreeze shortly, and there is a chance to revisit this vague term. And if we think there’s a better term to put in there instead of “evidence of deployment,” there’s certainly going to be a window that opens up for that.

If we think there’s a better terminology or better phraseology or definition, I would not be opposed to tackling that alongside this policy.

Martin Hannigan: Just to be clear, I’m not objecting two policies or cycles ago. You’re moving language from A to B, including that text, and I think regardless of the problem statement that any of the text is open for objection or modification.

John Curran: Absolutely.

Martin Hannigan: I want to be clear it is a legitimate objection.

Second, what would you replace it with?

Andrew Dul: I have not spent time worrying about this yet because I believed we had found a good place ‑‑ we had found a good set of text and that I had not heard of any issues with the current phrasing.

So if there are issues with the current phrasing, then I’m happy to actually hear them and listen to alternative text phrases to replace that.

So if we don’t like “evidence of deployment” and we think that is too strict, based upon how ARIN is applying doing allocations or assignments, then let’s come up with the new text that works for us.

So…

John Curran: I will go a different direction. Same thing I said when the original phrase came up. I would be a huge supporter of an adding of an element of definitions that says: Evidence of deployment. This is documentation or something to the effect that shows that some equipment or services or contracts have been entered into such as A, B, C, D, E, F, G, et cetera.

Right now we’re ‑‑ as ARIN staff, as we said in the Staff Comment when this first came around, we’re going to do our best to try to take the essence of that and apply it. But it’s always better if what we’re applying is actually specific and is what you want.

I don’t know what you think would be good evidence of deployment that we wouldn’t consider. But I would prefer it now and have it in a definition so we can just say yes.

Martin Hannigan: Sure. And I think you have my feedback, and I think that there are at least one or two network operators on the AC that could probably come up with some reasonable terminology that would be a little bit less offensive or ‑‑ not offensive, but onerous than this.

And, again, this is based on my experience and with multiple applications for addresses with ARIN. I can send contracts all day long. I don’t believe they understand a word of what I’m sending. And I don’t believe I should be required to have contracts in place for locations that I don’t have some reasonable assurance that if I follow the policy that I’m not going to have a surprise at the end and not get the addresses. Thank you.

John Curran: Fair enough.

I’m going to close the microphones. Approach the queue. Last call. I’m closing the queue in ten, five, three, two, one.

Queue is closed. Thank you.

Thank you, Andrew.

(Applause.)

Closing Announcements and Adjournment

John Curran: A couple of things. We’re now closing. Thank you, everyone, for coming. There’s a room available. If you wish to get together with some of the AC members or the various shepherds and work on any of these, there’s a room available to do private meetings.

For those who are going to be here Thursday, we’re going to be talking about these policies again. Hopefully we’ll see some improvements and we’ll get closer to where we’re going.

I’d like to thank everyone for participating in the PPC. Hopefully this will help everyone in the evolution of policies.

Thank you very much.

(Applause.)

(Meeting adjourned at 1:18 p.m.)