ARIN PPC at NANOG 58 Transcript - 4 June 2013 [Archived]

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

Opening Announcements

John Curran: Welcome, everyone. Hi everyone. Everyone out there in the break room, come on in. It’s the Public Policy Consultation. I know people are interested in pretzels and public policy. Hopefully - so, yeah, we should eventually get some people. Very good. I’d like to welcome everyone. I’m going to do a little introduction about what this session is about. And then we’ll actually start going through the discussion of the Open Policy Proposals.

[Music]

[Laughter]

John Curran: Amazing. Thank you. I thank the comic relief team. Public Policy Consultation. This is an open discussion of the Internet Number Resource Policy held by ARIN, and it facilitates in person and remote participation, both today.

It may be held at - we hold them - every time we have a Public Policy Meeting, we do a lot of consultations. But we also hold them in other forums that we think are relevant. Currently the only list that we’re willing to try this out right now on is NANOG. And we’ve done one before. We’re doing this one.

We think this is a good community to be at. We think the cross pollination is helpful.
So I’ll give a couple of quick things. We’ll do an update on the current policies. And then we’ll go through each of the draft policies that are out there.

And this includes the Inter-RIR Transfer Policy Proposal, the 3GPP Network IP Resource Policy Proposal, the RIR Principles Policy Proposal, and the LIR/ISP End User Definition Proposal.

Welcome remote participants. Do we have remote participants? Yes. Okay. There should be a webcast. I’d like to thank the people for whatever measures it took to get that back up for this.

There should be a live transcript. There’s someone else at the end of the remote webcast who is transcribing it and putting it out there. So understand there’s a little lag, but there’s a transcript.

Downloading the meeting material. You can get online. Chat room, online virtual microphone and hands up show of support; when we ask for a show of support, you can be counted.

Okay. The Chair, in this case Vice-chair, Paul Andersen, will moderate the discussions of the actual draft policies so everyone can speak and all can be heard. Please state your name and affiliation each time you’re at the microphone. Please comply with the courtesies in the Discussion Guide.

If you’re in the room, there’s this handy dandy Discussion Guide. If you didn’t get one, there’s a bunch on the table over there, but I also see Susan passing them out.

Very good. Head table. Paul Andersen, myself, Kevin Blumberg, Bill Darte, who is our jabber monitor, Scott Leibrand, AC, and John Sweeting, the Chair of the AC. John Sweeting is going to give the update on the AC Council activities.

Update on Advisory Council Activities

John Sweeting: Good afternoon, everyone. John Sweeting, AC Chair. Quick update on Advisory Council activities. So as John said, we have four draft policies that will be presented today. What we’re looking for is feedback and input on whether you think the policies are crafted correctly and what we can do to change them to make them more effective, and if you support them or if you’re against it.

Of course, we’re always interested in how many people we can get supporting these policies. We also have two policy proposals. Although it says newer items, one isn’t really a newer item. I believe one is 182, Einar - let me go to draft policies. John already talks about these.

We’ve got the Inter-RIR transfers of ASNs, the 3GPP network IP resource, the RIR principles, which is the 2050 debate that’s going on on PPML right now today with a lot of good discussion.

Hopefully we can keep it up at a level of good discussion and keep the bad remarks out of there, just respect everybody on the list and put your opinion out there and let other people put their opinions out there, please.

And then the LIR/ISP and End-user definitions. Oh, so Proposal 186, Section 8.2 reorganization, this proposal, when the AC looked at it, it seemed that it really didn’t need to be a policy, draft - recommended policy that had to go all the way through the process.

We posted it out on PPML and asked for input, if there was any objection to us handling this as an editorial change to the NRPM. And that period ended May 29th or 30th.

There were no objections noted. So the intent of the AC is at our next call to vote to recommend this to the Board of Trustees as an editorial change to the NRPM.

But the real reason that we believe that was because Chris Grundemann, who ended up rewriting 8.2 for an earlier policy, actually said, “Oh, I just left that out by mistake,” because his intent was not to leave that word out.

So we’re just actually putting the word back in that was there all along. Prior to that change in that ARIN was still following that guidance even today. So that proposal will most likely be eliminated once we make that recommendation to the Board.

And then there’s ARIN Proposal 189, allocation of IPv4 and IPv6 address space to out of region requesters. That is an ongoing - we got it in like the day before our last call so we couldn’t do much with it at our last call. So it’s still in the proposal state.

And that’s it. I would like to put in - the good work of the AC.The AC does go out and support a lot of community outreach functions, the ARIN on the Road and several others. And also, as you can see, we’re here supporting this PPC here at NANOG.

Lee Howard: My name is Lee Howard from Time Warner Cable. I think you and I may have met once.

John Sweeting: I think I see you sometimes.

Lee Howard: I think you used an acronym that maybe not everyone in the room is familiar with. I don’t know if you can spell out what NRPM means.

John Sweeting: Yeah, I can. I was going to - Number Resource Policy Manual. I couldn’t get past what John just whispered - network.

Lee Howard: ARIN’s policies. But I wanted to ask you. Is this an opportunity for discussion of the proposal that you just discussed or are those not up for discussion right now and you want to get to the draft policies?

John Sweeting: Draft policies are the priority. We’re going to go through them first.

John Curran: Thank you, John.

[Applause]

John Curran: I’m going to do the introduction for the draft policies under the discussion.

Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of ASNs

John Curran: The first one we’ll discuss is Recommended Draft Policy 2013 1. This has been recommended by the AC. They found it properly formed and it is a candidate potentially to go to the Board of Trustees after it goes to Last Call in preparation to go to go to the Board of Trustees. This is a Section 8.4 change, Inter-RIR transfer for ASNs. The history: Started out as a proposal in 2012. The AC shepherds, Scott Leibrand and Rob Seastrom. Presented at NANOG 57. Was promoted as Recommended Draft Policy 2013-1. It was presented at ARIN 31 in April 2013 at our Barbados meeting. It’s on the AC’s docket. The text is available and in the Discussion Guide, both online and in the Discussion Guide.

The staff summary: Would allow the transfer of ASNs along with IPv4 address space in an 8.4 Inter-RIR transfer and applies the same criteria currently listed for IPv4 ASNs. No similar proposals or discussions. Something to be considered is without similar proposals or discussions, this requires a matching policy proposal at the receiving RIR because it’s an Inter-RIR transfer policy.

So if this was adopted, it would be one hand. There would have to be some other RIR doing something else. I don’t know how much the priority is one way or the other on the other RIRs.

Staff legal assessment: The policy is clear can be implemented as written. It would be a minimal resource impact and poses no particular legal issues. Previous discussions: Very little communication on this or conversation. No posts for or against on the Public Policy Mailing List.

