ARIN PPC at NANOG 61 Transcript - 05 June 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: Good morning, everyone. Okay. I’m John Curran. I’m the president and CEO of ARIN, the American Registry for Internet Numbers. I’d like to welcome you to our Public Policy Consultation at NANOG. We’re trying to make sure we get input from the community on a handful of policies in development right now.

A Public Policy Consultation is an open public discussion of Internet Number Resource policy held by ARIN. It’s got in‑person and remote participants. We hold them at Public Policy meetings and we hold them at other forums, like NANOG, that have been approved by the trustees.

So this morning we’ve got an update on the ARIN Advisory Council activities. Chairman John Sweeting of the AC will give that. We have four Recommended Draft Policies. Recommended Draft Policies potentially could be adopted after this meeting. Meaning they could be sent to last call by the ARIN AC and then to the Board of Trustees.

So those are particularly important to pay attention to. We have ten policies in development right now, ten policies for which we have a policy statement and the AC is working on refining it based on your input, which means they need your input.

So very important. Glad to have you here.

I’d like to welcome remote participants. We have remote participants who have access to the webcast, the live transcript, downloadable media materials, and a chat room. We have a remote monitor who will monitor for questions from the remote room and come up and ask them.

I ask everyone to please speak so that everyone can hear you. Speak clearly. Identify yourself when you’re at the microphone. Please comply with the courtesies in your Discussion Guide.

So Paul Andersen, ARIN’s vice chair and treasurer, will be moderating; I’m the president and CEO; and John Sweeting, the AC chair, will be helping the discussion of the policies.

Let me now turn it over to John to do the AC report.

Update on Advisory Council Activities

John Sweeting: Good morning, everyone. Welcome to this Public Policy Consultation.

A couple of things I want to point out real quick is, as John said, there’s four recommended drafts that the Advisory Council has voted forward for adoption, and the next step is to send it to last call. And we really want good input on those four as we’re planning to take some final actions sending that to last call.

And there’s a couple of the draft policies that we’re looking to abandon, and the shepherds that come up and do the presentation will be very clear on what the intent is on those policies. And what we’re looking for there is like is there any reason why we should not abandon those.

So the Policy Development Process charges the member‑elected ARIN Advisory Council as the primary facilitator of the process.

Today, besides myself, from the Advisory Council we have Dan Alexander, the vice chair; Kevin Blumberg, primary shepherd on a few of the proposals; Andrew Dul, another shepherd; David Farmer; Scott Leibrand; John Springer; and myself.

Number of policy discussions today. Like I said, we’ll have four Recommended Draft Policies that we want to hear your thoughts on, specifically whether there’s any reasons not to move them forward in the process towards adoption, and also the 10 draft policies, which there’s a few that ‑‑ most of them we’ll continue working getting them ready for Baltimore, but there’s a couple that we feel we would like to abandon and stop work on.

After today’s meeting, if you want to continue discussion on these or any other policy proposals, we have a room up on the third floor where you’d be welcome to come up and sit with us and work on some policies, or just seek myself or any one of the AC members out and let us know what’s on your mind, what we can help you with.

The only other thing I’d like to say is we have very limited time on each and every one of these. So if you could get up, speak your piece when you’re ready, and then let the other people get up and do theirs and we can move along and cover this in this meeting. That’s it. Thank you.

John Curran: So let’s move right into the policies.

First policy we have to discuss is Recommended Draft Policy ‑‑ let’s see. Here we go –

Recommended Draft Policy ARIN-2013-8: Subsequent Allocations for New Multiple Discrete Networks

John Curran: Andrew, if you want to come up. I’ll do the introduction, and then I’ll turn it over to Andrew to present.

The origin of this policy proposal was November 2013. The shepherds, Cathy Aronson, Owen DeLong, Rob Seastrom. It was accepted in November. It was presented at NANOG 60. It was reverted to draft and presented at ARIN 33. It was revised, and the AC made recommendation again in May. So this is recommended to be adopted. It’s in your guide.

The proposal adds missing criteria to NRPM 4.5, Multiple Discrete Networks, and NRPM 6.11, IPv6 Multiple Discrete Networks, to assist staff and the community in determining the allocation sizes for new sites in existing MDN customers.

Revise text to remove the requirement to “obtain connectivity at the new site” and replace it with the requirement the organization “has shown evidence of deployment” of the new discrete site.

If implemented, ARIN would require hard evidence such as connectivity contracts, proof of deployment at the new site, et cetera, but it wouldn’t be specifically having to be a connectivity contract. It could be evidence of purchase. It could be an engineering plan. So there’s more flexibility in the defined language, but it would need to be concrete evidence of deployment.

Does not create legal concerns, and presentation by the AC.

I’ll see if I have yours ‑‑ is he the next slide? Yes, he is. That’s so convenient. Thank you, Einar.

Andrew Dul: This policy basically comes from the Policy Experience Report last year, and tried to fix an issue that the staff identified with the existing policy. And we are basically implementing a slight variation on what the staff’s current policy ‑‑ or current practice actually is.

So the way we are fixing this is we’re adding a little new section. It basically allows ARIN to give a new site a minimum allocation or an immediate need request per site.

And this has been fairly uncontroversial with the exception of the “has shown evidence of deployment,” which we believe that text now actually mirrors what we think the community wants for this policy.

This is just talking about where the origins of this policy are and the original discussion about it. And at this point we’d like to hear from the community of any issues with the current language as the policy is written.

As I stated earlier, I believe we’ve fixed the issues that the community has raised out before, and this policy we believe is now ready to go to last call.

So any comments from people today?

Paul Andersen: So this is your moment. You can come up, tell us whether you support or don’t support this proposal moving to the next stage or any feedback you have on the text.

I ask you not all to rush at once: fire code violations and all that.

Where is Lee Howard when you need him?

Again, as you all make your way to the microphone, I’ll remind you to state your name and your organization prior to speaking as well.

But if there’s no feedback, then it makes the AC ‑‑ if you do not hear the chair, if there’s no comments, he believes the AC will move it to last call. It saves time. Makes time for other things.

John Curran: Any remote participants?

Paul Andersen: Anyone typing? They need a moment or two. There’s the webcast delay. Well, we’ll give a going once, going twice, three times, we’ll close the microphone.

Just giving a moment for remote participant. But seeing none, thank you, Andrew, and thank you for your feedback on this.

(Applause.)

Recommended Draft Policy ARIN-2014-5: Remove 7.2 Lame Delegations

John Curran: Okay. Very good. So next up we have Recommended Draft Policy ARIN‑2014‑5: Remove 7.2 Lame Delegations. This is also a recommended policy. Meaning it could be adopted after this meeting.

Okay. So this originated in January of this year. Rob Seastrom is the shepherd. It was presented at NANOG 60. The AC made it recommended in April. It’s in your guide.

The proposal would remove NRPM Section 7.2 because it’s out of scope for ARIN and because ARIN has never effectively implemented it.

Staff would not change our current operational practice.

When ARIN switched from per zone DNS management, we ran into major issues with lame delegation and we suspended it. The issues included lack of clear definition on what a lame server was and the potential of removing a misconfigured but working reverse server.

It does not create legal concerns.

And now I’m going to have John Springer come up and do the AC presentation, which ‑‑ no presentation. Oh, very good. Go John.

John Springer: So when this was presented in Atlanta and Chicago, the primary shepherd, Rob Seastrom, made a point saying it was going to be the shortest presentation that ever occurred in the history of ARIN.

So the proposal is to remove Section 7.2. And I now call for any feedback or commentary. If we receive none, we’ll probably be moving this to last call.

Paul Andersen: On a historical note, this was my first‑ever policy I shepherded on the AC to put it in. So good to see that you’re removing all existence of my tenure.

(Laughter.)

Paul Andersen: Would anybody like to come up and comment on whether they support or do not support or moving this policy to next stage? Center microphone.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Just a clarification from John. How many years has it been since this policy has not been in effect? As in how many years has it been since ‑‑

Paul Andersen: We’re going to hand that over to Mr. Curran.

John Curran: I’d say six and a half at this point, I believe. At least five. I think we’re up to six and a half by now. Because it was at the point in time when we had to implement the per-zone management that you all use now.

Kevin Blumberg: Thank you. I’m in support of this proposal. Thank you, John, for that feedback.

Paul Andersen: Center microphone again.

Joe Provo: Joe Provo, Google. Strong support.

Paul Andersen: Thank you very much.

Any other comments, people who would like to give reasons why it should not advance? Again, the AC is looking to potentially advance this to last call. Going once, twice, three times, sold. Except for remote participant, because we give them a little extra time because they’ve got to type.

I’m looking at you ‑‑ no. So seeing no further feedback, I think we can ‑‑ unless you specifically want a poll.

We’re good. Thank you very much for that valuable input to the AC.

John Curran: If we have lots of time, we can use it as a longer break, because coffee is good. So let’s see. Next up is Recommended Draft Policy 2014‑12: Anti‑hijack Policy.

Recommended Draft Policy ARIN-2014-12: Anti-hijack Policy

John Curran: Okay. So it was proposed this year in February. David Farmer and Cathy Aronson are the shepherds. Accepted as Draft Policy in March. It was presented at ARIN 33 in Chicago. The AC made it recommended in May. It’s online and in your guide.

The policy would clarify expectations for experimental allocations by requiring that all experimental allocations come from ARIN’s Internet Resource space, do not overlap existing registrations, and not be private or otherwise unroutable space, and be registered in Whois with a designation indicating the registration is experimental with a comment indicating the end date of the experiment.

Staff: This policy could be implemented as written. Another comment: This policy’s probably a good thing because we did something else recently with a very large non-documented experimental allocation as part of testing blocks.

And this would make sure that you all understand how we do testing and that we do it in a rigorous manner and it’s goodness.

Legal assessment: No particular legal issues.

Presentation by the AC. Come on up.

David Farmer: Hello. This is not going to be the shortest presentation for ARIN ever, but that’s not a problem.

Okay. Problem statement: ARIN shouldn’t let people hijack addresses. Which is kind of what happened, and at least by some people’s definition. I’m not sure I agree with that definition, but that’s okay.

And so we’re going to put a little more detail into the guidelines. So we have a recommended policy statement. This is what’s in the guide. Modify Section 11.7 with a new name, calling it “Guidelines,” and then put in a ‑‑ modify one sentence and add a sentence about how the allocation should be documented in Whois.

So this is the recommended policy text. All of the text in black is previous text from the previous policy and the text in blue is the text being added and inserted.

There’s been some recent discussion there’s ‑‑ about the third sentence, which is the original text, and it’s pretty awkward. And so we’re going to propose some editorial changes as we go into last call. These are listed here. They’ve been on PPML for a little while.

And then make a quick change to the policy statement, basically saying, yep, we’re going to modify that third sentence to clarify the original policy intent.

And then this is the overall policy text. You’ll notice that there’s a number of changes in the third sentence there.

Discussion: Anybody object to us incorporating ‑‑ the AC incorporating the editorial changes based on the PPML feedback prior to last call?

Thank you.

Paul Andersen: Let’s go back so we’re working with the proposed text. So I’d ask at this time if people have either feedback on the editorial changes or feedback on the proposal to approach the mic forthwith.

Center microphone.

Bill Manning: Bill Manning. And I read through that text and it talks to me silently that this is IPv4‑specific or IPv4‑tuned, because there are other experimental spaces defined by the IETF which don’t meet these criterias. The ULA spaces, for example.

Paul Andersen: Are you proposing there needs to be clarifications? Or are you not supportive or are you supportive?

Bill Manning: When other organizations such as the IETF are able to designate usefulness of parts of the address space that don’t fall within the ARIN policy guidelines, this seems a little extreme.

Paul Andersen: Could you just hang up ‑‑

David Farmer: I could, but this is one small part of the experimental policy text talking about how ARIN would allocate experimental. This whole section is only about allocations made by ARIN.

Bill Manning: No, it doesn’t say that.

David Farmer: This doesn’t say that; other parts of the text. This is one sub-section.

Bill Manning: Okay. It says: Come from the global Internet Resource space.

Paul Andersen: Hang on. I’d like John to respond.

John Curran: This goes into Section 11, which reads: Experimental Internet Resource allocations. ARIN ‑‑ and the first sentence is: ARIN will allocate numbering resources to entities requiring temporary numbering resources for a fixed period of time under the terms of a recognized experimental activity.

So in the context of that first sentence and the whole Section 11, I think it’s clear this is ARIN’s experimental policy for temporary allocation of general‑purpose address space, not IETF-specialized or technical. But you should go pull NRPM and look at the first two sentences and see if that provides enough context. If not, we should wordsmith it.

Paul Andersen: Would you mind going and having a peek and come back and let us know if that clarifies it for you?

Bill Manning: In about six months, yeah.

Paul Andersen: Thanks. Next speaker.

Mike Joseph: Mike Joseph, Google. I strongly support this policy. Moreover, I agree with the assessment that this would apply only to ARIN allocations. And I disagree with the assessment that this would be IPv4‑centric. In fact, this policy was originated specifically because of an IPv6 prefix hijacking. And it is in fact IPv6 that was envisioned when this policy was crafted, as the person crafting it was sitting next to me.

Paul Andersen: Supportive, yes?

Mike Joseph: Strongly support.

Paul Andersen: Thank you. Next speaker. Speaking maybe ‑‑ need a moment to think? Maybe just check on the remote while that ‑‑ no remote? Center microphone.

Ruediger Volk: Deutsche Telecom. Just an outsider’s remark: Looking at this statement, it looks kind of awkward that there is the remark that, well, okay, research organizations should not be allowed to hijack. I wonder what other organizations might be.

(Laughter.)