And with 102 people in the room, we had seven in favor and eight against at ARIN 31. And when asked should the AC work on this, eight in favor, 12 against. So it’s a fairly lukewarm policy. No one particularly loves it or hates it from what we can determine. And I’m going to now turn it over to Scott to do the AC presentation.

Scott Leibrand: This policy proposal is quite simple. ASNs are already transferable within the region. Not transferrable out of region. So this will allow that if another RIR were interested in doing so. The benefit to doing that, obviously RIR ASN resources could be recovered and used.

The registry could be updated when ASNs are transferred because of business needs of various sorts, when - many of the actual use cases that we’ve seen so far are not people selling addresses to someone else, they’re I’m using the address at this other place for this other reason and I need to update the records and 8.3 transfer is the easiest way to do that in a lot of cases, this would allow if another region participated in an 8.4 transfer to do similar things.

And this allows for some parity between the policies for in region and inter region. Most of the folks who have spoken out against this did so on the basis this isn’t really necessary. For several reasons. One might be that they don’t think that ASN transfers were necessary to begin with.

Another might be that there’s no shortage of them. And as John already mentioned, without a similar transfer policy allowing that in another region, simply nothing that this policy proposal does in that situation. So our question as the AC to you as the community are: Is this necessary and useful? And should we move this forward or abandon it?

As you saw on the previous slides, we had some lukewarm response from the community because most of the folks who spoke up in favor of this policy proposal were from the NANOG community, I felt it was important to bring it back here and hear from you guys.

If you really think this needs to move forward, I’d like to hear from you guys at the mic or with your hands up when we ask the question. In the absence of any interest, then I’d like to hear people’s opinion whether we should go ahead and abandon this as unnecessary. One way or another I’d like to get your input as to whether we can make a decision here.

Paul Andersen: Thank you, Scott. As pointed out, this is the audience participation portion. If you have any comments or questions on this proposal, as Scott stated, we’re really struggling because we’re just not getting a lot of support. So if you could stand up now, if you’re in the room and come up and state your name, affiliation, whether you support or do not support this policy.

Lee Howard: Here, let me model that behavior. Lee Howard, Time Warner Cable. Opposed. Mildly. I don’t think it’s necessary. I don’t know that it’s useful. But I did want to ask a question because I believe that this would modify or be affected Section 8.4, the policy manual, specified transfers for Inter-RIR transfers, which says that: May take place only by RIRs who agree to the transfer and share reciprocal needs based policy. Do we have needs based policy for ASNs? Do we have to demonstrate that you need an ASN, is that correct? And do other RIRs also have needs based ASN policies?

Paul Andersen: Mr. Curran?

John Curran: So recognize that we don’t preemptively mail people postcards with random ASNs on them. They actually have to say they want one. For purposes of ASN that is saying you have need, and it’s the same in other RIRs. So we recognize such as a needs based policy.

But level of rigor varies by RIRs. Some RIRs, you actually have to say I’m tending towards multi homing or some equivalent statement. So it is not necessarily each RIR determines what is appropriate there.

Lee Howard: So can I infer you would read the other RIRs needs based policies as compatible?

John Curran: When another RIR passes a policy or proposes one that’s similar, I will stand in their forum and tell them whether it’s compatible or not, which I’ve done for all the Inter-RIR policies so far.

Lee Howard: Okay.

John Curran: But, no, I can’t preempt.

Lee Howard: Even less useful.

John Curran: Right. Thank you.

Paul Andersen: Others that have a view on this policy, we ask you to approach the mic. We also of course have remote participation. So please feel free to start typing madly if you would like to ask a question by jabber monitor. John, go ahead.

John Curran: Lee, I wasn’t trying to be flippant, but I wanted to be very clear: Right now the current ASN policies of the other RIRs may or may not be needs based at all. The level of need is hard to discern. It varies by RIR. Someone while proposing a policy for Inter-RIR transfer, another RIR, might say the purpose for transfer is the needs based test.

Just like in the RIPE region, they may eliminate the needs assessment for IPv4 as a general thing in their policy manual; that doesn’t preclude someone introducing a policy that introduces needs assessment simply for transfers. So we really need to see the specific policy proposal before people comment.

Paul Andersen: Other comments or feedback on this proposal? Again, we’re really struggling. Feedback is useful even if just to come up and say you’re in support or against.

Stacy Hughes: Stacey Hughes, TW Telecom. I will vote to abandon this as an AC member because it’s irrelevant. Thank you.

Paul Andersen: Thank you for that feedback. I don’t see any other people approaching the mic. And any jabber comments left? We have one queueing up.

Jeff Hankel: Jeff Hankel, Louisiana State University. I’m very new to this space. I thought ASNs were unique and global. Why are we talking about transferring from one or not to another?

Paul Andersen: John?

John Curran: And I have no view - I’m the staff. No view in favor of both; whatever you folks decide makes sense. We do have cases where people may have a business unit that’s moved to another location. Or they may have some sort of change that they’ve gone through and they find themselves able to update the records for IPv4, but they may not be able to indicate that business is now in another region and another RIR, for example.

Because our policies say once it’s assigned to you, you can use it or you can return it, we don’t recognize - and we do recognize transfers within the ARIN region, even though someone can come get a new ASN, why would you transfer one?

You only update the records accordingly. Because it’s been moved to a new business. If it’s moved to a new business in another region, there’s presently no way to officially recognize that it’s left the building. Does that make sense? I’m not sure that use case comes up very often. But it is a possible use case.

Paul Andersen: Rear microphone.

Jared Mauch: Jared Mauch, NTT. If I want to update a record and provide you a valid address and it’s not in your region, will you update it? Even if it’s the correct address?

John Curran: So the organization - if the organization is in the ARIN region, and you are saying you’re changing the organization record to reflect it’s now out of region, because the organization moved.

Jared Mauch: Maybe my mailing address is out of region.

John Curran: We’ve had that happen. There’s no - there’s no enforcement of that, per se, but there are people who want to reflect the fact that the business is broken up into pieces, they’re still here but that piece is now in another region.

Jared Mauch: So I think what it sounds like is that this proposal may not be necessary because you will update the records based on the request of the person from whom the resources have been allocated to even though they’re outside of the region?

John Curran: Right.

Kevin Blumberg: One thing I wanted to clarify. Each region was given blocks of AS numbers. So that’s why it needs to be done. And I believe that was part of the intent of the original question.