Paul Andersen: Is that just a comment or are you supportive?

Ruediger Volk: Well, okay, my understanding of the context of the proposal is, yes, fix what you have. Looking at the text and in particular the language explaining the thing comes with strange questions.

Paul Andersen: Okay. Thank you. Other people who would like to comment? Other follow‑up? Other remote?

So given we’ve had some vibrant discussion here, I’d like to ask that we do a poll because it’s always good to get a little bit of audience participation.

First, are pollsters ready? Just give them ‑‑ so we will ask the question. First I will ask for those who are in favor of this policy moving forward in the process and those who are opposed, just so you’re clear.

So once I get the green light from our pollster, I will ask you: Those who are in favor of this proposal, including the editorial change, moving forward, please raise your hand as high as you can and leave it there until I ask you to lower it.

I’d ask remote participants to indicate their support or non-support at this time as well. Preferably just hands up. No duck signs or anything like that, as I see some in the audience. Are we good? You may lower your hands.

Those that are opposed to this policy moving forward in the policy process, please raise your hand nice and high. All right. We’ll just wait a moment for the tabulation to occur.

Next step will be last call phase.

The envelope, please. On the matter of 2014‑12 on the question of moving it forward, those in favor, 19; those opposed, two.

Okay. 21 in favor; zero against. My apologies. I misread the paper. 44 people are in the room or online.

Again, just to clarify, 21 in favor; zero against; 44 in the room. This input will be passed to the AC for their consideration.

(Applause.)

John Curran: Moving right ahead. Let’s see. Next policy up is Recommended Draft Policy ARIN‑2014‑13: Reduce All Minimum Allocation Assignment Units to /24.

Recommended Draft Policy ARIN-2014-13: Reduce All Minimum Allocation/Assignment Units to /24

John Curran: Okay. And history of this was proposed in April 2014. Kevin Blumberg and Bill Darte are the shepherds. AC accepted it as a Draft Policy in May. They made it a recommended policy in May. It is online and in your Discussion Guide.

Staff understanding: The policy would reduce the minimum allocation assignment size to /24 for all networks whether end‑user ISP or whether single and multi‑homed. Additionally, it would eliminate the existing multi‑homed policies.

Staff comments. Okay. So it’s not clear in the proposal what criteria would be used to determine allocation size other than /24. Current criteria is very clear about what’s used to qualify for a /21, /22 and /20. And when you strike all that, it’s not quite clear how we do the initial size.

Staff uses current criteria defined in 4.2.2.1 in conjunction with slow start to establish the de facto 20 maximum allocation size for new ISPs. So an ISP who comes in who is qualifying for the first time because of slow start will not get larger than a /20. Staff recommends that a maximum initial size of /20 be loaded and codified in existing practice, and the section will be titled “Minimum and Maximum Allocation.”

The proposal will benefit smaller ISPs who aren’t able to qualify currently under IPv4 policies; in particular would be unable to qualify for 8.2, 8.3, and 8.4 transfers in a post‑depletion world. Note this is a point that was raised during the Policy Experience Report in Chicago.

ARIN would likely have many discontiguous /24s as we near depletion and fewer and fewer larger blocks. This block would actually allow more organizations to use those smaller prefixes and continue with the efficient use of the pool.

No legal assessments. No legal proposal. Does not appear to pose any significant legal risk. And now I will turn it over to Kevin Blumberg to do the AC presentation.

Kevin Blumberg: Good morning, everybody. So the thrust of this is we wanted to author and we wanted to basically look at the entire NRPM and lower everything down to a /24 whether you’re single‑homed, multi‑homed, end‑user, ISP, simplify the entire process.

The removal of the multi‑homing section was effectively because of duplication. Every section other than the amount of space, whether it be your minimum assignment sizes or all of the things that were duplicated between the two, so the sections got combined at that point, because there was no difference now that everything was /24.

The key parts of this policy was to not change slow start. The slow start section is unchanged completely in this proposal. Efficient utilization is completely unchanged in this proposal. Those aspects are the same and will continue to be the same. It was to remove out and lower everything to /24, and that was the main aspect to it.

We’ve gone through the staff comments and have a little bit of a disagreement in some respects, and a friendly disagreement. The first is in relation to what size to give out in the staff comments. One of the concerns was that /24 was really now it and there was no really way to ‑‑ there was no description of a way to do more than that. Whereas in the text it does actually say “and larger.” So ISPs are generally allocated /24s and larger which does give staff the flexibility of assigning larger space when required based on your needs through slow start and your utilization.

The discussion in regards to ‑‑ and this was the most or a little complicated, but in regards to “maximum” was historically in the NRPM ‑‑ and I’ll bring up the section here in the multi‑homed section ‑‑ we had some specific descriptions, examples of we have this amount of space, you can get this amount of space. And staff had in the past ‑‑ and please correct me if I’m wrong ‑‑ had used this as the maximum for what an organization should get. So the maximum that was given as an example with a /20, that was the maximum you could get on your initial allocation.

This does take that out and what it allows people to do or organizations to do is to come in and say I’m actually using a /19. I need to show that I’m efficiently utilizing it. I need an /18. In the past that wouldn’t have been allowed based on this text and with this revision it really allows and simplifies both a little bit in the free pool scenario but more importantly in the transfer market, it just simplifies what you need based upon the amount of time that you are, whether it be three‑month, 24‑month, et cetera.

I’m just going to bring up the questions I have for you. First question was obviously do you support this as written. There’s a lot of changes. It’s in your guide. And I would appreciate if you do have any feedback in that, we’ve got a lot of feedback from the community, both ‑‑ sorry, we’ve got a lot of feedback from the community on the PPML already. Do any of the changes that we’ve outlined create issues that we’re not aware of, because you’re obviously part of the community. This is a community, and we miss stuff.

Do you see anything that we’ve missed on these changes? Should we put in maximum allocation or leave it based on slow start and efficient utilization, not having a maximum set? And should that text be reinserted? Thank you.

Paul Andersen: We ask all the eagle eyes to approach the microphone after John has an interlude here.

John Curran: I’d like to comment on the staff’s comments and the maximum size feature. It’s not a ‑‑ it’s up to the community what they want here. For the time between now and depletion of the ARIN free pool, a maximum might be useful if you are concerned about the rate of depletion of the free pool.

After that point, it’s questionable whether it serves a need. But in that intervening time, removing a maximum makes things simple; that’s a benefit. Leaving a maximum in eliminates the possibility of a party that has an ISP‑assigned block. And there are ISPs over the last 15 years who have assigned in some cases very large blocks to their downstream ISPs. So you might have parties out there who have /16s, /17s, and /18s that are effectively from their upstream ISP. They could now immediately come in where they could not before, they’d only get a /20 ‑‑ they could come in and get a /16, /17, /18, or /19. Is that a problem? I don’t know. It’s a feature, and that’s really the trade‑off. The question is, in the point in time when you have this free pool, is removing that /20 cap a necessary thing or not?

Certainly post‑depletion it probably doesn’t matter at all. So I just want to clarify that. It’s not a problem either way. It’s just how you want to manage the resources.

Paul Andersen: Thank you, John.

Bill Manning: Bill Manning again. To the extent this simplifies policy manual, I support this; to the extent that it clutters the policy manual, I am not in favor. And in cluttering the policy manual, you are creating, for want of a better term, interim IPv4 policy to deal with a specific case, this sort of end‑space runout and how much you can get, how much you can’t get.

I would almost rather see ‑‑ and this is not new ‑‑ that a minimum allocation regardless of address family will be a /32 and people who are concerned about routing would be concerned about routing and whether or not they’d be willing to accept anything smaller than a /24 or a /27 or whatever into the routing system. But that’s not something that ARIN in policy should be concerned about. ARIN should be concerned about efficient allocation of the address pool that has been given, regardless of address family. So I would like to actually see this recast being addressed family agnostic.

Paul Andersen: So not supportive and your desire would be to have it recast to make it supportive.

Bill Manning: I support it to the extent it simplifies the policy manual; I don’t support it as it’s address family‑specific and temporally‑specific. I don’t think in five years this is going to be important.

Paul Andersen: Mr. Blumberg would like ‑‑ then you’re allowed to run away. Next speaker.

Scott Leibrand: Scott Leibrand, ARIN AC. Couple of responses to Bill’s comment. He might be interested in the discussion of ARIN 2014‑3, I believe it is, which removes the 8.2 and 8.3 minimum IPv4 blocks as requirements. So that would mean in a post‑exhaustion world, the minimum IPv4 transfer size would be a /32. The second ‑‑

Unidentified: (Indiscernible.)

Scott Leibrand: It’s a separate proposal and it’s less likely to pass. There’s two things ‑‑

Paul Andersen: All right.

Scott Leibrand: There’s two things going on here, and I think they need to be discussed separately. My point is that discussion I believe belongs in the later discussion.

The other point I would make is that we have two different sections of the policy manual, Section 4 and Section 6. They deal with two address families. The effort here is specific to the Section 4, which deals with IPv4, and I believe this is a simplification and will make things a lot less complicated, both now and after runout.

So to the first half of your comments, I believe this does address the simplification and doesn’t, as it’s currently drafted, make things any more complex.

Paul Andersen: To clarify, the proposal mentioned earlier deals with Section 8 which solely deals with transfers. But are you supportive or not supportive? You are supportive? Two thumbs up, let the record show.

Next speaker, please.

Mike Joseph: Mike Joseph, Google. I have some concerns about the aspects of the policy which make unclear the ‑‑ or potentially, in this case, remove the maximum allocation sizes. But not just because it potentially allows an unlimited maximum initial block, but also because, it’s my read of the policy, and perhaps that can clarify, it is not clear if allowing the organizations to get initial /24s would mean organizations can only get initial /24s.

John Curran: So at present the criteria that we use to establish an organization obtaining a block size of /22, /21, or /20 is laid out in the sections that are being excised in this proposal. But it’s clear that the intent of this is to allow us assigning allocation size based on their actual documented need, but it’s hard to see how that intersects with slow start, because the whole section is covered by slow start, which means we give parties an initial block size and allow them to show that they’ve used it before we give them the next block.

So there’s nothing to prevent, under this policy, us from allocating a block larger than /24 if we see the party coming to us has need right now for something larger than /24. So we could give out /23s, /22s, /21s from the free pools, /20, /19, and that’s the question about if someone shows up who has an ISP, you know, they have provider‑assigned space of /16 and they want to get out of it while they can, this would say we would give them their /16s so they could renumber out of it. And so, yes, /24 does not become the default; this becomes very much a judgment for initial allocation.

Paul Andersen: Support/not support/further comment?

Mike Joseph: As long as we’re not tying our hands to only being able to get /24s going forward, then I have no objection.

Paul Andersen: Thank you very much. I’d again encourage this is a Recommended Draft Policy. There’s a lot in here. So the AC is very much looking for your input, if they have found the right text regarding the possible statement that’s defined. I’d urge you to come up, give your feedback.

Next speaker, please.

John van Oppen: John van Oppen, Wave Broadband, Spectrum Networks. The maximum allocation size is a big thing for me. I think we’re basically dragging out our v4 runout for no reason. If people need addresses now while we have them, we should be using them up and we should be allocating how we did.

I’m definitely in favor of this because I can tell you, like at least from our perspective, it encourages us ‑‑ the current policy encourages us to take every one of our LLCs that has users all over the West Coast and have every one of them apply for /20s, which is, frankly, just stupid.

And we as an end‑user ISP, like we’re not going to stop adding cable modem users to the network. We know this. This is not likely. We’re going to let them sign up and we’re going to get the IPs to do it whether we have to buy ISPs or whatever.

This just really takes the policy and matches it to something that’s reality. If we need the IPs, we should get them; if we don’t need them, we shouldn’t get them. It’s quite simple.

Until we’re out of IPs, then hopefully everybody realizes that v6 is important and will actually turn it on on their content and we won’t just see like three sites making up 95 percent of our v6 traffic towards our end users.

Paul Andersen: Thank you. Thank you for that comment in support, as you said.

Christoph Blecker: Christoph Blecker, Disney Interactive. I’m in strong support of this policy. I think lowering especially for end-users the requirement down to a /24, well, there’s an extreme benefit there to get IPs out the door and get them in use.

Paul Andersen: Thank you very much for that statement of support. Other people who would like to make a comment or even just come up and say they’re in support or not?

Remote participants? I see the shaking of the head.

So give one last chance. Again, this is a Recommended Draft Policy, so we will be taking a poll to get to see whether or not this room feels there’s support to move this forward to last call.

We’ll close the mics now. Last chance for remote participant.

Okay. With my poller, hardworking in place, I will ask the same question style as I did last time: First for those in favor of moving it to last call and then asking for a show of hands of those who are against.

So those on remote participation, please indicate your vote now. And for those in the room, raise one of your two hands as high as you can. Please leave it up. Hats also count. Trying out a little humor. Please leave them up until the counter gives me the indication they have the count.

Those that are opposed to this policy moving forward, please raise your hand or hat at this time. All right. Thank you very much. One moment while we get the tabulation. I have had a cup of coffee since the last time, so I think I’ll be able to read the sheet correctly this time. But you never know with me.

And the envelope, please. They left me no ambiguity this time; they only gave me two numbers.

(Laughter.)

Paul Andersen: So on the matter of 2014‑13, those in favor, 16; those opposed, zero. Total people in the room and remote, 49. Again, 16 in favor and zero against. This input is being instantly provided to the AC for their consideration. That concludes our last Recommended Draft Policy. We’ll move on to the Draft Policy section.

John Curran: Thank you, everyone. Okay. So next up is Draft Policy 2014‑1: Out of Region Use.

I’ll ask the shepherd to come up and present.

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

David Farmer: We’ll make this quick. The problem statement for this policy is that there’s no ‑‑ the current policy neither clearly forbids nor clearly permits out of region use of ARIN registered resources. We’ve had a number of previous attempts to limit out of region use, and those have failed. We’re working now on an option to clearly prevent them. But in doing so, there are a number of issues that have to be addressed in policy and operational practice, and we are attempting to address those.

The policy statement creates a new section, out of region use. ARIN registered resources may be used outside the ARIN resource region, et cetera, et cetera.

There’s a definition here. This definition was modified since the Atlanta PPC to take out the billing address, which was one of the criteria that was suggested by the community that would be a problem. That’s been handled.

Additional language was added to not duplicate resources with other RIRs and restricting utilization rates to ARIN registered resources. So you can’t use how many resources in the RIPE region, per se, to demonstrate what you should be getting for a block.

There are a number of policy sections to this. They’re summarized here. I’ll give you a moment to look through them. I’m not going to read them to you.

And then so discussion. There hasn’t been much work on this since ARIN 33. There’s just been a lot of things and this one hasn’t bubbled up to the top. We’re going to work on that. There’s been general support for the concept. The AC plans to continue its work on this. And the general direction is simplify and shorten. And if you have suggestions, we’d love to hear them. And I think that’s it.

Paul Andersen: Just a reminder: This is a Draft Policy, not a Recommended Draft Policy, so as opposed to the ones that ‑‑ correct, Einar? Thank you. You had that look for a second that ‑‑ if Einar says it’s wrong, it’s wrong. So this policy is not as far in the policy process, so we’re looking for more initial feedback. We will not be taking necessarily a poll at the end.

So I urge you to come up and give your comments on whether it’s sound policy from your standpoint and seems to be addressing a problem you’d like solved. So, with ‑‑

Unidentified: (Indiscernible.)

Paul Andersen: It is tracking. If you turn to your thing, you can see the lovely diagram. It’s up here and it’s making its way down. But, with that, I will open the microphones. First speaker.

Scott Leibrand: Scott Leibrand, ARIN AC and one of the people who has taken a hatchet to this text in attempt to simplify and hasn’t quite gotten to where we want to be at.

I’d like some feedback as a member of the AC from the community on whether you think that this is something important to do long-term post runout. A lot of the previous discussion around this has been for v4. We’re specifically not moving this forward in time for v4 runout. It really is going to be something that matters, that applies mostly after IPv4 is exhausted.

So the question I think for the community is: Is it useful, when everyone is getting IPv6 addresses, for them to be able to get them from a single RIR and use them everywhere and what policy language do we need around that, and possibly it might also matter if you can get addresses via ARIN on the transfer market and use those anywhere.

So if the community has a general support of that ‑‑ I think that’s what we’ve heard before ‑‑ it would be useful to make sure that’s still the case. So if you don’t support that, I’d like to hear that especially. If you have any specific suggestions around the text and what we should do with it, you can provide that now or later.

But that’s kind of where we’re headed, and I think it’s useful for the community to make sure that we’re still on the right track there.

Paul Andersen: Preferably we’d love the feedback now. You’re here; we’re here. Let’s go for it. Remote participant. First of the day.

Richard Jimmerson: Yes, remote participation. This is from Anthony Delacruz of CenturyLink: Are there other ramifications/penalty for being in violation of X.3? Will a network or ASN listed other than in X.1 that you wouldn’t be able to use towards justification, would ARIN be going after folks in violation to reclaim/revoke?

Paul Andersen: John I think would be best to answer this one.

John Curran: Richard, I want you to read that one more time.

Paul Andersen: Nice and slowly.

Richard Jimmerson: This is from Anthony Delacruz of CenturyLink: Are there any other ramifications/penalty from being in violation of X.3 ‑‑ then in parentheses ‑‑ more network or ASN than listed, other than in X.1 then you wouldn’t be able to use towards justification. Would ARIN be going after folks in violation to reclaim/revoke?

Paul Andersen: Just give John a second on that.

John Curran: Okay. So that’s actually a very good question. The most important thing to remember is that NRPM Section 12 is fairly broad and can be applied in many circumstances completely independent of this policy. If indeed we had someone who we thought as a result of them coming in for address resources had in the past fraudulently obtained address resources, it’s possible we could do a resource review on blocks that were not assigned under this out of region use policy.

So the answer is: There’s no limitation, per se, on what we can do a resource review on for NRPM 12 if we believe there’s been fraudulent activity. Otherwise, no, the section as written is pretty clear, and we wouldn’t be triggering resource review based on incidental use. It makes it plain that such occurs routinely. I think I answered the question, but if that’s not the case ‑‑

Paul Andersen: Richard, if you could ask the gentleman if that answers his question. Let us know.

Next speaker.

David Huberman: Hi. David Huberman from Microsoft. Scott, in response to your request for comments, I think it’s important that the AC work on this in a post‑exhaustion world.

I think a few things. With v4 exhausted globally, with AS numbers being basically infinite, with IPv6 being basically infinite, we’re not dealing with scarce resources anymore. So now it’s just housekeeping, administration. And an IP address is an IP address and a network is a network, and we want to connect one to the other when the other needs it, right? So I don’t see the value in Regional Internet Registries with respect to IPv4, I guess is sort of what you’re asking about, right, and where we’re going to use it or where we’re going to take it ‑‑ if we get an AS number from ARIN, where are we going to use it, where are we going to route it from, announce it from. It doesn’t have a whole lot of value to me to restrict, oh, you have to get it from ARIN because you’re using it in Chicago. No, you have to get it from JPNIC because you’re using it in Tokyo.

The network doesn’t care. The equipment doesn’t care. I speak English and I live in Virginia; let me come to ARIN. I speak Japanese and I live in Tokyo; let me go to JPNIC. So with v4 out, yeah, you have a waiting list for new resources that come available as people don’t pay their bills or as companies go out of business, and whoever is in line gets it. I don’t care if they’re in China or if they’re in New York; it’s a network that needs IP addresses. So I think it’s important. I think it’s good. I think it’s a good evolution of the registry.

Paul Andersen: David, but as the policy here ‑‑ great comments, but I had a hard time if you thought this is the right direction or the wrong direction.

David Huberman: I think it’s a great direction. Let’s get rid of any concept of regional restrictions of use because I think in 2014 and then beyond they’re irrelevant. It’s administrative. Let me deal with the registry I want to deal with, because an ASN is an ASN.

John Curran: I think ARIN ASNs, I’ve heard anecdotally, taste a little better. But, yes, probably an ASN is an ASN.

(Laughter.)

Paul Andersen: Don’t. No. Just move on. Move on. No good can come from that exchange. Next speaker.

Mike Joseph: Mike Joseph, Google. We generally support this policy. I do point out that in fact the policy correctly identifies that this address is only the utilization of addresses and where they may be used, not which entities are eligible to request resources at all from ARIN, which I think is a perfectly fine distinction to make and I think it is, in fact, one of the things that previously was conflated in earlier attempts to address this issue.

I do point out that while this policy does clarify what is out of region versus in region use, it seems reasonable that that might be done for billing or verification purposes. But I would have strong concerns if that were ever done to examine utilization differently for the same reasons that we opposed all previous policies that considered utilization differently.

In other words, an entity ‑‑ as David said, an entity that is using addresses globally ought to view that global utilization in a global context and not have to figure out 30 percent here versus 70 percent there and figure out how that qualifies them for address space.

Admittedly, this policy doesn’t seem to do that, so that’s good. But it does add definition. So I want to clarify for my colleagues that let’s not use that as an opportunity or an invitation to add additional qualifying criteria down the road. Specifically, on the incidental use, I think that could go either way. There is some risk in just ignoring small prefixes and other RIRs, but I’m not sure it’s a huge concern. But it may be something that we want to consider whether it makes sense to keep in X.3 or not.

Finally, in the initial part of Section X, there is some wordsmithing that’s needed. In the middle paragraph, the ‑‑ particularly the second sentence of the middle paragraph is rather unclear and also grammatically incorrect. So it would be nice for that to be reworked.

And then the third paragraph would seem to conflict with the second paragraph, although I don’t think it does ‑‑

Paul Andersen: I’m sorry? The third and second?

Mike Joseph: Yes, the third paragraph: Only the utilization rate of ARIN registered resources or immediate need may be used to determine a valid request size. But then the previous paragraph talks about how ARIN will examine utilization for other RIRs. I believe I get the intent, but I think it’s sufficiently unclear that that needs to be addressed as well. Overall, however, I think this is good work, and I support this policy.

Paul Andersen: Thank you for that. Any questions from you?

Thank you. That’s some great feedback. Dave may be in touch by email soon to get some clarification. But thank you. That was great.

Last call on comments seeing no remote participation. If you wish to speak, move toward a microphone now. Once, twice, Kevin, three times, sold.

Thank you very much for the input on this Draft Policy. We’ll move, oh, to the next one. Thank you.

John Curran: Very good. Okay. Next up is Draft Policy 2014‑3, which is the remove 8.2, 8.3 minimum IPv4 block size requirements. And I’ll invite John Springer to come on up.

Draft Policy ARIN-2014-3: Remove 8.2 and 8.3 and 8.4 Minimum IPv4 Block Size Requirements

John Springer: I’m channeling Owen DeLong and Bill Darte, neither of whom who could be here today, to present 2014‑3 for you to remove the minimum IPv4 block size requirements on Section 8.2, 8.3, and 8.4. All three of these sections deal explicitly with transfers, and they make the minimum block size allowed a /24. In a post‑exhaustion world, policy should allow and enable networks to move blocks around as they see fit without arbitrary regulation of the minimum size. Policy statement is: Remove the offending bits.

And a little background. Generally the ‑‑ in the discussion on the PPML, the opposition is a little heavier than the support on this. But there was a lot of feedback made to the shepherds in Chicago that kind of counterbalanced that a little bit. So one of the shepherds is tending towards maybe wanting to abandon this, and yet we still need to get some input from the community about what your intentions are.

So we’ve got a couple of questions here to help us think about this. If you feel that current language in the NRPM is appropriate and limiting transfers to /24, then we should stop working on this. If you do not think that is correct, if an organization should be allowed to transfer blocks down towards the /32, then we need to continue working on this. And there’s a lot of potential discussion about the math on this. So if anybody has any ideas about a nibble boundary or whether you like the idea of transferring /32s, let’s hear it.

Paul Andersen: Thank you, John. As John alluded, the AC is leaning towards abandonment on this policy. So we’re here at the operator forum, obviously, to hear feedback. So we urge you ‑‑ it’s a nice, short, sweet problem statement and policy statement ‑‑ do you think this is a good idea? Please stand forward center microphone.

David Huberman: David Huberman, Microsoft. I proposed the policy. And the reason ‑‑

Paul Andersen: So are you opposed or propose?

David Huberman: I proposed the policy and therefore I support it. The reason I put this in here is because, trying to think ahead, we’re operators here, right? What do you peer with over an exchange (indiscernible)? Do you peer with a /24? Peer with /32? Do anycast? Anycast, couple of machines? Why are you anycasting at /24? Only need a couple of IP addresses.

We have this ‑‑ when I was looking at the transfer policies and trying to make sure that we’re set up for success in 8.3 and 8.4 transfers for the coming years, I noticed we have this /24 minimum, and it’s totally arbitrary.

And so we had a little discussion on the Mailing List about what’s the technical motivation behind this, what is the technical reason why having a minimum of a /24 is a good thing, what is the virtue. And there’s no answer to that. There’s a lot of discussion about the AC should abandon it, but there’s nothing about the technical merits of why it’s good.

Those who were in support of it, and there weren’t a whole lot who spoke up, agreed: There’s no reason not to be able to transfer a /32 if you want to buy and transfer a /32 because that’s what you need on your network. The same rules from 15 years ago, when I started in this industry, are true today: People will route what you pay them to route. That’s how it works.

So /24 in ARIN, which has no stake in the routing space, makes no sense to me. I just don’t want it there. If only I had a principle. Just my opinion.

Paul Andersen: Dave, don’t run away. Just a second. Thank you for that statement. John wanted a question.

John Springer: Bear in mind that I’m only channeling the shepherds. So just as a procedural matter, for a Draft Policy where we have it in this stage of the proposal, you have three tests to meet: It needs to enable fair and impartial number policy; needs to be technically sound; and needs the support of the community. You may have two of those, but not the third.

David Huberman: Sure. Understood.

John Springer: So your arguments about technical soundness are well taken, but you just need to drum up some more support.

David Huberman: Yes.

Paul Andersen: Thank you. Perhaps some support coming right now to the mic. Or not. We’ll find out. One of you has to approach. There we go.

Mike Joseph: Mike Joseph, Google. I strongly oppose this policy. In particular, to address David’s comments, in fact, routability has such an important part in ARIN’s work, we recently added it to the NRPM and clarified that when we incorporated a number of principles out of 2050.

Particularly, Section 1.3 says that: The principle of routability guarantees that Internet Number Resources are managed in such a manner that they may be routed on the Internet in a scalable manner. So I think that, in fact, considering routability, when revising the NRPM, is paramount. I think that if we allow arbitrary transfers of any prefix length, we will see /32s being sold one by one and the routing table completely explode.

Paul Andersen: So your opposition is fundamental, or is there anything that could be done that would gain your support?

Mike Joseph: Removing this would gain my support. So, no, my opposition is fundamental.

Paul Andersen: Okay, wait. Another section another question.