I believe one of the benefits of this is to allow both IP space and ASN numbers to be transferred at the same time through 8.4, whereas right now what you would need to do is an 8.4 transfer of the AS number - sorry, the IP numbers, and not be able to transfer the AS number but probably use it but not necessarily know where it’s actually being used.

So I don’t know if you can do an 8.2 transfer out of region, which would be a merger and acquisition. So if you’re selling from one unit to another, you couldn’t necessarily do it out of region. So this would allow for some out of region both basically transfers and sales.

Paul Andersen: John, I want to clarify, because I guess the previous question was maybe the policy is not relevant, you’re talking more about address updates. But this policy would allow you to transfer to another organization altogether, correct? Which you would not do without this policy? Out of region. In region but not out of region.

John Curran: Presently a party could say I have more IP addresses than I need. I’m transferring these numbers to a party in APNIC, reciprocal party with ARIN, and you could transfer IPv4 addresses.

If you then said I also have five AS numbers and I want to get rid of two of them and I’m going to sell them to the same unit over there in the Asia Pacific region, we would say that’s not possible. We literally will not allow that transfer.

Now, you could - they could use them. We don’t enforce routing. But if you actually wanted to sell the ASs, that’s not actually possible per policy.

Paul Andersen: Thank you for that. Rear mic.

Jeremy Schmikel: Jeremy Schmikel from IBBS. So basically the way I’m understanding this policy is one of the main use cases, I guess, from what I understand is if say that my business is located here in the United States, and it’s purchased by a larger company or larger entity that happens to exist in another RIR, and the v4 address could be transferred under this policy but I would have to apply for a new Autonomous System Number, if all resources were moved.

However, if I still have a network footprint here, the majority of the network footprint is here in the ARIN region, even if the company lived in another RIR, say like the mailing address, for instance, was another RIR, could we technically keep the Autonomous System Number without any issues?

John Curran: Could you repeat that last question, that last sentence?

Jeremy Schmikel: If the majority of the network footprint is still located within the ARIN region, even if the company, let’s say the company headquarters is in another RIR, is that an issue?

John Curran: No, that happens today quite a bit actually.

Jeremy Schmikel: That’s what I thought. And my personal opinion, I don’t know that this is entirely necessary to the point -

Paul Andersen: Are you in favor or against or no opinion?

Jeremy Schmikel: Opposed at this point.

Paul Andersen: Opposed. Thank you. Next question.

Amy Potter: Amy Potter. I have a sort of hypothetical question that maybe you’ll care about, maybe you won’t. Bankruptcy estates that are selling their IP addresses via Inter-RIR transfer, if they also have ASNs, if this policy doesn’t exist, then those ASNs are left in this in between space - I don’t know if you care about that, if there’s enough that that’s not an issue, maybe it’s not necessary to have this.

Paul Andersen: So point of clarity. My understanding of the policy today, in the case that you spoke about, they would be able to transfer to other organizations within the region; and with this policy, if passed, would allow them to now be transferred to other regions with like policy, similar policies.

John Curran: Presently that can only be accomplished within the region. If you tried to transfer to a party unrelated outside the region, we would not allow it. We would say you literally cannot sell your AS.

Amy Potter: I would say in that situation you would be left with ASNs that are -

John Curran: Could you speak slowly into the mic.

Amy Potter: In that situation, if you end up selling your addresses to someone in the Asia Pacific region, and the bankruptcy estate still had several ASNs, they would sort of be wasted, just sitting out in never-neverland, because no one’s - as a broker, I’m not going to go through the trouble of finding someone to transfer just ASNs because there’s not a lot of value in that. But also you’re going to end up with these systems that don’t go anywhere. I don’t know if you care about that.

Paul Andersen: I think I understand your comment. You’re just reinforcing. I think that was one of the reasons the policy was proposed by the original proposer way back, there’s a need of consistency in the current specified transfer, covered the v4 resources but did not cover ASNs or inter RIRs.

Amy Potter: Basically. I’m just saying that there’s a scenario where you might end up with all sorts of ASNs that don’t belong to anyone.

John Curran: The circumstance that happens is that the receiving party doesn’t get the ASNs. They remain with the original registrant. That can cause all sorts of interesting issues several years later, if it turns out the original registry doesn’t care, the party that’s the recipient using them anyway, the databases don’t reflect that. So I don’t think we have a lot of demand for ASN transfers, but we said the same thing within the region and we’ve had half a dozen of them occur. So there are people who make use of these policies. Hard to tell who is when.

Amy Potter: For what it’s worth, I’ve had people approach me trying to get ASNs.

John Curran: I would take it you’re in favor of the policy as written?

Amy Potter: I’m just playing devil’s advocate. I’m not sure if it’s really necessary if there’s enough ASNs out there, if there’s not a shortage issue.

Paul Andersen: Thank you. Other questions or comments before I close the microphone and remotely online? Anyone feverishly - I’ll close the microphones after this comment.

Jeremy Schmikel: Jeremy Schmikel, Integrated Broadband. I believe inherently the ASNs don’t really hold much value; it just seems more likely they would be removed.
Most of the purchaser of v4 addresses from a different region, that’s what’s at value here, I would think, and that they already most likely have their own autonomous systems. So I’m opposed to the transfer. I think it would be more clean for them to basically return and in the case they needed one just apply for one in their own region.

Paul Andersen: Okay. So you’re not in favor so we will now - the question I would ask is again the audience participation time. And I ask those remote and in the room, I’m going to ask a question of whether or not you support moving this policy forward. This would be advice provided to the Advisory Council.

So I would ask for all those in the room who are in favor of moving the proposal forward to please raise your hand nice and high. Anyone who can hear my voice is allowed to put their hand up.

And our counters will count. I think I got it. There’s also the remote obviously. And those opposed to moving this forward. Keep them up. Are they able to put their hands down, Susan? You can put your hands down. I also see the sound - is it able to get the mics more in the front? It’s hard to hear some of the questions. Thanks. Just a moment.

On the matter of Policy 2013 1, Inter RIR ASN Transfers, regarding moving it forward: In favor, 0; against, 12. Those in the room and remote 51. Input will be provided to the ARIN Advisory Council right now for their consideration. Thank you, everyone. John.

Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy

John Curran: Okay. Going to move right ahead. And next up is Policy 2013 2, which is the 3GPP network IP resource policy that originated in March of this year.

Scott Leibrand and RS, Rob Seastrom, shepherds. Presented at ARIN 31 in Barbados and there was discussion. They would lower the utilization threshold for additional IPv4 allocations for 3GPP networks. No similar proposals or discussions at other RIRs. It was - it’s still in development by the AC, so we’ll perform when they told us it’s ready to be reviewed.