John Curran: So note the section of principles that you cited in the NRPM regarding routability, ARIN should not adopt policy that can’t be technically made to work, that forces parties to do things that would break routing, for example. But as noted by the prior speaker, because everyone has freedom to decide what they accept and what they peer with, it’s not clear that removing the minimum causes a problem if you believe that individual operators can decide exactly what they’re going to accept or not going to accept regardless of what gets transferred. So I see the section you site. But I want to say I would recognize if ARIN was issuing ‑‑ ARIN was issuing blocks to parties on a /30, here’s your four addresses congratulations. The community may have a problem because people would have an expectation that those ARIN issued blocks were routable. That would definitely be a case where we’d all be staring at that is ARIN creating a situation that’s not routable. But when operators are doing it on their own and then have to find the way to route the result, it’s not clear that that’s a technical problem because there are circumstances, as noted, when someone may want to have a /30 routed, a peering connection, for example, or something small. So I guess all I’m saying is that we added routing in there to make sure that ARIN didn’t force breakage on operators. I don’t know whether or not as it’s written it means operators can’t decide that themselves for issuance and transfers that they do on their own.

Paul Andersen: John, you promised him a question, though.

Mike Joseph: I’d like to respond to John’s comments if I may.

Paul Andersen: Go ahead.

Mike Joseph: First off I did highlight 1.3 for the reasons you said. But also for an additional reason, which was to clarify that ARIN does in fact consider some operational impact such as routing when adopting policy. So the tendency of some folks here to argue that we ought not consider any operational impact when contemplating policy is to me a bit of a red herring. To your specific points, while it’s certainly true ‑‑ and I wouldn’t suggest we adopt a policy that would preclude an ISP from assigning a /28 to their customer and allowing them to route it however they wish, I would argue this does in fact ‑‑ this isn’t quite analogous to the situation you described of ARIN allocating smaller than /24s. By allowing the transfer to proceed, ARIN’s registry would reflect a smaller prefix. And therefore it would look as if to the world that the entities acquiring those other prefixes would have the expectation of routability. I don’t see this as any different in particular post‑exhaustion. ARIN for v4 will be administering almost solely at transfer market and not its own free pool. So to me those two are not distinguishable and I continue to oppose this policy. Thank you.

Paul Andersen: Thank you.

John Curran: One sentence. Thank you for that response. It’s also true to the outside world they build filter lists based on ARIN’s information so yes they would build filter lists if a transfer had a /30 they’d build a filter list recognizing it’s /30 potentially. You’re correct, to many people they would respond to this as if it was an ARIN allocation, even if it was a transfer. So thank you for the point.

Paul Andersen: Long sentence. Next speaker.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I generally do not support this proposal ‑‑

Paul Andersen: Could you speak up a bit?

Kevin Blumberg: Sorry. I have two issues, one is a technical and one is a business issue. From a technical point of view, I’m concerned that by going all the way to a /32, well, you can use your newfound powers with the anti-hijack, throw a million /28s onto the routing table and see how that goes and how many people complain about that.

I think we’re going to one extreme ‑‑ we’re going too far towards an extreme. I would look at lowering it over time. I would look at having the operator community come back to us. But going to /32s scares the living bejeezus out of me.

Paul Andersen: So you could support the policy if it was a slower ‑‑

Kevin Blumberg: I could support it with a lot of feedback over time from the operator community. But the second part of it, which is my bigger concern, is I use ‑‑ I know many companies use the NRPM and what ARIN’s policies are in how we do our assignments to our customers, how space is used with them. I don’t need a customer going to a court and asking from their /32 from me for their Web-hosting website and that court agreeing with it, not understanding the ramifications of pulling out /32s from my space for whatever reason that may be.

We have policy. The courts can do what they want. But if our policy shows single IPs are allowed, we are giving justification for that, and I am very concerned about that in a post‑runout environment.

Paul Andersen: John would like to follow up ‑‑ oh, Kevin.

John Springer: So, Kevin, there was a slide there that posed two questions. These two questions I couldn’t detect from your statement where you fall in this spectrum, because it sounded like you were willing to work down towards ‑‑

Kevin Blumberg: I believe at this time it’s appropriate to abandon. I would not support this.

Paul Andersen: Thank you. Next speaker.

Martin Hannigan: Martin Hannigan, Akamai Technologies. I just want to poke a fork in this. Yeah, what everyone else said, I’m opposed. But I actually ‑‑ I appreciate David’s sentiment. I ‑‑ from my own perspective, I think ARIN should get out of our business and let us operate our networks. Thank you.

Paul Andersen: So that’s supportive?

Martin Hannigan: Opposed.

Paul Andersen: Opposed. Sorry. Remote participant.

Richard Jimmerson: Yes, this is a remote comment from Kevin Otte from Flying Penguin Technologies: I concur with the abandonment of the policy. We don’t need to let the IPv4 address space fragment into an administrative nightmare.

Paul Andersen: Last call before we take a ‑‑ I believe the AC chair would like a poll of those that are in favor of abandonment. So if nobody’s going to speak, once, twice, three times, I’ll ask my esteemed pollster ‑‑ no changing chads in this election, please. It’s a trick.

Listen carefully. I’ll first ask for those who are in favor of abandonment ‑‑ a little bit of a double negative ‑‑ those opposed to abandonment that the AC would continue to work on this.

So those on the remote, please signal now. And those in the room in favor to the AC moving towards the abandonment of this policy, please raise your hand nice and high. You can lower them.

Those that are opposed to abandonment, please raise your hand now. Could you please keep your hand raised. That was the hanging chad of votes there in the back.

Okay. Thank you again for not giving me more numbers than I need to read. On the matter of 2014‑3, those in favor of abandonment, 22; against, one. Those in the room and remote, 49.

Thank you for this feedback.

John Curran: Okay. We are going to take a break shortly, but I think we have time for one more policy. So we’re going to cover Draft Policy 2014‑6, remove NRPM Section 7.1. So I’ll ask Scott Leibrand to come up.

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

Scott Leibrand: Okay. So Section 7.1 of the NRPM and the corresponding Section 6.5.6 both describe operational practice for managing the IN‑ADDR.ARPA and IP6.ARPA zones. The author of this Draft Policy asserts that that shouldn’t be in the NRPM as it’s operational practice and not number policy. Therefore, we propose to remove Section 7.1 and 6.5.6 in their entirety.

Some history. The original proposal actually just suggested removing 7.1. Previous discussions highlighted 6.5.6 does the same thing. For consistency the proposal was updated to include both of those. 7.1 is IPv4 and 6.5.6 is IPv6. So the discussion questions for you as the community center around whether we should have operational practice like this documented in the NRPM.

Many types of operational practice are not documented in the NRPM. Reverse DNS delegation is. Is that because there’s a meaningful reason that we need to have it there or not? And then if you think it shouldn’t be documented there, then the question becomes should we remove it entirely and not have it documented anywhere officially by ARIN in any community‑maintained documents, or do we need to document it somewhere else first? One of the types of feedback that was received in Chicago was that we should have an operational practices document, and it should be put there before we remove it. Or should we just leave it in the NRPM, it’s not doing any harm, doesn’t do any good to remove it and abandon this?

Those are the three options as I see them, and I would be interested to hear feedback from the community on those. So unless anybody has any specific questions around the text, I won’t bring those slides up.

Paul Andersen: Again, Draft Policy. We’re looking for feedback on, fairly straightforward, the discussion points. I see some mic approaching occurring. Go ahead.

Mike Joseph: Mike Joseph, Google. I support this policy and the removal of the outdated Section 7.1 text. It’s quite clear that the text in 7.1, in addition to dealing with only IPv4, also contains ‑‑ also strangely deals with /16s inconsistently from other prefixes sizes and other historical artifacts, so I support removal of this section. Certainly one could envision rewriting this, but at this point it just doesn’t seem worth it.

Paul Andersen: Do you have any view on the second point of should it be anywhere else or…

Mike Joseph: I would say it’s out of scope for this forum.

John Curran: If I could follow up on that earlier question. It’s ‑‑ the maintaining of IN‑ADDR.ARPA by operators is an operational issue, and it’s not clear it’s even an ARIN operational issue. But there is ‑‑ I see in NANOG a healthy BCOP process now spinning up. Would that be suitable for where a best practice was documented for something like this, as opposed to within ARIN?

Mike Joseph: One might envision that, but in the context of the ARIN Public Policy process, I would suggest that it’s out of scope. Thank you. So I support this policy.

Paul Andersen: Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I’m generally in support of this. Only one clarification. If by removing Section 7.1 is ARIN obligated to continue providing IN‑ADDR.ARPA to ISPs and end-users?

John Curran: Excellent question. So one of the things we’ve been looking at at ARIN is trying to get a better description of what services people get from ARIN and ‑‑ because it’s not as clear as one might expect. You can derive it backwards by looking at the NRPM and the RSA, but even that is only ‑‑ it’s kind of like squinting one eye and trying to guess it.

We actually need a services document that describes what services we provide both to parties under contract and legacy holders not under contract. And so, yes, we’re going to work on that. We’ll provide IN‑ADDR.ARPA services and make that clear that that’s part of the registration services we provide. That’s part of our update to ‑‑ trying to do one more push to get a clear description of services to parties both under contract and legacy holders that we want to do within ARIN.

So I want to get the services part done within ARIN no matter what. Our role in providing IN‑ADDR.ARPA, that shouldn’t necessarily be what an operator’s obligations or best practices are in making use of that.

Kevin Blumberg: Based on that, I would say that, from a timeline point of view, this removal should coincide with ARIN codifying separately that service. Thank you.

Paul Andersen: Thank you for that support. I’d ask at this point if you could move to a mic if you would like to speak on this proposal, as we’d like to close the mics shortly. John, do you have a quick interjection?

John Curran: I was just going to say: I’m faster than the AC, so that will be the case, yes.

(Laughter.)

Paul Andersen: Oh, you’re in a spicy mood today. He had a bad flight here, so he’s taking it out on… Next microphone.

Martin Hannigan: Martin Hannigan, Akamai Technologies. I support this policy. It’s always great to poke a fork in the other side of the roast. Let’s not overthink this, though. Let’s just get rid of it. It’s already largely ignored.

Paul Andersen: Thank you. Support. Got it. Last comment.

David Huberman: David Huberman, author of the policy. I support it. Mark, can I put you on the spot for a second?

Paul Andersen: Come on down, Mark.

David Huberman: This is one of the few things we do in the RIR world which is top‑down. The RIRs, as the administrators of their various IN‑ADDR.ARPA and IP6.ARPA zones, decide as a matter of operational practice, in combination with the DNS community, how they’re going to provide, how ARIN is going to provide, IN‑ADDR.ARPA and IP6.ARPA. Everybody else has to conform to that for the DNS to work.

So quick question. Do the five RIRs in v4 all delegate /24 reverse zones until you hit the /16 boundary, then delegate /16 zones until you hit the /8 boundary, and then bump it up to the next level? Is that consistent in all five RIRs?

Mark Kosters: That’s correct.

David Huberman: For IPv6, do all five RIRs delegate on the nibble boundary the /24, /28, /32, and then that’s like it, right? Is that consistent?

Mark Kosters: Yes, for the most part. Except for the /23s.

David Huberman: /23s, which is a special ‑‑

Paul Andersen: Mark, could you approach the microphone a bit, just for our remote ‑‑

Mark Kosters: Yes. So this is probably an accident of history, but ARIN’s first sort of initial allocations from IANA dealing with v6 were on /23s. So that doesn’t seem like a nibble boundary to me. So, anyways, we’re dealing with that. That’s in the past. But that’s one of the few cases where things are not on a nibble boundary.

David Huberman: Thank you very much, Mark. And the point of all that ‑‑ I don’t know how to say this without sounding weird, but I’ll just say it. This is an RFC to me. It should have been an RFC a long time ago.

Mark and you and some of your colleagues at the other RIRs really are world‑class experts at this, having worked in this for 10, 15 years in this space. So this is really something that ‑‑ you really should put an RFC together and then put it there. Nip it in the bud. Get it through the IETF. Because it’s a ‑‑ it really is a protocol.

Paul Andersen: Thank you, David.

John Curran: Understood. Thank you, Mark.

Paul Andersen: And thank you, Mark, for playing our game. We have some lovely parting gifts for you. I did say that technically Dave is last, but I think a remote participant snuck in there, so…

Richard Jimmerson: Snuck in right before you said. So this comment is from Kevin Otte of Flying Penguin Technologies. He is in support as long as a reverse zone is delegated, what the registrant does with it is their issue. Operational practice already dictates if you don’t have good rDNS, you’ll have problems.

Paul Andersen: Thank you. So, with that, we’ll close it off. Should I just send them to coffee or…

John Curran: I can do that.

Paul Andersen: John is going to come up and send you all to coffee now.

John Curran: Okay. So we’re nicely on schedule. We’re going to take a break for 30 minutes. We’re going to come back. We have six or seven more policy proposals and draft policies ‑‑ actually draft policies to go through. So we’re going to break from 11:00. We’ll be back at 11:30. That’s both in the room and remote participants. Thank you. We’ll see you in 30 minutes.

(Break.)

John Curran: If everyone will get settled, we’ll get started. Okay. Welcome back to the Public Policy Consultation at NANOG 61. We have several draft policies to consider this afternoon. The first one up is Draft Policy 2014‑8: Alignment of 8.3 Needs Requirements to the Reality of Business. Kevin Blumberg, come on up.

Draft Policy ARIN-2014-8: Alignment of 8.3 Needs Requirements to Reality of Business

Kevin Blumberg: Hello, everybody. So our intent is to abandon this proposal. We’ve spoken with the author, who is in agreement, and the reasoning behind that ‑‑ I really wanted to talk about that more, the reasoning why we’re looking to abandon.

Some things have come up recently that have simplified some of the issues that they were concerned about. There have been other policies that more surgically deal with this issue and make it simpler for end-users and ISPs who are needing space in the transfer markets to be able to do that. One of them was discussed earlier, lowering everything to a /24, as an example, will make it simpler.

The biggest concern with this policy is that it tries to solve the problem by removing out the ‑‑ most of the policy by saying under current ARIN policies, i.e., you can do a transfer, but the only requirement is the 24 months. And it basically took a big swath of removing out all other policy except for the 24‑month requirement.

When you try to add in specifics rather than taking out everything into 8.3, it actually really complicates 8.3. And so I’d like to hear if there’s anybody who is concerned about letting this policy go.

One of the pieces of feedback was that at this time this policy should probably be abandoned but it’s good once we get closer or after runout to revisit this; that if more simplification is needed, that will be the right time, but right now there isn’t enough data.

And, again, the biggest concern was new entrant, and by lowering ‑‑ and by getting community support to lower the allocation sizes to /24, as an example, that definitely helps a significant amount with new‑entrant issues.

So if there’s anybody who is in favor of abandoning or who is opposed to abandoning this, more importantly, by all means come up to the mic. I’d love to hear your feedback.

Paul Andersen: As Kevin mentioned, the AC is planning to abandon or ‑‑ as that seems to be their track. So we’d love to hear whether the community supports or does not support this potential course of action. First speaker.

Scott Leibrand: Scott Leibrand, ARIN AC, and probably one of the people that Kevin was talking about who thinks that we should go ahead and abandon this but we need to revisit simplifying NRPM Section 4 in light of runout. Given that, there are a number of efforts going on in that space already, but I think we need a lot more effort there. There’s a lot of you in this room who are very good at reading the NRPM and figuring out all the things that are wrong with it; there’s also a number of you who are previous policy authors or have contributed to actual text.

I think we need more community input on as far as actual proposals to clean up and fix Section 4 of the NRPM in light of the situation after runout. So I would encourage people to think about ‑‑ not necessarily just fire off a proposal today, but think about proposals to ‑‑ that would go into effect when there’s no more free pool. And think about when there is no more free pool which things ‑‑ like this author tried to do ‑‑ which things are no longer relevant and should be removed. And if you can do that in a simple bite‑sized manner, I think that would be a good input into the Policy Development Process to allow the AC to do a lot of the work.

Paul Andersen: Thank you, Scott, for that intervention. So encourage obviously those to submit to the policy process on the specific matter before us.

Does anybody wish to comment? Going once, going twice, going three times. Seeing no remote participants or no views, I think that we can consider that as input to the AC.

Thank you, Kevin.

John Curran: Next up we’ll be covering Draft Policy 2014‑9. And this policy proposal is resolve conflict between RSA and 8.2 utilization requirements, and the presentation will be given by Scott Leibrand.

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

Scott Leibrand: So the problem statement here centers around the fact that 8.2 transfer policy says if you’re not using space at the time of a merger and acquisition that ARIN should do one of several things, one of which is to reclaim that space. However, the RSA, which is a legal document between anyone who has recently, within the last decade, acquired space and/or has brought space under the agreement, explicitly prohibits ARIN from reclaiming space just because it’s not utilized.

So there’s a direct conflict between our policy manual and a legal document. Legal documents control, so this portion of the policy manual is not enforceable. It’s a direct conflict. So this proposes to fix that. It does so in order to solve a couple of problems. One is that conflict I just mentioned. That’s Item 2.

Another is Whois accuracy. So there’s a concern among a lot of people who want to do mergers and acquisitions that if they don’t have all their documentation perfect and they can’t get ARIN to execute the thing completely, that there’s a risk they’ll lose their space. And a lot of us who are involved in the process say no, no, no, the RSA says you can’t lose your space just for that. But people don’t know that. So this is perceived as something that prevents people from finishing up transfers when they get difficult. So the idea here is by removing the threat of reclamation, which is an empty threat, we will remove the perception of a problem and will encourage people to finish up their transfers.

It also ‑‑ the current way the text is written is to remove the word “aggregate,” which was referencing some sections in the NRPM that just got removed, and so therefore there’s no way in the policy manual to do the aggregation anymore and there’s no need to reference it here. So the actual proposed solution is now really simple. The original version of this proposed striking the whole thing, but instead the current version is ‑‑ based on feedback from the community is that we should simply remove the words “aggregate” and “reclaim” from this portion of the text. So that leaves just “return” or “transfer.” So if someone wants to voluntarily return space to ARIN, they may. Otherwise, ARIN will work with them to get them to transfer any space they don’t need after a merger and acquisition to someone who does need it. And obviously they can do it with whomever they like on any reasonable timeframe, and that will be fine under this policy.

So do you agree that this is solving a real problem, that the problem statement is valid, and do you support removing the words “aggregate” and “return” to resolve that conflict, or do you have any other suggestions? If you’re opposed, what concerns do you have? And there’s more details here that I’m not going to go into unless people have specific questions.

Paul Andersen: One more thing, so to speak. Again, Draft Policy, we need your feedback. Don’t rush all at once. Go ahead.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. I do support this proposal. What happens if it doesn’t happen? Does the NRPM then dictate you to make changes to an RSA down the road, or ‑‑

John Curran: The RSA takes precedence, is under the control of the Board of Trustees. When we ‑‑ we’re very close now to having an identical RSA and LRSA. The only difference is the fee schedule in all material aspects. When we did that, the right that we extended to LRSA holders, which was that you would not have your resources reclaimed totally for lack of use, was extended to RSA holders. So that takes precedence over the NRPM. And there’s no way to have an equitable treatment of all ARIN’s customers without doing that. So if this doesn’t happen, all it means is that there’s language in NRPM that we know is not effective.

Kevin Blumberg: I guess what I’m asking, John, is if the community has reaffirmed something in this particular case by saying no, don’t do it, would ARIN be required then to look at the RSA and see if they could make the adjustments to the RSA to fit the NRPM, or is it always the other way around.

John Curran: The changes to the RSA don’t happen because of changes to NRPM. They’re initiated because the community contacts the Board or at a member meeting and says: We want a change to happen.

Kevin Blumberg: Thank you.

Paul Andersen: Thank you. Next speaker.

Mike Joseph: Mike Joseph, Google. Just an observation for my colleague. I would suggest that revising that section of the RSA would likely be problematic. I would be surprised if I saw that changing, I would think. In any case, on the topic at hand, I support this proposal.

Paul Andersen: Thank you. Last call. Once, twice ‑‑ we’re all closed. Sorry ‑‑ no, go ahead.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the policy as written. I also support continued thought in the community as to whether this section is even necessary. But I think this is a first start: Get rid of the blatantly conflicting text and then further consideration.

Paul Andersen: Different problem statement. But good point.

Last call for real this time. Once, twice, three times. Seeing no remote participants and seeing no one approach the mic, we’ll pass the feedback on to the AC. Thank you very much. Thank you, Scott.

John Curran: Okay. Next up we have the Draft Policy 2014‑11: Improved Registry Accuracy Proposal. This is also a Draft Policy still being worked on by the AC. And I will have Kevin Blumberg come up and present it.

Draft Policy ARIN-2014-11: Improved Registry Accuracy Proposal

John Curran: As I mentioned earlier, there’s some other work relevant to this. With respect to the RSA and LRSA, we accumulated over the last year and a half, since the last LRSA and RSA ‑‑ we’ve accumulated a long list of comments from the community regarding possible improvements. And these are fairly problematic. Example is: No matter what you do with your IP addresses, we can’t have a circumstance where you come and sue ARIN for damages that would eliminate an entire registry because of something we and you did. You just use those addresses at your risk. We don’t endanger the rest of the community because you use the addresses. Even if ARIN did something wrong, we don’t endanger the registry.

So some of the changes that we’ve collected I nod up and down to and I go, Yep, thank you, and discuss with the Board and they’re not going to go anywhere. But there’s a list of changes that we think are worthwhile and we’re looking into. This includes making it clearer what services we provide to people.

As I said earlier in the day, you can sort of squint one eye and see there’s a mention of services in the LRSA but there’s no delineation of them. So it’s not clear that we provide what is registry services. And this is particularly apt because we provide services to both resource holders under contract and parties not under contract.

So right now we’re on a project to clean this up and discuss it with the Board and try to figure out if we can get a clearer statement of services provided. If that were the case, I think it overlaps heavily the language of this policy proposal. Any questions on my monologue there? Okay.

Kevin Blumberg: Thank you, John. One of the things we’ve been looking at over the last I guess two and a half months since the last ARIN meeting in Chicago was how to look at this policy proposal and deal with the fact that many of the requests in the policy in the problem statement were related to contractual issues between ARIN and the address block holder. And we can’t really do that, as was previously talked about, where we can’t override something that is in the RSA within the NRPM. That just wouldn’t work. So there’s been a lot of discussion back and forth, and very recently I heard that, actually, no, there’s some active work being done to look at the RSA and LRSA, which puts us in an interesting situation of what should we do with this policy.

So the policy, the intent of the policy was to get more accurate registry information by dealing with some legacy issues, non-contracted legacy issues and getting these people in the fold as easy as possible, to make it as easy as possible. But most of the way of doing that would not actually be through the NRPM. So we looked at cleaning it up and how to clean it up. My recommendation is going to be to hold off on this policy, to keep going as a draft, to keep refining some of the things that we’re doing.

We’re looking at adding in definitions for what legacy is, because there are no definitions today within the NRPM, and potentially spelling out within the NRPM some of the services that are available or some of the aspects that are specific to legacy that we do need to document that might have been historical, but it’s good to have it within the NRPM so that people just know where they sit and it’s not a nod and a wink, it’s actually there for them to feel comfortable with.

But to do that without understanding what the changes to the RSA are is kind of premature. I don’t feel we should abandon because I do think we should be working on this, but at the same time I think, without seeing what’s going to happen, it’s kind of premature to continue work.

There was a lot of disagreement in Chicago in terms of the aspects of this proposal, but we wanted to get your feedback: Should we actively sort of rapidly work on this, should we wait to see what happens with the RSA, or should we abandon this and deal with this proposal later on. And if anybody has any feedback on that, I’d really appreciate it.

Paul Andersen: You all by now know the drill. Maybe not. No? We’re looking for feedback on Draft Policy ARIN 2014‑11, those that would like to discuss whether or not this is a problem statement worth solving or the effort so far. Go right ahead.

Mike Joseph: Mike Joseph, Google. I oppose this policy as written. It does seem to be redundant with the work that’s being undertaken by John and the Board. I also think it adds a lot of unclear definitions to the NRPM, particularly a slippery slope where we may start to invite the opportunity for further differentiation between legacy and non‑legacy space holders.

And I think that that’s largely inappropriate for the NRPM. It’s my opinion that the type of services provided by ARIN are more properly determined through contracts, through ARIN’s operating procedures, and through the Board. This is not such a matter of policy. I think in fact that we ought to strive to have unified policy for all holders of address space regardless of the contractual nature of those space holders. So I oppose this policy.

Paul Andersen: And your opposition is you believe it’s best done at the Board level; you don’t think there’s something that could be changed –

Mike Joseph: Well, I have two reasons I oppose. On the services point, that’s best done through the Board and through ARIN Suggestions and the other operational forums; on the policy language, I think it introduces dangerous definitions into the NRPM.

Kevin Blumberg: Mike, do you believe we should continue working on this or that this policy should be abandoned?

Mike Joseph: It should be abandoned or at least put on hold in favor of determining the work that John has stated will be done most expeditiously, apparently. Possibly before you could even blink an eye, as a slow AC member, John states that this policy might be ‑‑ the services document might be done.

Paul Andersen: AC are people, too.

Mike Joseph: I was alluding only to John’s previous comment about the speed at which he promises the services document.

Paul Andersen: Understood. Thank you for the feedback.

John Curran: While we’re working expeditiously, it’s also something to be discussed with the Board that needs to look at the overall ‑‑ so it is going to move promptly, but it is a joint activity.

Paul Andersen: If the AC was slow, wait until you see that Board. No.

(Laughter.)

Paul Andersen: Sorry, Mike. Go ahead.

Mike Joseph: And I would hope that the Board and ARIN would invite input on that process through the appropriate forums but probably not this one.

Paul Andersen: Thank you. Good comment. Okay. If there’s no one else who wishes to comment, we’ll close the mics. Seeing no remote participants or people approach ‑‑ go ahead, sir.

Bob Evans: Bob Evans, Fiber Internet Center. Sorry about my voice; I was under a speaker last night.

So as a good Net citizen, several legacy holders, of course, also SWIP who they have got running the IP addresses, and I think that makes it easy for all of us to then find spammers and block them out of a network.

The way I read this so far, it’s just unclear which services are going to be what. If that is removed somehow from a legacy holder, I think it’s going to be harmful to the community as a whole. I just want to make sure that ‑‑ because it’s like you said, it opens things up.

John Curran: Let me respond. The services that we offer to legacy holders and to non‑legacy holders are very similar. The only place we found a material difference isn’t in the areas of SWIP but it’s in the area of RPKI. And it actually doesn’t have to do with the costs, per se, as much as it’s awkward for ARIN to be representing registry accuracy on a party that we haven’t actually vetted and put under an agreement. But I don’t expect it to affect SWIP.

Bob Evans: I think to address that you have to go back to the formation of ARIN and what was the intent at the time that the NSA and everybody handed everything over. So maybe it’s a Board decision.

Paul Andersen: Thank you. Okay. If there’s no further comments, we will wrap this one up. Thank you very much.

Oh. My apologies. So we are going to do our audience participation after a good coffee break, time to stretch those arms once.