And now I will invite Scott who is coming up to this one or Scott - I’ll invite Scott up. I ask people when they come to a mic speak slowly and clearly. Somewhere out there on the end of the webcast someone is doing transcription. Think of that person when you speak. Okay.

Scott Leibrand: I will talk slowly and clearly so they can pick that up.

[Laughter]

Scott Leibrand: So I’m back. This one is a little bit less simple. The original problem statement here and the original proposal was that there is at least one mobile network operator that is having some trouble getting enough global unique addresses for their needs. So someone from that operator put together a policy proposal to help address that issue.

And this policy proposal would basically relax the 80 percent requirement in certain situations that would allow for - I’ll get into that in this next slide. So they’re using a number of non RIR assigned address blocks internally to provide addressing to handsets behind their NATs. RFC 1918 isn’t large enough for some of these large networks. RFC 6598, the/10, doesn’t help either.

So they have a number of otherwise unrouted blocks that they have been using historically. As that space is brought back into service, via returns, reclamations, transfers, et cetera, it becomes problematic to have those members also being used on the inside of a large mobile network. So they’ve been going through the effort of renumbering into global unique space. That requires some addresses at ARIN also.

There’s some technical details that the author provided about the way their network architecture works, which I have it in the appendix, can talk about it if anyone wants to.

We talked about those fairly extensively at ARIN 31. Basically what it comes down to is their failover architecture requires essentially 50 percent utilization in that one region needs to be able to pick up another region if there’s an address. So that conflicts with the 80 percent utilization requirement in the current policy.

So we did discuss this at ARIN 31 in Barbados. There were a number of folks who felt this problem was very specific to a single customer’s needs and was not more general. One of the questions that we brought to the community was is this a problem for more networks.

There were some folks that felt that this was a broader problem. Not necessarily for mobile networks that have similar architectures but more generally there are other networks that for various reasons it might be useful to apply a policy that’s more relaxed. Others felt that we needed more information to know if this is a problem.

So obviously if we do address this issue, it does fix the problem for at least one level network operator and probably other operators as well. It will allow them to reduce excessive use of NAT and address conflicts, and obviously make it easier to get IPv4 addresses. If we’re able to do so through the policy while they’re still here is going to accelerate IPv4 depletion.

It’s unclear as to whether, as to how many networks this policy proposal will apply to. It’s also unclear as to whether this is the appropriate solution or if there’s an architectural or technology fix that could be applied. And, of course, there are deck chairs.

So I wanted to highlight some of what I thought were the important discussion points that we should talk about here. One is the very obvious one. This is an important problem for us to solve. The feedback at ARIN 31 was somewhat equivocal on that, and I think what it comes down to is are we going to have a broad enough solution that it’s going to apply to other networks.

I think the number of approaches to solve it, one of which does exactly that, which would be to broaden the residential market area section of the policy manual, cover existing devices as well as what it currently covers are homes.

This is the portion of the policy manual which I recommend you pull out and read or bring up on the slide, but basically it says for residential ISPs that are serving a number of homes in the region and have to assign addresses to their equivalent, they can assign those based on the number of homes served by their infrastructure, whether or not those homes are actually currently using their IP services.

So this is classic cable policy. The approach that the author was wanting to take in this original policy proposal is to do exactly this, to cover folks who have devices, many of which are feature phones or smartphones that may not happen to be using an address at a given moment but if the devices are present on the network, they would be able to apply the same sort of 50 to 80 percent utilization ratio that the cable networks can apply.

So that would be one approach to solving this problem. There may be others. We’re still interested in feedback from folks who may have ideas. And we’re also interested in the question of whether we should move this forward or abandon it. So this is the existing NRPM text also in your Discussion Guide, and I’ll leave this on a slightly modified version of that which possibly would address this, and I’ll hand it over to Paul.

Paul Andersen: I think if I can find it, I’d ask if anybody has comments on this proposal, the first point is just a problem that the AC should spend time trying to solve. And if you have a view on the approach, that would be useful. It’s definitely one we need some discussion on. Don’t rush up at once. There’s only three mics, I know.

Jared Mauch: Jared Mauch from NTT.

Paul Andersen: You won the race, sir.

Jared Mauch: Perfect. This seems like provider having very short range vision in how to architect their network, coming to ARIN and asking them to change policy to work around their own brokenness, and I do not think this is something that we should encourage people to do; therefore, I do not support this.

Paul Andersen: You do not support it. First if I may, I’ll let Scott respond if he’d like. Thank you to the sound people. That’s so much better here on stage to hear. I thank you for that. Next speaker.

Jeremy Schmikel: Jeremy Schmikel from Integrated Broadband. I agree in a sense I believe that since this happens to be one mobile provider as mentioned: I’m sure there are more that are impacted. It concerns me that we’re looking at changing policy for everyone just to fix one person’s issue, especially when we’re already so close to the end of the line for IP version 4 as it stands today.

I think the 80 to 90 percent number, that’s probably pretty fair. I like that suggestion there. But instead in turn we should be pushing these multiple providers and people that work with the mobile networks that are having issues as we presented earlier, Android and Apple, that do not have IPv6 support yet properly at this time, it does need to be rolled out in order to not necessarily fix the problem because we all know that dual stack is the way to go and it doesn’t even fix everything. But I think it would help alleviate some of the issues.

As it stands today, due to this being such a small focus problem, I don’t think it’s necessarily a way to proceed. I’m opposed.

Paul Andersen: Next speaker.

Warren Kumari: Warren Kumari, Google. Probably with what’s a first, I actually agree with Jared.

Paul Andersen: So I take it you’re opposed?

Warren Kumari: Yes.

Paul Andersen: Let it be recorded he’s opposed.

Matt Pounsett: Matt Pounsett, Afilias. Like the first speakers, I’m opposed. I don’t see the point in doing something like this. To bring up the cable subscribers issue, that was done for a specific case where we had a segment of the industry that had no control over its own architecture.

We did that because incumbents were forcing other organizations into the incumbent architecture and they were the others we were trying to solve the problem for, just because you give me the questioning look there.

We were trying to solve a problem for people there who didn’t have control over their own architecture. These organizations do have control over their architecture. They can find a better way to solve this problem, I think.

Paul Andersen: So opposed?

Matt Pounsett: Yes.

Paul Andersen: Next speaker.

Lee Howard: Lee Howard, Time Warner Cable. It’s great having subscribed to PPML and we can come here and talk about policy, and I forgot how much fun it is.

Paul Andersen: To the point, sir, to the point.

Lee Howard: I was struggling to read the discussion in the Discussion Guide or on the slide for some specification of which version of IP we’re talking about. It seems to me there are trillions of addresses available, IP addresses available, and I can’t figure out what the problem is.