All right. So the same question as before. I’m going to ask first for those in favor of abandonment ‑‑ in other words, not proceeding ‑‑ and those that are opposed to abandonment.

So those who are in favor of abandoning Draft Policy ARIN 2014‑11: Improved Registry Accuracy policy, please raise your hands or some other limb high. High and keep it up, please. Thank you. We need to count it. If you don’t keep it up, it doesn’t get counted. Sorry. You can lower.

Those opposed to abandonment, please raise your hand. Remote participant, if you have not done so already, signal your vote.

Some very complex tabulation is occurring. I think for a caffeine break we seem to have been slowing down here.

On 2014‑11, those in favor of abandonment, four; those opposed to abandonment, two. And in the room and on remote is 45. We’ll provide that input to the AC for their consideration.

John Curran: Next up we have Draft Policy 2014‑14, which is removing needs from the small IPv4 transfers.

I’ll have John Springer come up and do the AC presentation.

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

John Springer: Okay. So in Chicago the results of a professional survey were presented and Leslie made some comments about ARIN staffing, and this Draft Policy is the result. For it to go from a policy proposal to a Draft Policy, it needed to satisfy only two requirements: It needed to have a clear problem statement and be in scope for the Advisory Council.

So the problem statement, we worked with the author a bit on this to make sure that it was fairly narrowly crafted: ARIN staff, faced with a surge in near‑exhaust allocations and subsequent transfer requests and a requirement for team review of these, is spending scarce staff time on needs testing of small transfers. This proposal seeks to decrease overall ARIN processing time through elimination of that needs test.

The reason the survey’s pertinent is that one of our biggest areas of opportunity in ARIN is possibly to reduce this processing time. Relatively simple policy statement. There’s identical text in Sections 8.3 and 8.4. We’re going to replace the existing text, which is the “from” section with the “to” section.

I advise a careful reading of the “to” section because it’s kind of worded in a negative way. It is written to concern transfers larger than a /16 and effect transfers smaller than a /16. Needs testing has been maintained for transfer for a number of reasons over the years, some of which include the community likes to ensure protection against hoarding and speculation in the v4 market.

This proposal seeks a middle ground between the elimination of needs tests for transfers altogether, which we have seen has happened in other places, and the continuation of needs test for every transfers, which implies continuing lengthy processing times for ARIN services.

Pros: Specifically the policy seeks to reduce ARIN processing time for small allocations. There’s been a considerable amount of back and forth on the list about this, quite a bit of discussion about whether or not a /16 is a small allocation.

Leslie had some figures earlier in the week that indicated that, of the total number of transfers that have taken place to date, roughly half of them are larger than /16 and roughly half are smaller. So clearly with that as a metric, this Draft Policy, if implemented, would have an effect.

There’s also been the mention, you know, everybody’s always aware that the small entrants, people that need a /24, have a hard time with that. This would probably ease that, although that is not a specific intent of the Draft Policy. Also there’s a perceived unfairness with a lot of small operators that are seeking PI resources. And this might coincidentally increase Whois accuracy to the extent that we’re able to get some resources registered in an accurate manner.

Like I say, there’s been a considerable amount of discussion on PPML about this. A lot of it has revolved around the question of what is small: Is /16 too big? Is /24 too small?

One correspondent raised what I thought were fairly pertinent points about how to assess success. And another comment was proposing a graduated approach might be more appropriate than just doing it blankly on /16. And then I’ll leave that last comment for reference, if I need it later.

So where this is in the process, the Advisory Council accepted it as Draft Policy. For it to proceed, it needs to satisfy three tests that I mentioned earlier: It needs to enable fair and impartial number policy, needs to be technically sound, and it needs to have support in the community. I need input from this group about those matters. Absence of support is pretty drastic; absence of any of the other two equally drastic.

I intend ‑‑ in working with the author, this is a fairly narrowly crafted thing. The author has expressed a willingness to play with the math. And there’s some interest, apparently, for doing that, adjusting that /16 in some direction or another. I hope that policy can be worked on between now and October and presented in Baltimore because this is a perennial subject that keeps coming up. There’s people that want something to be done about the needs basis, and there are people who do not want something to do about the needs basis.

In the past it’s been a challenge to try and obtain a narrow enough framing on this to be reasonable about it, and I think this might be a good opportunity for that. At any rate, I throw the floor open and ask for comments.

Paul Andersen: You beat me to it, so go for it, sir.

Bob Evans: I had to speed it up.

Paul Andersen: I’m trying.

Bob Evans: Bob Evans, Fiber Internet Center. I kind of see this as a Trojan horse. I love the fact that there’s a Paperwork Reduction Act within this proposal here, but at the same time the /16 is way too big to be considered small.

One of the reasons is a lot of us are old enough to remember what the Hunt Brothers did with silver when it became a real commodity, and I think we’re opening ourselves up to this same thing. I think it’s going to be very unfair for smaller ISPs as somebody goes around and figures out how to get /16s and transfer them to their little network in Dubai. And there’s a lot of stuff if you’re going to move something that big.

But I’m totally in favor of speeding up the Paperwork Reduction Act of lowering it to, say, a /20 or something like that, would be ideal. And I think there’s just too many opportunities to corner the market on stuff like this, because it’s going to be a what’s available in the private‑sector marketplace and that gets scooped up and then the prices of IP addresses will go way up and then you’re going to have the smaller ISPs harmed even if they have to go to that market after ARIN’s exhausted them. While ARIN’s been able to keep, in fact, if you think about it, the price of IP address space reasonable, by still having some when it runs out, that’s not going to be true.

The second point is you can say: Oh, well, we have a hammer at ARIN and can tell them this isn’t right. And then they’re going to say: Oh, we have a venture fund and a hedge fund over here with a lot more lawyers in it. And then you’re going to stop all transfers, and that’s going to then hurt the small guy again. So this affects the market quite a bit for smaller ISPs if you make it a /16.

Paul Andersen: So you’re not supportive as is, but you could be supportive if the /16 was replaced to a /20?

Bob Evans: Put it back to what really is small: the /20.

John Springer: My intention with this is to take the results of this meeting back to the list. Like I said, there was a pretty frank exchange of views on the list. And the issue of the /20 threshold will definitely be taken up there, and I look forward to your comments when that takes place.

Bob Evans: I didn’t get to see the information you referred to earlier about the 50/50, 50 percent larger than a /16; 50 percent smaller than a /16. So what was the number used? How many transfers was that?

John Springer: I’ll need to develop that information further. That was just a swag of the data.

Bob Evans: So we’re swagging this stuff to us, are we? I mean, was it 100? Was it 200? Was it a thousand? Does anybody know?

Paul Andersen: Leslie can comment. I hate to do it to you, but…

Leslie Nobile: So we completed roughly 72 8.3 transfers, and 39 of them were /16 and over. Larger. Larger ‑‑

Bob Evans: 39 would have been caught by this.

Unidentified: Big numbers.

Bob Evans: Right. And 256 IP addresses is not small. Thank you.

Paul Andersen: Thank you very much. Next speaker, please.

Joe Provo: Joe Provo, Google. I oppose this strongly on at least three points, maybe more if I can think of them. One, I guarantee you that 100 percent of your transfers will be less than whatever bar it is, if you make needs‑based go away for a certain bar. People merely manipulate their requests, stage them, what have you.

Number two, the entire point of IP addressing while markets and whatnot are nice ‑‑ the entire point is utilization and actually providing service. That is a need. If we eliminate needs‑based, then we basically said we’re really in a derivatives game. That’s it.

And, third, that con right there, the final one, the rule‑breaking behavior, we’re essentially saying that, yeah, all this policy process is nice and all, but we’re just going to roll over to what people do. That’s it. Thank you.

Paul Andersen: Okay. Opposed. Next.

Christoph Blecker: Christoph Blecker, Disney Interactive. I’m not in support of it as a /16. I would be open to supporting it as a /20. And the reason is, and I think it’s a very important part of that text, is that the relief from needs basis is only for the first transfer in a 12‑month period. If somebody’s going back and staging these out, they have to wait another year before ‑‑

Paul Andersen: Or do the needs.

Christoph Blecker: Yeah, to ‑‑ either need to prove needs or they need to wait a year before they can do another needs‑free transfer. So that paired with lowering the bar to a /20, I would find that ‑‑ I would be open to supporting that.

Paul Andersen: Not as written but supportive at a /20?

Christoph Blecker: Yes. Thank you.

Mike Joseph: Mike Joseph, Google. Unsurprisingly I oppose this, and I would oppose it at any bar. As my colleague earlier pointed out, you choose a /24, people will simply transfer a series of /24s ‑‑

Paul Andersen: Even given the context that was previously put, that they’d have to wait?

Mike Joseph: They wouldn’t wait. They would have subsidiaries. And then the argument about the Whois being accurate is such a red herring. That’s the argument that’s thrown up every time we talk about implementing proper policy; that if we implement policy, people will simply not comply with it.

If we have a compliance problem, we ought to deal with that. But watering down our policy in favor of essentially being just a recorder of deeds is not where ARIN ought to be going in my opinion. So I strongly oppose this policy as written and in any future revision.

Paul Andersen: Fundamentally opposed?

Mike Joseph: Indeed.

Paul Andersen: Thank you. I’d ask if you’re going to speak that you approach the microphone now or start typing because we’re going to close the microphones very, very shortly. Next speaker, please.

David Huberman: David Huberman from Microsoft. I’d like to ask the audience to get their heads out of the sand and come back to the real world and out of la‑la land.

Guys, this is going to happen. It’s already happening. When ‑‑ I don’t want to use my example because I’m a big company with a lot of money and that’s not fair. But if I work ‑‑

Paul Andersen: Dave, could you ‑‑ you’re also just hard to hear, but could you ‑‑

David Huberman: If I work at a network that has some money and I need IP addresses and I can’t go to the registries, I’m going to go buy the IP addresses that I can afford to buy for whatever period of time I choose to buy them. I might go by a one‑year supply; I might go buy a two‑year supply; I might have the money and the resources and the interest and engineering interest to go buy a five‑year supply. And I’m going to do that, and it doesn’t matter what ARIN’s rules say. I’m going to go do it because my responsibility is to run my network, to my company, for my customers. I’m running a network. And ARIN is irrelevant to that. Because it doesn’t matter if Whois says that or not; it matters that I can use them.

So if we believe that policy for the sake of enforcing utilization is really important, then I don’t know how you reconcile it with the fact when there’s no v4 addresses left in the well and I need more v4 addresses, I’m going to go buy them and nothing’s going to stop me.

Paul Andersen: I think we’re kind of veering a little bit off here, but I’ll let John ‑‑

David Huberman: Veering off? It’s germane to the whole needs base.

John Curran: I just want to answer the question. In the case where the addresses are registered to another entity ‑‑

David Huberman: Yeah.

John Curran: ‑‑ but you believe you’ve acquired the rights to them ‑‑

David Huberman: Yeah.

John Curran: ‑‑ your assumption that the registration doesn’t matter would be predicated on the if you route them ‑‑

David Huberman: That fact that my ‑‑

John Curran: There’s a whole question coming ‑‑ at the point in time when you route them, even though they’re listed to another entity, that other parties would accept those routes.

David Huberman: Yes.

John Curran: Okay. And I guess the question is: That’s certainly true for some entities, but do you believe it’s universally true?

David Huberman: I believe that in the real world in 2014, with your relationships with your peers and your transit providers today, when you tell them you’re announcing something and you have that authority, you’re going to do it. Some people require letters of agency, and I get that letter of agency from XYZ corporation whose addresses I bought. And that’s it.

John Curran: The only challenge with that assumption is that in a lot of cases those addresses haven’t been updated in 10 or 15 years, and anybody can scribe a letter of agency. So I guess my question would be I’ve ‑‑ what assumptions ‑‑ you’re saying it doesn’t matter what it’s registered as. Following that, I guess, I’d just like to know the assumptions. Your assumptions are that it doesn’t matter to anyone, not it just ‑‑ or it doesn’t matter to the biggest corporations?

David Huberman: No, I think to the buyer of the addresses, absolutely with the assumption that you’ve done your proper due diligence that you’re buying IP addresses from someone who really is the registrant, it says XYZ in Whois and you are buying from XYZ, it’s not a high bar to clear to buy the addresses from XYZ and to get your peers and your providers to route it with whatever paperwork those peers and providers want to see, which in many cases is none.

John Curran: And it’s not a high bar if you’re a multinational network, or it’s not a high bar for everyone?

David Huberman: No, I don’t think it’s a high bar ‑‑ I don’t think it’s a particularly complex legal transaction; I don’t think it’s particularly a complex engineering transaction.

John Curran: The reason I ask, and just for comparison because you’re speaking from a perspective, is we’ve heard from smaller providers that under those circumstances they don’t have the clout or authority to get those addresses routed even with an LOA because it’s not accepted by their much larger peers. So I’m just asking whether or not your view is based on the particular peering power of one particular group or community.

David Huberman: Well, I understand I represent a multinational large corporation, but I did spend ten years dealing with mostly small folks, and I never got that sense. I don’t want to speak contrary to what other people’s real experiences are, but that’s never been my knowledge in my industry.

John Curran: That was my question.

Paul Andersen: Input taken. I think we need to kind of get back to the concept of whether removing needs test for small IPV transfers is a policy worth working on.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. If ARIN has a staffing issue, I don’t see why we’re putting it into a policy to deal with the staffing issue, which is what the original intent was. But that being said, my issue is the ramifications of this abuse we’ve talked about earlier from some other colleagues, the fact that we are ‑‑ correct me if I’m wrong ‑‑ that this would be implemented outside of compliance with the inter‑RIR compatible needs‑based policies, because we would be removing needs from a segment, and the question would now become: Are we in a compatible situation with the other RIRs we’re doing it with?