Paul Andersen: Mr. Leibrand. I think we need clarification.

Scott Leibrand: I think we intended to apply this to IPV3.

Paul Andersen: I take it you’re opposed to this policy. Is there anybody who would like to speak in favor of the policy, I’d ask you to approach a microphone now or start typing so that Bill Darte can echo your words here in the room. Kevin.

Kevin Blumberg: Kevin Blumberg. I’m going to be speaking on behalf of The Wire, which is my company. This dates back to the dial up days. To me this is a dial up problem in some respects. They would like to have one IP for their customer and one IP for that failover node for that customer as well, give them two smartphones, whatever the case may be. It’s not a well-architected concept.

And my concern is that it is going to bleed out - I don’t really care about the IPv4 run out; that’s going to happen. This is going to be an issue, we always have to look at it in the post runout as well. This is going to be a bleed in the post runout. It’s a complete inefficient use. And I’d love for more providers to have come up, and I’ve not seen those providers come up and say this is an issue.

Paul Andersen: You’re opposed?

Kevin Blumberg: Opposed.

Paul Andersen: This is a call to close the mics. If there’s somebody who would like to speak in favor, I’d urge them to come forward, come forward now. Are you approaching a mic, sir, or finding a seat? Seat. Got it. Anything on the remote? We’ll close the mics, if there are no further questions or comments.

Seeing none, we’ll close the microphones. Again, if you can raise your hand for me just for a moment and just participate in this one question. The only question I’m going to start off with is basically does this community feel this is an important problem to try and solve?

If you believe it’s a problem worth solving, I’d ask you raise your hand now. And of course participate remotely. Again I can assist the counter in that one. Got it. You can put your hand down. If you do not think this is a problem that the AC should spend time on solving I ask you raise your hand now.

Please keep it up for just a moment. And if you’re remote, please signify your vote now. You may lower your hands now. Thank you. Just a moment. The last ARIN update between everyone and coffee, between you and beer, I think I got the short end of the stick on this one. Thank you, Susan.

On the question of whether this is a matter - on 2013 2 3GPP Network IP Resource Policy, is this a matter the AC council should resolve. 0 in favor. 19 against. 51 people participating. This feedback has been provided to the Advisory Council for their consideration. Thank you, John.

John Curran: Okay. Thank you very much. I’m going to continue. Moving right along.

Draft Policy ARIN-2013-4: RIR Principles

John Curran: Draft 2013 4: RIR Principles. It originated just a couple of months ago: ARIN Proposition 187. The shepherds are Chris Grundemann, Cathy Aronson and Owen DeLong. And it was made draft policy in April. The text is online and in your Discussion Guide. It hasn’t yet been discussed. This is the first real chance to discuss it in a policy forum.

The problem statement: Guiding principles of stewardship are not currently being carried into RFC 2050bis. Background: RFC 2050, a 15-year-old foundational document of the RIR system, is being updated in the IETF. That foundational document has some goals in it, and it also has some allocation policy from 15 years ago.

In the revision of it, the goals have been revised, and the allocation policy, which is 15 years old and replaced by the RIR system, per se, means that when we look at the new document, there may be concepts that people believe should still be followed by the RIRs and, in particular, by ARIN that aren’t in the revised RFC 2050bis.

So the policy proposal takes the principles that are perceived as missing and it suggests that they go into the Number Resource Policy Manual. No similar proposals or discussions at other RIRs. Legal staff assessment is still being developed by the AC. So we haven’t done one yet. And I’m going to now turn it over to Bill Darte who will give the presentation from the AC.

Bill Darte: Thank you. Bill Darte. I’m not one of the shepherds for this policy, nor am I the author. Jason Schiller is the author of this. Chris Grundemann was planning to present today but had to leave the meeting. I’m standing in stead. The original text, as John said, RC 2050 described the registry system. The distribution of globally unique Internet addresses and rules and guidelines and principles for those distributions of number resources, that current work that John referenced has left some of those principle terms out at this stage of this development.

And so in Barbados, at our last Public Policy Meeting, there was a suggestion that perhaps there ought to be a policy that recodified or reintroduced those concepts into the Number Resource Policy Manual of ARIN. So that’s what it intends to do, to express those same principles that were codified or expressed in 2050 into the NRPM.

Specifically, it would create at this stage of the process - by the way, at this stage of the process we’re in discussion only. That’s what a Draft Policy does is help us make sure that we have a clear policy statement.

So the principles and goals of the Internet Registry, Section 0, would be included in the NRPM. Efficient utilization based on need, covering the principle of conservation that was in 2050, with a sub bullet of documented justified need; that there is needs basis for allocation and assignment of Number Resources; that there would be support for hierarchical aggregation that, again, supporting the 2050 goal of routability and uniqueness through a registration process again.

And all of this is wrapped up in a concluding statement about stewardship. This is what stewardship means. So that is what would be included new in the Number Resource Policy Manual, if this policy proposal, this Draft Policy were to mature, gain support in the community. So according to ARIN Public Policy Development Process, we’re at the point of trying to assess whether there’s community support or not for moving this specific proposal or not or something different forward, or not.

The crux of our need, as with the other presentations you’ve heard today, is to get your support or your comment whether you support introducing this language so that everything - basically the NRPM, Number Resource Policy Manual, has been founded on these principles in the past.

Everything that we do in the way of allocation policy, you know, has been predicated on these things. But if a policy like this, similar to this, if language is not introduced into the policy manual, then the authors and others in support of this so far have said then there would be no place to point. We won’t be able to point back to 2050 because it will be updated.

There would be no place to point and say that our processes and policies are all founded in these principles. So that’s the whole point of this. So any discussion that you would have upon whether these kinds of principles that were originally expressed in 2050 should be expressed in the current public Number Resource Policy Manual.

I will say that the discussion that’s been on the list - and there’s been some hot discussion on the list - a lot of that discussion has been around whether there is a needs basis anymore, whether there ever was a needs basis in the past.

I think there’s a lot of discussion that is tangential to the point of are these principles still the principles that we operate by, and should they be expressed somewhere where we can point to those foundational principles when people ask us how we run ARIN and make policy and allocate number resources.

Paul Andersen: Thank you, Bill. Thank you for standing in for Chris on short notice as well. This is, again, as Bill pointed out, this policy is earlier in the process. So the AC is just looking for feedback on how to move forward with it, that’s all. So as always, I would ask you to not, as you have previously, rush to the microphone. Just take your time.

Matt Pounsett: Did I make it first?

Paul Andersen: You did. You may go first. Remember to state your name and affiliation.

Matt Pounsett: Matt Pounsett, Afilias. I agree. I think that these are definitely the general principles we’ve operated on and they continue to be. I think it’s probably more important post runout when we’re trying to deal with transfers and things like that, when it’s that much harder to get address space it’s that much more important, the needs basis and be maintained. That’s a good idea to do this.

John Curran: Matt, can I ask a question? Because this is being predicated on the change of 2050bis, and that change is, there’s goals in 2050 and there’s goals in 2050bis. The language that’s in this policy proposal is not just the goals, what’s called principles in here, but actual allocation policy from 2050. And I guess have you looked at 2050bis to see what more since that’s what’s causing this change, have you looked at the differences between the two?

Matt Pounsett: I’ve not done that comparison of the two RFCs, no.

John Curran: That’s what I was curious about. Disclaimer, I’m one of the co-authors of the 2050bis and I’m familiar with it.

Paul Andersen: Other comments or questions? Scott.

Scott Leibrand: Scott Leibrand, ARIN AC. So having watched a lot of the discussion and read over just the goal section, not the rest of the 2050bis, I’m a little bit skeptical that what we have in this initial draft of the policy proposal is the type of thing that’s really necessary.

Let me rephrase that. The goals in the 2050bis capture most of what is captured here. I think what’s left is more a description of current allocation policy than it is a statement of high-level principles.

There probably are a couple of higher level principles that we don’t have global consensus for any longer because of the move away from complete needs based policy in the face of IPv4 runout that might still be relevant for another year or so in the ARIN region.

But I’m not sure that those are the things that we want to codify in a way that this policy proposal seeks to do. So I am approaching this skeptically. I think the general approach of this may have some merit. But as evidenced by the heated discussions on PPML, and other things, I’m not sure we’re there yet.

So I would encourage everyone to go back and reread all of the relevant documents and start thinking about ways that we can actually do what I would call a gap analysis and find what’s actually left that still needs to be described and have a discussion about what, whether there’s actually consensus on those gaps, because I see a lot of the areas that are not described in 2050 being the contentious ones.

And I’m not sure we have a community consensus on what those should be. So I’ll be interested to see how that plays out. And I’m looking forward to a lot of editing and discussion on this one. I don’t think it’s ready yet.

Paul Andersen: Skeptically supportive of the direction.

Scott Leibrand: I’m skeptical of the current text. We’ll see where it goes from there.

Paul Andersen: Other comments that would be useful for the AC? Again, on this one I would think we’ll probably just pass on the global comments and not - since it’s new. Seeing none in the room, I’ll just check with Mr. Darte. Closing the mics. Three, two, one. Closed. Thank you very much. We’ll provide that input to the AC.

John Curran: Thank you. Okay. Thank you everyone.

[Applause]

DRAFT POLICY 2013 5, LIR/ISP AND END USER DEFINITIONS

John Curran: And coming up on Draft Policy 2013 5, LIR/ISP and End User Definitions. So back in May this was submitted. AC shepherd Kevin Blumberg, Owen DeLong and John Springer, Draft Policy of the AC, meaning it was understood what it was trying to solve. The text is online and in your Discussion Guide.

It updates the definition of LIR/ISP and end-user. There’s no similar proposals or discussions in the other regions. It is still under development. So we haven’t done a staff legal assessment on it. And I’ll turn it over to Kevin, I presume, to do the AC presentation.

Kevin Blumberg: So here are the current definitions of what an LIR is or an ISP, an IR that primarily assigns address space to users of the network services it provides. LIRs are generally Internet service providers. And end‑users: An end‑user is an organization receiving assignments of IP address spaces specifically for use in its operational networks.

Now, the Draft Policy is trying to help define what an Internet service provider is. And this is what I wanted to talk about. ISP - the word ISP, the word LIR meaning changed over the last 15 years.

And so the question is does this change - what we have here actually change anything or does it just make a couple of words look nicer and not solve what the original issue was.

So I’m going to go over that. In Barbados, which was actually cooler than it is in New Orleans right now, we had a staff report that was done that brought up this issue. There is no term ISP in NRPM. Newer technologies don’t necessarily fit into the word ISP.

It’s kind of hard to define what an end-user is or who an ISP is. And what really the crux of it is is we have policy shopping. So what’s gone on is, over the last three to four years, an end-user is still at 12 months. An end-user has a /24 for multi homing requirements. They have a much simpler time because, quite frankly, end-users are smaller. There are less of them; they don’t come back very often. They have simpler needs. They don’t have to assign to their customers as an example.

And what has happened in the inverse is that ISPs, in the ISP definition, have gone from 12 months to three months. And we’re going into this runout, things are getting more difficult.

And so by having a very vague definition, which has worked for many years, it allows people to say, no, I’m an end-user. You’re giving it to your customers to use.
But based on the definition, I’m an end-user. And what we’re looking for or what I believe the author is looking for in this policy is to help clarify so that there is less ambiguity for staff and for the community as to what is an end-user and what is an ISP.

Now, we could do it one of two ways: We could try to define what an ISP is. And having spent enough time at NANOG, I would be very interested if we had 50 opinions by 20 people on what an ISP is.

But the question is for the community, as I see it, what is an end-user? Can we define end-user and leave the rest for the category, would that be acceptable? That’s one question I’ll pose to the group.

The other question is: If we do this, we’re going to be making some subtle changes to what people have expected for many years. A Web hosting company potentially that might have been fine in the end-user policy might not any more. They might have to be in the ISP and vice versa.

So the bar will move, will shift, and what might have been one way will now be a little different. And this will be both in, again, our current scenario and down the road that will have an effect on the transfer markets, et cetera.

So I guess I’m going to open this up to the floor because really what we’re looking for at this stage is as much feedback as we can get what the use of and what the community wants in this area is.

Paul Andersen: Thank you, Kevin. I think it’s worth pointing out this definition not only affects the policy under which an organization would be, but it also affects fees. We do charge different fees at ARIN whether you’re an end-user or lower ISP. So we posed some questions here. Ask again if you could rapidly approach the microphone since this is our last proposal. So we might be able to wrap it up a little bit early.

Jeff Hankel: Jeff Hankel, Louisiana State University. I fall into the category of I don’t know what I am. I’m a university. I assign IP addresses. I have a lot of users. But in your eyes am I an ISP? Or am I an end-user? You ask me, it’s vague.

Paul Andersen: Hold on a sec.

John Curran: You’re an end-user right now. If you ask me, we would say that your registration as an end-user; you pay lower fees than an ISP, by the way, for very, very similar services. It is also true that there are some criteria that are different, end-users and ISPs, for obtaining initial and new allocations.