Paul Andersen: Two very separate questions I heard. Let’s deal with the second, which is compatibility, and then come back to the first, which John Springer would like to address.

John Curran: Recognize that other RIRs’ compatibility requirements are very low. We probably would not have any difficulty there with respect to that. The first question regarding whether there’s a staffing problem, I’m unaware of any staffing problem with ARIN. I will say compliance ultimately, though, as we just discussed, is about people actually paying attention to their routing and peering. It’s anchored in the community, not in ARIN. We can do a lot to make sure that the records are accurate, but, at the end of the day, you folks have to decide how important those records are.

Paul Andersen: Thank you. John.

John Springer: So one of my initial impressions of this was that it was out of scope for ARIN to be concerned with the staffing measures, and I was informed that it definitely is.

Kevin Blumberg: It was more an observation. The last part to all of this for me is if we want to simplify needs, the needs test, let’s simplify the needs test. Eradicating the needs test before simplification I think is throwing the baby out with the bath water. And, John, to your final note, an LOA is useless for me as a small provider. Without the ARIN record showing that I am in fact the owner, none of my upstreams would touch me.

Paul Andersen: Okay. We’re running out of time. Two things. First of all, after the remote participant has been read, the microphones will be closed. If you’re not standing in line by the time of the end of the comment, that will be the cutoff. And I’d ask the remaining comments be succinct, if possible.

Richard Jimmerson: This is a remote comment by Jason Schiller of Google: There are many organizations that play by ARIN’s rules who will engage in this practice if they can do so and not be on the black market and have legal grounds to moderate disputes of use. Passing this policy will promote this behavior.

Paul Andersen: Did he indicate support or opposition clearly?

Richard Jimmerson: He did not use the words “support” or “oppose,” and I’m watching in the chat room ‑‑ he opposes this.

Paul Andersen: Last two comments.

Tony Hain: Tony Hain. So I guess from a “ask the question here” perspective, consistency of policy across resources, how would the v6 version of this policy be written? I’m basically going to oppose this as written because I can’t imagine a version of it that could be built for IPv6. And if we don’t have consistency, what are we doing here?

Paul Andersen: I was going to say that transfers right now are not even contemplated under IPv6, so I think that would be a broader topic. I take your point, though the whole topic has not been contemplated ‑‑

Tony Hain: Well, it has been contemplated by some –

Paul Andersen: Maybe not been addressed, is maybe the ‑‑

John Curran: At present, the present resource transfer policy starts out with: In addition to transfers under Section 8.2, IPv4 numbers and ASNs may be transferred. So apparently do not have a specified transfer policy for v6. So changing the needs test for a policy that doesn’t exist.

Tony Hain: Understand. But fundamentally you’re removing needs test for small. If I’m thinking about that in a context of IPv6, what’s small? And what’s a needs ‑‑ well, it’s a needs test today, but we’re on the slope. And so I’m going to oppose this as written.

Paul Andersen: Opposed as written?

Tony Hain: Yes.

Paul Andersen: Thank you.

Andrew Dul: Andrew Dul, ARIN AC, not speaking as the secondary shepherd on this policy, of which I am. I think the question that we are debating here is much larger than the actual problem statement that is postulated. And I don’t think that’s necessarily a bad thing. But the word “need” is a very loaded word in this context, and I think there’s a very wide variety of what need means. And what “need” should mean after the v4 runout is something that we need to address in a larger context by understanding what type of marketplace we want to have in the long run for address transfers.

And while I think this policy has opened the door to that discussion, I don’t believe that we want to create another dual‑class type of arrangement where there are certain blocks that are allowed to be transferred without a need and others that must require one. So we previously just discussed about how we are dealing with the legacy/non‑legacy issue now still 20 ‑‑ 15 years later. I don’t want to create another class of issues by making another bifurcation in our policy. So I think we need to be consistent on what we do in the post‑before world regardless of the size of the box. So I oppose this as written currently.

John Springer: I don’t have a comment directly to Andrew, but thank you for that, Andrew. So the immediate thing that I plan to do with this is to take it back to the list. There are ways that statements can be made in this type of a venue, which more or less, in my opinion, require that to be carefully considered and analyzed and evaluated for a number of different things. So that’s what I intend to do with this, and I thank everyone for your input.

Paul Andersen: Thank you very much. That ends that policy. So we’ll move on to the next one. John.

John Curran: Okay. Next up is ARIN Policy 2014‑15: Allow Inter‑RIR ASN Transfers. Scott Leibrand.

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

Scott Leibrand: This may look familiar. We already allow transfers of ASNs within the ARIN region. We had a proposal to do so between regions in 2013, 2013‑1. That proposal was recommended for adoption and consulted in the community, and a bunch of people said: What’s the point? Nobody else, no other RIRs, can do ASN transfers, so this policy would be one‑hand clapping. So we abandoned it at that point, intending to pick it back up if any other RIRs adopted a policy proposal for ASN transfers. APNIC has done so, so therefore we had a community member who brought back the 2013‑1 text as it was on the website and proposed that to be put back into the process. That text is here in red and black.

In making this presentation, I also noticed that a previous version of the presentation had additional corrections that never made it to the version he used for starting this. So those are in blue. They simply clarify that we’re not saying if you get an ASN transfer that means you can’t get an IPv4 transfer. No. You can get a transfer of either resource according to these conditions. That’s fine.

This is a pretty simple proposal. It basically adds the words “or ASNs” to the inter‑RIR policy and then cleans up a couple of things. So having brought this back into the process, we’re looking for feedback from the community as to whether this text is the right way to move forward with this: if you support the idea of allowing Inter‑RIR ASN transfers, if you don’t support it, or do you just not care, in which case you don’t have to get up. But particularly we’d like to know if anyone supports or opposes this idea and has any input on the text. So take it away.

Paul Andersen: You know the drill. Straightforward one here. Any comments on this suggestion?

Kevin Blumberg: Just one question. Kevin Blumberg, The Wire, ARIN AC. Right now 4‑byte ASs ‑‑ and I’d love the RIRs to confirm this ‑‑ are completely and utterly clean in terms of which blocks which registries have. There’s no fragmentation or segmentation within that block, unlike the 2‑byte ASs which are completely fragmented all over the place.

John Curran: Yes.

Paul Andersen: Yes.

Kevin Blumberg: So that is the case?

John Curran: To my knowledge, except for the unusual exception of the block of 4‑byte which is actually the 2‑byte, yes.

Kevin Blumberg: I do support this but not as written because my concern is that what we’re actually doing is for the first time we have something clean and we’re going to allow it to get unclean and broken ‑‑

Paul Andersen: But how would you ‑‑ how would you propose correcting that?

Kevin Blumberg: Or 4‑byte ‑‑ sorry, 2‑byte ASNs get ‑‑ don’t allow 4‑byte.

Paul Andersen: Okay. Kevin? Do you have one? No?

John Curran: So given clean 4‑byte blocks out there as allocated per RIR frameworks, how is that beneficial? I guess I’m just wondering: At some point do you anticipate filtering on them, on those boundaries, or is this gross geolocation? I guess I just want to understand the benefit that’s being achieved by maintaining that.

Paul Andersen: Here’s a question: Do you anticipate any large operational impacts on the fragmentation of the database with IANA and yourself?

John Curran: No, but I just want to ‑‑ if there’s a purity benefit there, it needs to be described globally, because I can’t say that you won’t get transfers between any two RIRs globally. So I want to know what you’re obtaining as a benefit.

Kevin Blumberg: By moving it to allow for Inter‑RIR transfers, we’re going back to the discussion is this for vanity or is this a real reason to be doing it. There’s a whole bunch of things that we can get into. The reality is this is clean. Or the 4‑bytes are clean right now. There’s no reason to recycle them today. I don’t know if ARIN has a plan to recycle them, or once it’s ‑‑ to an entity.

We actually have a chance with the amount of 4‑bytes there to not have to deal with who was on a 4‑byte, where it was, which region it was. We know where it is today, and there is I think some thought and benefit to that. Might it matter? No. But I think we should have some discussion in that area.

Paul Andersen: Thank you very much. Geoff.

Geoff Huston: Geoff Huston, APNIC. Not a for or against this proposal, but I observe that sometimes when you walk on the beach and you kick what looks like a small rock, your foot gets broken. And when you start digging, it turns out to be a massive great boulder and you’ve just done it.

What do we do with transferred resources in general? Because IANA gave a block of something to one regional registry and little bits drain over into other registries and how do we track those little bits that they’ve gone from A and appear in B?

Now, the reason why I ask this is we have been inconsistent. And, in particular, in the 2‑byte AS number sub-registry, at one stage, about three or four years ago now, we gave back to IANA the records of all the detailed movements. So in theory IANA knew, not what it did but what is at that time, which AS number was in control by which registry, whereas in the IPv4 and IPv6 addresses, when resources have moved, we have not done that.

Now, you’re about to go through the same sort of issue again when you talk about these transfers. And at least this time, eyes wide open, how do we as a network of registries record this kind of where is the resource, which registry is the authority, because currently there is no such map. Now, if you made IANA do this, let me talk about the boulder you’ve just kicked your foot into.

Paul Andersen: The painful boulder.

Geoff Huston: The painful boulder. Because over on the other side we have this thing called RPKI. And RPKI needs to be accurate all of the time, right? Because if it isn’t, really bad things happen to everything, because a little mistake means all your certs go invalid. So all of the time it has to be accurate. Over here you have six registries in I think six different time zones, each of which are doing updates at different times.

So, by design, those registries will be inconsistent when you’re going up to IANA and back. Which means, by design, because of differing cycles on cert production, you’re going to stuff at least one‑fifth of the world in routing all the time. So you don’t want to do that; I don’t want to do that; none of us want to do this. But what’s the design principle when you’re talking about moving resources, about understanding and tracking who’s the authoritative registry? IANA is not perhaps the best answer, practically speaking, but we’re talking about practicalities here and the policy needs to be implemented. And just saying what we do now is not a good answer because we don’t know what we do now consistently. So might I just have a plea that, unlike APNIC going, yeah, that’s fine, you at least think about this problem and maybe say to your NRO folk or whatever: Guys, get it together. Thank you.

Paul Andersen: I would be remiss if I did not let John ‑‑ you thought you were escaping that easily.

John Curran: So I have a question and then another question. My first question: From your soliloquy, I would take it to say that the assumption the bright RPKI folks will just figure that out is probably not a good assumption.

Geoff Huston: I’m pessimistic that the bright RPKI folks are willing to dilute their security framework ‑‑

John Curran: Right. Understood.

Geoff Huston: They would like perfection in the registry.

John Curran: I’m on SIDR now looking at the same draft. So ‑‑ okay. So since we’re all looking at the same thing, given that, that would say that it would be good to get some feedback to all the RIRs saying, hey, while Whois, or whatever you’re using to publish this stuff, may let you punch holes and all cope with one another, poorly, particularly, RPKI in particular doesn’t. And I think if that information were related to the NRO, we could get it to our communities. But we need the RPKI wizards to explain keep contiguous blocks at the IANA is a good thing.

Geoff Huston: Well, that’s part of it, John, keep contiguous blocks at the IANA, because what you’re really saying to IANA is: Record what you did. Right? Record your actions. And that’s it. But at the RIRs we’ve now got this problem of saying if the registries reflect what is, we’ve got these holes being punched, how and where do we understand how people who use these registries, the consumers, never get the twisted little paths of, well, ARIN got the block but APNIC has the instance. And when you start talking about transfers, which is why I bring it up here, policy is fine, but implementation is everything. And it’s the implementation of this that is the nightmare. Shouldn’t say “nightmare.” Challenge.

John Curran: Challenge.

Geoff Huston: Challenge. Thank you.

Paul Andersen: Thank you. So we’re running a tiny bit behind, which I know is a little different from this morning, and we still have two proposals, so I’d ask if the remaining speakers could be succinct, if possible, please. And if you wish to speak, please approach the mic clearly right now. Thank you.

Mike Joseph: Mike Joseph, Google. I support this policy. I think that ‑‑ yeah, I will also observe that, Geoff’s comments and concerns notwithstanding, there’s probably a need in the future to also look at a more generalized way of handling multinational M&A and restructuring between RIRs. And that’s something that we should probably look at because that’s going to be relevant even for IPv6 most likely. But certainly for ASNs. Nonetheless, as written, I support this policy.

Paul Andersen: Thank you. Last one.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the policy. However, due to comments, I think we should ‑‑ there’s no burning need for this, so let’s be cautious and let’s figure it out before we put a stamp on it.

But one thing I would want to add is in the v4 world we had this chant of registry accuracy and that was what was paramount and we had to have transfers in order to maintain registry accuracy. Why isn’t that true of ASNs? Just a question for people to think about.

John Curran: The same reason it’s not true for v6. In a world where you can go get another, okay, then the people who want it go get another and it accurately reflects that. It’s the world where you can’t readily go get another that you end up using someone else’s.

David Farmer: That’s only one piece of transfers.

Paul Andersen: Thank you. So seeing no further comments, we thank the community for input and we’ll move on to our next topic and try to catch up on time. Thank you.

John Curran: Next up we have the Draft Policy ARIN‑2014‑16: Section 4.10 Austerity Policy Update, and I will ask Dan to come up and do the presentation.

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

Dan Alexander: Section 4.10 of the policy manual, its intent was originally to facilitate transition technologies in reality post depletion so people could continue to get a small block of v4 space after the free pool is depleted in order to deploy different transition technologies. This policy proposal suggests that maybe a better or maybe an alternate way of dealing with this is to mirror or copy what other RIRs are doing with an austerity approach of rather than focusing on transition technologies, provide a mechanism to just give new entrants small blocks of v4 addresses in addition to the v6 blocks that they would be asking for.