As we get towards the runout of IPv4 in the pool, people will self select which criteria is most favorable. And that’s fine as long as the community expects that to be happening. It’s also true that someone who can’t get additional space could be asserting to ARIN my business model has changed.

By pure coincidence you happen to be running out of address space, but my business model happens to change and now I’m no longer an ISP, so can I have some more numbers. And so we have the question of someone claiming: Do we worry about that, or do they self declare which they are. Got it?

Paul Andersen: Does that clarify it?

Jeff Hankel: A bit more.

Paul Andersen: Any feedback on the questions that are posed?

Jeff Hankel: Actually I do think this would be worth clearing up to see what you are especially at Louisiana University.

Paul Andersen: Thank you.

Jeremy Schmikel: Jeremy Schmikel, Independent Broadband. In my industry, we actually work with a couple hundred tier two and three cable MSOs throughout the ARIN footprint. And the way that the policy is written, as I read it currently, is basically defining an end-user as someone who - let’s say, I’m assuming that you’re meaning in SWIPing certain amounts of address space to subscribers behind the network, is that correct, as I understand it?

John Curran: You’re saying current definition of ISP?

Jeremy Schmikel: Not current, the proposed.

Paul Andersen: The proposed.

Jeff Hankel: Yes, that’s a pretty good summary.

Jeremy Schmikel: I was making sure. So let’s say I’m a cable ISP and I get an allocation from ARIN and all of my address space is simply DHCP to cable customers behind me, I don’t have to SWIP any address space, would I then be an end-user?

Paul Andersen: John, how would you interpret that?

John Curran: Under the proposed policy, if all you did was provide Internet services and the end-user organization receiving assignments for that network and does not register any reassignments. So if you do not register any reassignments, then you’re an end-user.

Jeremy Schmikel: I was wanting clarification on that. Thank you.

John Curran: Right.

Paul Andersen: I think actually - did you have a question or -

Jared Mauch: Jared Mauch, NTT. The one thing that I noticed is that in this booklet that I was handed -

Paul Andersen: Thanks to the staff who put that together. They did a lot of work.

Jared Mauch: In Section 2, you have a definition section, do you intend to define what ISP is as an acronym throughout as you do similar acronyms, because -

Paul Andersen: The bootstrap problem, right?

Jared Mauch: Yes.

Paul Andersen: I think that is a good take away for the AC to decide if they need to clarify. Good point.

Jared Mauch: I’ll skip, if I can address that. The acronym ISP expands to Internet Service Providers, that’s in the text of the new 2.4.

Paul Andersen: That is, 2.4.

Jared Mauch: I understand that. But I think the question is defining the end-user sites, university who is not quite sure, are they an ISP because they may have departments or other people that may sub assign things to, and whatnot.

Would it be valuable to put that there? And it begs a question I don’t feel needs to be answered, but it’s just a question of whether or not it makes sense to enumerate that further to provide clarity so people don’t try to drive trucks through holes.

John Curran: I’m going to ask a question to make sure I understand. The proposed text functionally defines the difference between an ISP and an end-user. You’re suggesting enumerating certain types of organizations are one versus the other? You’re suggesting an ISP includes a university; universities are ISPs? And community colleges are ISPs?

Jared Mauch: I’m suggesting that through the community feedback process, it may be valuable if you further document that.

John Curran: And I’m saying is that someone would need to suggest text as to what organizations end up in that enumeration.

Jared Mauch: Sure.

John Curran: Thank you.

Paul Andersen: Over to Kevin Blumberg first.

Kevin Blumberg: Just a quick question. Sorry you sat down. Is it easier to define ISP, or is it easier to define end-user? Because my concern is that ISP is a very long term moving target now that we’ve seen some - I guess my question for you is an end-user an easier term to define than ISP or six of one half of another.

Paul Andersen: Kevin, the next mic.

Matt Pounsett: Matt Pounsett, Afilias. I think that if an organization that provides Internet access is not defined as an ISP under this text, then this text is broken.

Paul Andersen: In other words, the interpretation that John gave earlier you feel suggests that the text is broken?

Matt Pounsett: Yes.

Scott Leibrand: I would agree with you, I did not intend for MSOs to be classified as end-users. By the way, Scott Leibrand, ARIN AC, author of this text.

Paul Andersen: In full disclosure.

Scott Leibrand: So my - first off, as mentioned in the policy text rationale, whatever it is, my organization is neither an ISP nor an end-user by strict reading of the current text. Because we are not primarily providing Internet access, and we’re not exclusively doing it to our own equipment, some of both being. It think it’s important to clear up that I’m either thing.

I think it’s important to tighten up these definitions a little bit. I do not think it is important to lock down every single possible edge case as either one or the other. While ARIN staff likes to have things cut and dried in policy so they can do their job more easily, I am inclined to put more work on them when it benefits the community.

And I think having policies that is a little bit flexible in this situation might be good. Now, in the well known enumerable cases like universities, MSOs, I think the text should go ahead and be clear enough to make it unambiguous what those are.
But for some new cloud type service that is sort of like an ISP and sort of like an end-user, I’m not personally opposed to having them be able to choose which policy applies to them.

And if the policies are so different that everyone’s always making the wrong choice by some definition, then perhaps we need to look at that distinction and tighten that up.

But that’s kind of where I was thinking as when I wrote this text, I think it does need to be tightened up a little bit. But I would like to hear feedback from the community as to whether you think we need to explicitly define everything or whether it’s okay to leave some ambiguity in here. I think I’ve heard a lot of, yeah, we should work on this.

Paul Andersen: I think while it’s valid to hear the community, I think as was pointed out earlier in the presentation, I think the proposal came out of a staff report that’s given at each one of our regular ARIN meetings that staff have had struggled with this.

So I think staff are struggling, I think it behooves us to discuss it, that means they’re having problems doing it, and their job is to execute their policy that the community passes. I believe the far mic was - John, do you have something to add? My apologies.

John Curran: So actually we can do whatever the community wants. And so if you want loose definitions, those are great. And those work fine. If you have two very clear definitions that says the world was made up of A and B, but you’ve defined A and B very tightly, you may find out there’s a lot of Cs that don’t qualify for A or B.

So you need to decide the philosophy here. Okay? If it’s that they can choose, then it’s pretty easy to have some light definitions of either. We don’t really care. They can choose.

If it’s that you want a hard line to either of the call side as an end-user or to be call side as an ISP, that also works, as long as there’s only one hard line that we’re enforcing.

If we try to enforce two hard lines, we actually end up with organizations that are A or B or I don’t meet either. And that’s the problem you face. So the philosophy of what the community wants is very important, before you decide which definition structure you want to have.

Paul Andersen: Far mic.

Jeremy Schmikel: Had a quick comment. Jeremy Schmikel from Integrated Broadband. I didn’t mean to necessarily introduce that loophole, just due to the work that I do, I work on behalf of several MSOs. It springs to mind. I want to make sure we have a clear definition, to a certain extent, because we don’t need to introduce all the Cs. I think it’s a valuable discussion and we should work together as a community to help come to those definitions. Thank you.

Paul Andersen: Center mic.

Matt Pounsett: Matt Pounsett again. I kind of feel like doing it by defining the end-user might actually not be the easiest way to do it. Because the thing I think we’re concerned about is the workload on staff and the resource usage of ISPs. They’re the larger resource string, right, for both workload and for Number Resources.

So I think it’s ISPs that we are concerned with. And I think so it’s probably easier. And so I think that any organization that shows some ISP behavior, even if it’s not all of what they do, should be an ISP. So I think it’s probably easier to define that than to say people who do this are end-users and everyone else is an ISP.

Kevin Blumberg: Matt, I’m actually really impressed with that little snippet. I’ll have to use that. ISP behavior rather than a specific definition. I think, for me really embodies what this is about.

Paul Andersen: We’d be able to take “that” but we don’t know you are the “this” as well.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. We can probably get it down to the smallest of things. People that provide Internet access to other organizations or to individuals, and the people who SWIP resources.

I think just even those two things probably cover 99 percent of them. There might be one or two other simple things we need to throw in there. Haven’t thought about it for very long. But I think that might be an easier approach, just to say that here are things that are ISP behaviors. Anyone who does these things is an ISP. Everybody else is an end-user.

Paul Andersen: Thank you. And I’ll check with the remote participation.
Anyone? I’m going to be closing the mics soon so that you’re not thrown off, there won’t be a poll question as we’ve had previously. So if you want input, even to say, get your two cents in, please approach the microphone now. Closing microphones. Once, twice. Three. Closed. Last question, you can comment sir.

Jeremy Schmikel: Jeremy Schmikel from Integrated Broadband. My hesitation comment is while it’s true you want to be flexible, confusion and frustration don’t lead to flexibility. I guess what I would envision is an applicant having to choose with the knowledge of interpretation and then your staff, business back and forth, it’s like who is interpreting what.

So I guess my question would be to you especially directed at like staff interpretation, is I’m guessing that they probably want some examples maybe. Maybe to Jared’s point, maybe there’s some kind of separate document that just gives examples and that’s not tied into the bylaws or whatever form of documentation we’re solidifying here so you have flexibility to adopt that over time.

Paul Andersen: Thank you, John.

John Curran: I think that’s a very good suggestion regarding having examples. When we get to the end of this and know what the rules are, it’s nice to have examples so someone can say I’m one of those and that’s easier. I’m going to raise an aspect, and this might reopen the topic, it might encourage people to come to the microphones. Recognizing the ARIN fee schedule for ISPs is there’s significant recurring annual fees for your number resources.

And the fee schedule for end-users is a small maintenance fee each year. And this has been the practice since ARIN was founded, since inception. So this means that parties - if two parties, both have six /16s, one is an end-user and one is an ISP, the ISP is saying several thousand dollars per year or $8,000 per year and the end-user is paying a maintenance fee of $100 per year.

Generally, if people have a choice of paying several thousand per year or $100 per year, as much as they’re altruistic, they choose to pay the lesser amount.
And so this means that we need to be careful because if people can self select, we could find ourselves having to face financial consequences of everyone saying I’m actually getting the same services and I’m just going to pay a lot less money.

So people who feel that the answer to this is normalized, the services, normalize the fees, people who think the answer to this is differentiate the services, please come to the mic. That would be a helpful aspect of this when we talk about ISP versus end-user self selection.

Paul Andersen: Someone has approached the mic.

Jared Mauch: Jared Mauch, NTT. I’m probably an ISP. And hopefully we pay our fees. Is this that big of a problem; or if the fees are aligned is that going to present a significant budgetary challenge for ARIN?

Paul Andersen: When you say aligned -

Jared Mauch: If the fees converge such that everyone is paying relatively the same amount -

Paul Andersen: Depends which way they converge.

John Curran: A lot of end-users would become very upset and would look to the person who submitted that suggestion and hunt them down.

Jared Mauch: Yes. But if it were to go the other way -

John Curran: It can’t, I mean end-user’s paying $100 per resource record per year. So anything -

Jared Mauch: I have no idea how the ARIN budget and stuff works. Perhaps that’s through my own ignorance and because I don’t pay a lot of attention to the process. If the ISPs stop paying their fees or start paying the end-user fee, how will that impact ARIN?

John Curran: 80 percent of ARIN’s revenues are ISP fees. So if the ISP fees came down to meet the end-user fees, it would get interesting.

Jared Mauch: Okay.

Paul Andersen: I think as treasurer I would have to say that would put us in a serious position, yes.

Jared Mauch: Okay.

Paul Andersen: Other people that would like to approach on this topic? Center microphone.

Aaron Hughes: Aaron Hughes speaking for myself. I’m sitting here thinking about the future of enterprises and end-users, subsequent allocations, v6 reports, reporting requirements. And that it will probably evolve over time end-users will probably require more resources from ARIN and maybe should pay more fees or maybe not.

And that reporting might require things like SWIPing - enterprises and end-users might start looking more like ISPs. So we should - I would suggest we are careful about language and what looks like an ISP means as we as a community have absolutely no idea what an enterprise is going to look like over the next five, 10, 15, 20 years.

Paul Andersen: Thank you. That’s a good comment. I will close the mic on this topic. We have ten minutes left in this section. Going once, twice, remote participation check. Nope. Sold. Thank you very much for your involvement. I’ll turn it over to John to finish up.

John Curran: Thank you.

[Applause]

Closing Announcements and Adjournment

John Curran: I’d like to thank everyone for participating in this session. I remind people we’ll be talking about these same things at the next ARIN meeting which is a joint ARIN/NANOG meeting, and that’s coming up in October.

In the meantime, if you have views on these policy proposals, they’re all online. There’s actually a mailing list that gets a couple of messages each day, called the Public Policy Mailing List. Welcome to join it.

There’s an active discussion of these and your views are more than welcome. If you have any comments particular to these, your Advisory Council, your elected ARIN Advisory Council, the folks from the community, are the ones you should seek out and you can express your views or help, help them explain aspects of this that may not have been covered. Thank you all for coming and enjoy the rest of your evening.

[Applause]

[Meeting adjourned at 6:07 p.m.]