So there’s three I would say key points to this proposal. One is it’s the wording of it is limited to people who don’t already have resources of a /22 or larger. So if you’re a new entrant or you currently have a very small block, you could come back and use this policy to get a small allocation. The other piece to this is the original policy actually had a /10 set aside for this purpose.

What this proposal also suggests is this pool would be fed by any blocks that ARIN gets as a result of the post IANA depletion policy, where actually in the case that happened recently, ARIN received a /11, I believe, from IANA, and that’s currently, I believe, on hold waiting the outcome of this policy to determine should that be added to the pool or not.

So this is still in the early stages since we’ve just gotten this proposal. But we’re really looking for feedback of, one, is this a good idea, do people agree with it, and, even more detailed, do you believe that the pool for this should be fed by those IANA assignments and are the blocks correctly sized and should this be limited to new entrants or should anybody be allowed to still obtain one of these small blocks. So feedback welcome.

John Curran: Microphones are now open. I’m chairing this as Paul had to step out. Front and center mic.

Andrew Dul: Andrew Dul, ARIN AC, speaking for myself as the author that wrote this proposal. I wrote this in collaboration with a number of other people at the end of the last meeting trying to address the issues that were raised by ARIN staff about the after v4 runout policy. So I believe this addresses a specific area of bootstrapping new entrants, none of whom are in this room. So the fact that people don’t speak for this policy in this room is probably because they aren’t here. And they may not even be on the Mailing List at this point. So I think we need to take a larger look at how we as a larger Internet community support people who don’t know that they need to go to ARIN to get address spaces.

I’d point out that similar policies in the RIPE and APNIC region have been fairly successful at bringing new entrants directly to the registry and providing them with address spaces, and I believe we should learn from that model and adopt a similar policy. As the author, I am agnostic about putting the IANA reclaimed into this block. If people don’t want it, it’s okay with me. I personally believe it should be there. If people want to pull it out, that’s okay. And I thank you.

John Curran: Next speaker.

Mike Joseph: Mike Joseph, Google. I oppose this policy. Fundamentally I think that this policy seems to throw out the original intent of the idea of allowing for transition technology space. Yes, we’re going to have some new entrants. We could carve out some type of soft landing for them and deplete our remaining v4 space quickly for the new entrants that come in in the last few months and get a little bit more run rate out of our current space, but that’s at the cost of taking what was intended to be in this earmarked nest egg for future transition purposes and making that no longer available. In the current form, it can last us quite some time for that additional space you happen to need to have that legacy v4 service on your otherwise v6 network. And instead we’re really just saying we’re just going to assign or allocate this space.

It also, incidentally, encumbers, for example, the recent /11 that came back. So I think allowing that to become part of the regular pool, allowing people to continue to get space from that is normal, and keeping this protected for the original intended use is the most sensible thing to do. So I oppose this policy.

John Curran: Is there any change to the policy that would allow you to support it? You note that it’s draining from the transition pool. If this policy was purely for new entrants and only using the /11, would that change your view?

Mike Joseph: I see. So you’re saying if we left the transition ‑‑

John Curran: I’m asking is there any change at all ‑‑

Mike Joseph: No, no, but to understand the hypothetical you posed, if the transition pool were left intact but we said this 11 ought to be earmarked for new entrants ‑‑

John Curran: For example.

Mike Joseph: Yeah, I think I would have to contemplate the specific policy language. I’m not really comfortable speaking on that hypothetical at this time.

John Curran: But right now you don’t know any hypothetical changes that would allow you to support it?

Mike Joseph: I have not conceived of such hypotheticals as yet.

John Curran: Okay. Okay. I generally ask people at the mic who don’t support if there’s any changes that would let them, so… Okay. Next. Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. We are putting together three distinct issues: We have austerity, we have IANA return, and we have transition. And by commingling them so much together, we are going to basically do negative things to all of them.

Yes, John, I believe that this should be a completely separate section, completely separate pool that has nothing to do with transition, leave transition alone until we actually get into a phase where we need to drain down the transition pool and we can see what happens with that and write policies with that in that regard.

I am ‑‑ I don’t like the idea of overflowing the bathtub from IANA returns continually until the cows come home. If you want to fill the bathtub the first time from IANA, great, but I really don’t believe it should be solely used for new entrants. I think that’s unfair to the rest of the community. Give the new entrants their initial block, and then, like everything else, it will drain down over time as is needed. So I believe overall that, yes, I do support something in this area, but I believe it should be its own separate area that can be very easily looked at and dealt with by the community.

John Curran: Next.

David Huberman: David Huberman from Microsoft. Strongly support this policy. You have to understand, if you look at the history of ARIN allocations, about 85 percent of the address space goes to about ten companies. The large networks in this region use almost all the address space. It’s been very unfair for small providers the way the rules are structured, especially ISPs who have to be of a certain size with space from their ISPs to get space from ARIN. It’s been inequitable for 15 years, I assert. With that in mind, I come to the mic saying, well, of course we should do this. Not only should we do this, we should have done this a long time ago. Large providers, large networks who are drawing down almost all the space today don’t need to draw down any more space as we reach exhaustion.

Let’s save all we can for the smaller folks who are just trying so hard to survive, not make them come to us ‑‑ I’m not an ISP, but not make them come to the ISPs and be hooked into an ISP because that’s the only place you can get address space. And transition technologies isn’t real right now. How many allocations have we made out of the transition technology /10? None. Zero. Right?

John Curran: One? None? A few. Two or three. A few.

David Huberman: Holding up a /10, which is a lot of space, and as we get new space from the IANA, the /11 and the rest of these things, without filling the bucket, I think they ought to go to the folks who have the hardest time. And it’s not the big guys.

John Curran: Next up.

Scott Leibrand: Scott Leibrand, ARIN AC and Twitter. First I want to channel something Leif just said on PPML. He was trying to be on jabber but couldn’t. So he said that he opposes this proposal. He said the whole point of the /10 was to provide transition space that did not overlap existing RFC 1918/3330 space. He would support a separate austerity policy for new IANA reclaim and deploys.

Back with my own hat on, the history here of soft landing is kind of interesting. I’ve been around long enough to remember the discussions around whether we should have a soft landing pool. We decided something different than most of the other RIRs did. It’s possible that the success of their policies would mean that maybe we did the wrong thing and we should do something like they did. I’m worried that we are being overtaken by events, though, and it’s too late to make a good course change there.

The path we did choose to take, very much like what Leif just said, was to use this space to make it possible for new entrants to do IPv6. This proposal eliminates that incentive for people to be able to get space if they’re using it for v6 transition. I think that is contrary to the spirit of the original reservation and is less than ideal.

If we were to have a separate block for new entrants that just needed v4 space for having v4 space, I wouldn’t be opposed to that. I’m not sure we can get that done in time. So I think we have to ‑‑ we need to be careful that we’re not saying that we must do this in order for new entrants to be able to get space. I think the alternative that we were thinking would probably be more likely at the time we made the policy we’ve got is that people who need v4 space solely for v4 purposes will be able to get it from the transfer market.

So I wonder if maybe what we should be doing here is instead of trying to chase a very dwindling free pool is to be making it easier for small entrants to get space via transfer with as little difficulty as possible, and that I think will address most of the business need. So opposed as written, would not be opposed if it were a separate pool, but am skeptical that can be done in time.

John Curran: Closing the microphones. Remote participants? Final comments? Excellent discussion. This will be provided to the AC. Thank you, Dan.

Now I’m back. Okay. So last policy proposal, ARIN‑2014‑17: Change Utilization Requirements From Last‑Allocation to Total‑Aggregate. We’re going to do this promptly, and then we’re going to be done. Andrew, come on up.

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

Andrew Dul: So I got to start everything off, and I guess I get to finish it off today. So this is about ‑‑ came from Leif from Alaska, and he basically postulated that the problem here is that because of some math issues around how allocations are being examined at this point is that there are specific cases where organizations aren’t being able to get the next block that they need because they’re slightly below the 80 percent utilization in one block but overall they’re using everything up. So that’s the problem. And how he proposes to change that is that instead of looking at the last block, at the 80 percent mark, he’s proposing to change it to look at the 80 percent mark over all of the allocations that an ISP is and end-user has. So basically this would, for larger organizations with multiple blocks, greatly lower the bar for organizations to obtain new address blocks.

One open question that has not been readily addressed at the Draft Policy at this point is how this would impact the existing utilization requirements that are in the Multiple Discrete Networks Policy. So that’s one of the things that we are looking for feedback on, if the Multiple Discrete Networks Policy should be changed or not or just ignore it. It’s unclear how the two of these would probably interact at this point.

So the questions that we have at this point is do you think that the current utilization requirements are fair and do they need to be changed, and, secondly, do you think this draft addresses that issue at this point. And we are looking for feedback on this to decide whether to abandon this or to continue work on it. At this point the policy has a few people supporting it but not a lot, and not really anyone calling for it to be abandoned, but the support is very narrow so far. So without continued support, the AC would likely look toward abandoning this policy.

Paul Andersen: So microphones are open for discussion on this topic. I do have to read the bullet points at least. Very new on the list, we realize, but I see ‑‑ no? Maybe? Wow. Sir.

Chris Rogers: Hello. Chris Rogers with Inerail. Being a small ISP, I do support the policy, the concept behind it. However, given that this would have the opposite effect for larger networks, allowing them to get additional prefixes more frequently, I think, I do oppose as written, but I would support if there were undecided‑yet wording changes.

Paul Andersen: Anything specific to help the shepherds?

Chris Rogers: Offhand, no, but I’d be happy to take care of that on the list.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the concept. There’s a lot of work needed to be done on it yet. One possible suggestion would be ‑‑ I’m concerned about removing the current utilization mechanisms. I don’t see a good reason to change it for the people that that works for. What I might suggest is an additional total aggregate and set that a little bit higher, like let’s say 85 percent. Just sort of off the top of my head what I’ve been thinking.

Paul Andersen: Okay. Thank you. If you would like to discuss on this topic, I’d ask you to approach to a mic because we’re coming to the end of our time.

Mike Joseph: Mike Joseph, Google. I support this policy. To address a couple comments, Mr. Farmer may not be aware that ARIN’s current practice actually changed recently. RSD no longer looks at 80 percent of all blocks, which may be what you were alluding to in an aggregate utilization of 85. In fact, RSD looks at 80 percent of the most recent block and much higher utilization of all previous blocks. That wasn’t ARIN’s practice until the last year or so. So that’s an interesting point that actually would suggest that a more generous interpretation, I think, might be favorable in some cases.

So the other thing I’d comment on is the question was raised in one of the other slides, I think, concerning what to do about 4.5. And I would offer a suggestion that this policy also be extended to apply to 4.5.5. I think the policy authors correctly observed nothing would be changing in 4.5.4, but I think one could see that 4.5.5, which specifies that each location ‑‑ that each block at each location would need to be used at 80 percent, I would think that the same concept that applies for all ‑‑ for an overall AS ought to be applied within each MDN as well. And so I think that’s sensible there. But, overall, to the point I think that one could envision some type of protection for abuse, but overall I think that might be a welcome change to support averaging of previous blocks.

Paul Andersen: Any comment? I saw nodding. Okay, nodding in agreement. So microphones are going to be closed. Unless I see a body popping up, microphones are closed. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. Just a clarification to start with. So we’re writing a policy to put back to status quo the way staff would handle numbers from 12 to 18 months ago, was this part of a communication or ‑‑

John Curran: So if you read the present policy, the present policy says fully utilized and 80 percent for last block. That’s what we strive to implement. In the past, it had been determined that we were not always checking the fully utilized in the past. And now we do a much better job of that. It’s an improvement to make sure we’re doing things according to the policy text. I believe it might have even been in a Policy Experience Report. But we’re implementing it as it’s presently written.

By the way, fully utilized is very difficult. One or two addresses missing out of a /18 somewhere means you don’t get your next block? So we actually ‑‑ we try to say fully utilized as fully as practical. There’s no addresses that can possibly be reallocated or moved to you. So it doesn’t work out to 100 percent for all previous blocks; it works out to very high utilization, and 80 percent for the most recent. So we’re implementing the current policy text. We may not have had the rigor that we needed in the past.

Kevin Blumberg: John, it’s efficiently utilized, not fully utilized.

John Curran: Sorry, efficiently utilized.

Mike Joseph: Although it’s true that these days RSD seems to take that to mean nearly fully utilized.

Kevin Blumberg: So having said that, I support this. And I will say this: As a smaller ISP, the smaller the box you get from ARIN, the bigger the jigsaw puzzle you have to deal with, the less possible it is to hit fully utilized or anything close to that. So going back to what I have been doing historically, which is utilizing as best I can but making sure overall I was over 80 percent when I went back to ARIN, especially with my last block, should be the de facto standard.

John Curran: Okay.

Paul Andersen: Thank you. And thank you for that comment. And that will I believe end this Draft Policy that is a little bit new. Thank you for that feedback. That ends our policy consultation. Thanks for all the input today. I’ll turn it over to John to close.

(Applause.)

Closing Announcements and Adjournment

John Curran: Thank you. Okay. Hopefully there’s been great input for the AC to consider and stimulate discussion. I’d like to welcome everyone and for attending today. It’s been very helpful. We’re going to have a joint meeting with NANOG in Baltimore, ARIN 34, and it will be Baltimore, the 9th and 10th of October, where you’ll get to see all these policies, or the ones that aren’t abandoned, at that meeting. That’s it. Thank you all for coming, and enjoy the rest of the meeting.

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