ARIN PPC at NANOG 60 Transcript - 11 February 2014 [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

[No transcript available for this segment, please see webcast archive]

Update on Advisory Council Activities

[No transcript available for this segment, please see webcast archive]

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

John Curran: Okay. We’ll start right in. And the first one up is ‑‑ I actually have a brief introduction. Okay. First one up is 2013‑8. And it’s Subsequent Allocations for New Multiple Discrete Networks. And this is a Recommended Draft Policy, could be sent to the Board of Trustees by the AC after a Public Policy consultation such as this.

So the history: It started out in October of 2013 as ARIN Proposal 191. The shepherds were Cathy Aronson, Owen DeLong and Rob Seastrom. The AC accepted it as Draft Policy in November of 2013. The AC recommended adoption in January of 2014.

The Draft Policy text is in your guide and online. Staff summary: It adds definitive criteria to the existing policy NRPM 4.5, Multiple Discrete Networks Policy, and 6.11, IPv6 Multiple Discrete Network Policy, to assist staff and the community in determining allocation size for new sites of an existing MDN customer.

This subject was raised by staff in the Policy Experience Report at ARIN 32. It adds some missing criteria and is consistent with the current practice. The criteria is: Must provide evidence of connectivity at the new site. Clearly states that new sites will receive ARIN’s minimum published allocation size; and if this is not sufficient, must qualify under the immediate need. And add the IPv6 MDN policy that includes both initial and subsequent allocation criteria.

Resource impacts: Minimal. Take about three months to implement. Does not appear to create any legal issues.

So now the AC presentation. Come on up, Scott.

Scott Leibrand: So this one is pretty simple and straightforward. The Multiple Discrete Network Policy has been around for a good long time. It’s been through some revisions.

After some recent revisions, staff noticed that there weren’t any good criteria in the policy for telling people when they can get new space under Multiple Discrete Networks Policy.

So the ARIN staff, being the good stewards that they are, went ahead and used the authority they had under immediate need to do the right thing and then they came to us, the community, and the AC and said, hey, looks like there’s something missing here.

So this Recommended Draft Policy adds or re‑adds text to the NRPM to indicate what the requirements are for getting additional space under multiple discrete networks.

That text is here in red. It is pretty similar to text that was in the policy before some earlier revisions. And I think you guys can all read more effectively than I can talk fast, even though I can talk pretty fast. Maybe I’ll slow down now.

And that text is also in your Discussion Guide which you probably have a paper copy of. So the older versions as I mentioned did have that text already in it. Here’s an example of the text that was present in 2004. I see people reading, so I’m waiting.

And this is actually relevant because there have been 23 unique organizations that were approved for space under MDN between those two meetings.

So the question is: Do you think we did this right? Is this the appropriate text for setting the policy for getting new space under the Multiple Discrete Networks Policy? Is there any suggestions you would make as far as improving the text or any other comments?

I’ll go back to that and open it up for discussion.

Paul Andersen: Ask you to approach the mic. First the question: Obtaining connectivity, is that defined somewhere?

John Sweeting: In the same section that defines ISP and Internet.

Paul Andersen: Got it. First mic.

(Laughter)

Paul Andersen: Just filling my head as I was reviewing it, that’s an interesting question.

Lee Howard: Lee Howard. I have noticed that somebody always has to go first in order to get people to come to the mic and make comments. So therefore I’ll say: It looks good.

Paul Andersen: I’ll take it that you’re supportive of the policy. Those that would like to comment on the merits or nonmerits of the policy.

Comments or questions about the policy? Demerits? Hurry, the snow’s coming.

Martin Hannigan: So define new connectivity. So this seems a little chicken before the egg, especially with exhaustion. So I get my connectivity, then I ask for the addresses? Or I ask for the addresses and then I get my connectivity? And if I get the connectivity and I sign an agreement for N number of months I can’t get the addresses, do I send the bill to ARIN?

John Curran: I can answer that last part. No. But ‑‑

(Laughter)

John Curran: So this states that the connectivity has to be in place for you to be allocated the minimum allocation size. I do not know the chicken‑and‑egg aspect of this.

Presumably you saved one last block to connect up so that you can apply to the address space that you’ll have for the next one. But this does seem to imply that you’re getting address space that you somehow don’t need because you’ve borrowed it from somewhere else.

Martin Hannigan: I’m not sure what business you’re in, but that’s not the way that mine works. Typically, when I need to deploy, for example, a new SSL system, I have to plop down a large stack of equipment, match exactly the same amount of IP addresses across the board.

And if I put that stack in place and then go and ask for address space and I don’t get it, I basically have a drone sitting there doing nothing. That’s basically useless.

Scott Leibrand: So from previous policy experience and the text that I remember applying under when I was getting the space from ARIN directly, the other approach to this is to have some sort of contract for connectivity that you can demonstrate to ARIN.

If we change the policy to require that you demonstrate that, would that address your concern here?

Paul Andersen: I was going to jump and say what does the text for multi‑homing say because I believe that’s how we handled it.

John Sweeting: So I think the actual policy is that once you have the connectivity, you’re guaranteed the minimum allocation size. But you will get ‑‑ you can get more if you can justify more, but you will get the minimum allocation size for that discrete network.

Martin Hannigan: That’s not my experience, actually. I’m a user of the MDN policy.

John Sweeting: The new network shall be allocated.

Martin Hannigan: After a needs assessment?

John Sweeting: No, the proof of ‑‑ I’ll let Leslie answer that.

John Curran: So it does say that verification that you’ve already obtained connectivity at its new discrete network site is present.

As this is written, okay, you will, if you have connectivity, you will receive the network allocation. But I agree with your constraint that says somehow you’ve arranged for that connectivity and you have it before you actually have the IP addresses in hand.

So while I think it’s a low risk, it’s a risk and it’s also, to some extent, I don’t know how you can have connectivity using addresses that you don’t yet have.

So I consider it a valid concern that people could come to us with the text of the policy as written.

Martin Hannigan: So I think ‑‑ wow, that’s loud. I think we’re on the right track with respect to the ‑‑ that’s really loud. So I think we’re on the right track with respect to the issue with the agreement but contractual kind of problem here, and I think that the rest of this proposal is fine.

That particular language, to me, and as a very big user of the MDN policy, is completely broken.

Paul Andersen: Thanks for that feedback.

Sean Kennedy: Sean Kennedy, XO. As far as what Martin brought up, I mean, this wouldn’t work necessarily for ARIN; but as a provider, we’ll tell our customers we’ll review justification forms in advance of placing an order and give them some kind of idea that, yes, we would approve that type of justification.

They can place their order and assume that they can get some IP address space, and obviously we’ll want to make sure they’re actually putting in racks and servers and subnets and actually give us a subnetting plan.

So, I mean, maybe the best thing is provide address space. And I have concerns about the minimum allocation, because if we’ve got a customer that buys connectivity, we give them a /20 and they haven’t used that to 80 percent, we will make them use a /24 from that allocation, which they can use the multi‑home to another provider if they want, and I don’t see why ARIN wouldn’t do the same.

So we should definitely be validating that they don’t have, that they have utilized the space that they have and that they can’t multi‑home with what’s less.

Paul Andersen: You’re not in favor of the ‑‑

Sean Kennedy: I think it could use a little more work. Based on the comments here, I’m not against the procedure. It doesn’t directly affect ISPs. We’d actually love it if more of our customers went directly to ARIN. But they don’t want to pay the maintenance fees and membership fees.

Paul Andersen: So in principle, the problem but technically ‑‑

Mike Joseph: Mike Joseph, Google. Two questions, first for staff. Is it staff’s interpretation that this change to the NRPM only increases the criteria by which an organization could obtain addresses? In other words, does this represent a more permissive change to policy?

John Curran: This clarifies the existing text. It conforms with ‑‑ it conforms with our experience. I don’t think it’s more permissive. I think it is a clarification to give us guidelines that we’ve been doing heuristically before.

Mike Joseph: Let me ask you more directly: Is there any previous request that would have been approved under current practices but would not be approved should this policy be adopted?

John Curran: Not to my knowledge. Leslie indicates no.

Paul Andersen: Leslie is shaking her head.

Mike Joseph: The second question to the AC, would it be reasonable to replace the “has already obtained connectivity” phrase with “connectivity is imminent”?

Scott Leibrand: Apparently it’s way quieter than all the mics in the room. Is that working?

That text would work, I believe. I believe there’s also text elsewhere in the NRPM that deals with the same issue. So I’m going to be going back and looking at those and seeing if there’s existing text we can already use.

But imminent, under contract, something along those lines is my current thought on the best way to address that, yes.

Mike Joseph: Thank you. In general, I support the policy in its concept.

Paul Andersen: Thank you for saying that before I asked.

Martin Hannigan: Good suggestion. But I’ve never had an imminent agreement for network connectivity.

Paul Andersen: Imminent snowstorm.

Martin Hannigan: Imminent snowstorm ‑‑ I’m not aware of such a thing.

Paul Andersen: Other comments or questions or clarifications that need to be said?

Unidentified Speaker: [Indiscernible] Limelight. Just responding to a couple of comments here. The central rub seems to be the trying to resolve the conflict between the obtaining resources and obtaining physical space.

Could this not simply be resolved by putting in language there such as demonstrating intent being satisfied with a quote for price from a vendor not necessarily a contract but a dated current quotation?

John Curran: That actually reflects the current practice when it comes to multi‑homing and AS requests and similar.

So we know how to handle it. This is just very specific, noting that connectivity has to already be obtained. We need something a little looser that says “has shown intent.” I think there’s language elsewhere that might be applicable if the AC looks for it.

Chris Grundemann: Chris Grundemann. I think I understand the risk, but I’m not a lawyer. Seems you can write a contract for connectivity that’s contingent upon receiving addresses and then if you don’t get connectivity you don’t pay anybody. It doesn’t seem like an insurmountable problem.

John Curran: As I understand it, if you’re looking for this to bring a new hub site on, it’s not just getting the connectivity, it’s getting the equipment, doing the arrangements, the space, the colocation, the cross‑connects.

There seems to be a lot of pieces when you set up a POP. So I think what we need to show is we need to show there’s arrangements and it’s in process as opposed to connectivity is in place.

Chris Grundemann: To me, signing the contract with connectivity seems much easier than buying all the gear and loading up a whole site. Right? I don’t know.

Martin Hannigan: As the operator of a multi‑terabit contract you can’t write a contract on receiving or not receiving addresses.

John Curran: So the particular language here says “has obtained connectivity.” And that’s unfortunate, because that literally says the connectivity is in place. It’s not even signed a contract.

And so I just believe this might be overly specific compared to what we use, for example, for multi‑homing and AS acquisition.

Martin Hannigan: How about just “planned.”

Paul Andersen: I was going to take ‑‑ hold on. You need a mic.

John Sweeting: I just want to point out that this is for people that are already established customers of ARIN. They already have address space and everything and they’re now coming back saying we have plans ‑‑ I think plans would actually work very well to say we have a plan new site and we need addresses for this discrete site. It’s not like it’s somebody new trying to come and get addresses for the first place. It’s for existing customers that have a relationship already.

Paul Andersen: John, do you think the AC was intending this be more restrictive than current practices such as multi‑homing or maybe just wording clarification?

John Sweeting: I would defer to the shepherds but they’re not here. But from my point of view it’s that we got overly restrictive.

Paul Andersen: Okay.

Martin Hannigan: Just to quickly address the point with respect to moving addresses around to satisfy the need to turn up with like buying circuits that I may or may not be able to use later because I can’t get the addresses, if you look at ‑‑ so if you look at some networks’ use of the MDN policy, you’ll see ‑‑ you may find that utilization, at least in some cases, is extremely high. And there’s not the ability to move any addresses around.

So, for example, I may submit an application for new addresses under MDN and demonstrate I have north of 95 to 98 percent utilization. I don’t have additional addresses to move around to loan to a site while I’m waiting for an approval so I can take them back and put them somewhere else. We’re exhausting. We just don’t have that kind of address space in the interim.

Paul Andersen: So you’re supportive of the policy ‑‑ you’re concerned about this text being too restrictive?

Martin Hannigan: I don’t think ‑‑ again, we’re exhausting, we’re moving the deck chairs again. I think for the week that I have left to apply into this policy, sure, it’s going to work. But if going forward we may need it, maybe you’ll find a /8 under John’s desk, I don’t know. We should have something that actually works.

Stacy Hughes: That’s where it is?

John Sweeting: And I believe, if I remember correctly, that Leslie pointed out in one of the experience reports there was a hole in the policy that people could get multi‑discrete networks but then if they came back with a new site, there was nothing that covered them being able to get more address space for that new discrete network. So this was to fill that hole, and I believe we got a little bit too restrictive.

Paul Andersen: So we’d like to close the mics soon and also that includes remote participation, which I don’t believe we have any yet. But if you’re remote and you would like to comment on this, please start typing madly.

If you would like to speak in the room, please approach the mic. Otherwise, we’ll move off this.

Sean Kennedy: Sean Kennedy again. Just very quickly, obviously Marty shows use if he’s got 95 percent. I think there should be something to show that they do need that space; they can’t shift a /24 or something without making the policy too complicated for the ARIN staff, but a network that’s got a relationship with ARIN that’s allocated their assignments can go back and request new space.

So let’s make this something not that they’ve allocated the space but not used it for five sites and now they’ve got a sixth site, but they really for some technical reason need a minimum allocation or other block for a new location.

John Sweeting: That’s what the multi‑discrete network is for, Sean, even though they haven’t achieved the actual usage at other discrete sites, that ARIN would force them to move address space, that they would actually get a minimum for that new discrete site.

Sean Kennedy: But they have to show that they’re going to put equipment in that’s larger than a /24.

Scott Leibrand: Go ahead and reread 4.5.4. There’s actually quite a bit in there about the requirements for what you have to have done as far as using their existing space that are different for multiple discrete networks than they are for a standard network where it’s easy to route things around inside your network.

I think that part of it using the existing stuff is actually well taken care of in the policy. All we’re dealing with here is the text around the specific new site. And I think Marty’s concern is a valid one. The AC never considered that particular portion as to whether it was too restrictive or not. So we’ll go back and probably modify the author’s text along the lines we’ve discussed here.

But I think ‑‑ I believe all the concerns that I’ve heard you expressed here with the existing check or with that change if you think otherwise I’d like to hear it.

Paul Andersen: This is Recommended Draft Policy. It did have the opportunity potentially to go to last call, but I’ve conferred with the AC chair and I think he’d like to take the feedback and potentially work on it. So before I close the mics, we won’t be taking any votes per se or show of support. So just one last call, if you did want to comment, say good idea, bad idea, please jump up now.

Parliamentarian.

John Curran: Under the current policy process, if you make a substantial change, it’s no longer a Recommended Draft Policy, and it would have to ‑‑ be re-recommended and go to another Public Policy consultation.

So the question really is there’s no reason to do a show of hands unless you intend to make a really minor change and send it to the Board. If you expect us to send it to the community in April anyway before you send it to the Board, you don’t need a show of hands for anything.

Is the shepherd going to try to send this to the Board based on this small room doing a show of hands on text they can’t see. Because I’m on the Board and I’ll just tell you what I think of that, but maybe you can infer it.

Paul Andersen: So I think unless there’s further comment, we will end this item and thank you, Scott, and thank you all for your participation. That feedback will be taken back to the AC.

John Curran: Very good. Still very good. Okay.

Draft Policy ARIN-2013-7: NRPM 4 (IPv4) Policy Cleanup

John Curran: So we’re going to move ahead to our next policy proposal and that is Draft Policy 2013‑7, NRPM IPv4 Policy Cleanup.

There we go. Okay. 2013‑7 originated as ARIN Policy Proposal 190 in July of 2013. The AC shepherds Scott Leibrand and Kevin Blumberg and John Springer. AC accepted it as Draft Policy in August 2013 presented at NANOG 59 and ARIN 32. Remained on AC’s docket and revised and the text is available on line and in your Discussion Guides. It’s a work in progress.

The AC needs your feedback. Is it good number policy? Is it fair and impartial? Is it technically sound? Is it supported by the community? Should the AC continue to work on it or get rid of it?

Scott Leibrand: If you thought you were done with me, I’m sorry. So the history as we’ve already mentioned was that this was a much more substantial change to the NRPM changing a number of things that did not have consensus at previous meetings.

So this has been updated. It is a new problem statement, which specifically focuses on the changes to NRPM version four that are really irrelevant now and should be cleaned up for clarity.

The intent here is that these are the uncontroversial changes that really should have been made to the NRPM long ago but simply by virtue of inertia have not yet. So we’re addressing those.

The summary of what we’re doing here is removing some sections 4.1.1, 4.1.7, 4.1.9, 4.2.4 and 4.2.5, and we’re updating or replacing a few other sections with simpler text or otherwise making some minor changes that I’ll show you shortly.

So I’m going to go through all the changes, why we did them, if they’re a replacement, what we actually did; and then I have a red line of the ones we actually changed in the section, a red line for that.

For section 4.1.1 this is a section of the NRPM that tells people how to route their space. We believe that that is no longer necessary. It tells organizations where to get space, when to go to their upstream, when to go to ARIN, et cetera, et cetera.

Given exhaustion and other current realities, we don’t believe it’s necessary for NRPM to tell people when to go to ARIN and when not. That’s going to be stricken.

We also have a section 4.1.5 that is currently titled: Determination of IP address allocation size. And it indicates that that’s the responsibility of ARIN. That doesn’t quite match the reality of what is done.

So this proposal clarifies that we are more focused on the amount of requests ‑‑ resources requested.

So it’s not ARIN’s sole discretion to indicate what is required for a given site, but it is ARIN’s requirement to determine the validity of the request. So this text should not change anything operationally.

It should just make it more clear in the NRPM what’s really going on, which is people request the size of block that they believe is justified given their requirements and ARIN checks and validates that.

There’s a section 4.1.7 that references RFC2050. As most people know that’s been replaced with RFC7020.

And there’s been a separate policy proposal recently adopted, has RIR principles; and given both of those actions, section 4.1.7 is no longer necessary.

Another oddity of the current NRPM is 4.2.3 and 4.2.4 have a distinction as to whether you’ve been an ARIN subscriber member for more than a year or not.

We believe that that is becoming anachronistic and specifically superseded by policy 10.4.2.2, the last /8, and now it’s down to a free one for everyone while you’re getting the transfer.

So this particular section of the NRPM really no longer applies.

Section 4.2.5, web hosting policy, says that ARIN should gather information on why you really need an IP address for each of your web hosts and keep that information for possible development change. It doesn’t actually indicate that ARIN should do anything to accept or deny those requests, just gather information.

This has not resulted in any policy changes in the decade or so since it’s been implemented. So it’s really no longer needed.

That particular aspect actually overlaps with another policy proposal that’s been submitted by another author. So the idea here is that if that’s even the least bit controversial, you can consider it separately.

If something else in this policy proposal is controversial and this clean‑out might not go forward, you can consider that one separately.

If they’re all nice and we have consensus for all of them, then you can pass all of them and move forward.

So questions for the community are: Do you agree that everything we’re talking about here is minor cleanup? If not, do you have suggestions for how we can improve this to accomplish the cleanup that is necessary and not try to do anything controversial?

And that would also indicate that if you think something is controversial we can simply strike it from the proposal and do the other things.

Obviously, any significant fraction of the community agrees that something maybe is not a good, then that’s certainly the definition of not agree. So I’ll leave it to Paul to have the discussion.

Paul Andersen: Okay. Omnibus ones are always difficult ones to end discussion, but we want to see if there’s any item that people want to speak up and, as Scott said, that’s controversial that we should be cleaning up.

Lee Howard: Lee Howard, thanks for the cleanup.

Paul Andersen: I take it you’re in support?

Lee Howard: Yes.

Paul Andersen: Any items here or anything that the AC should not be ‑‑ Lee Howard.

Lee Howard: Let me ask the question on the collecting the data on Web hosting, has the staff provided guidance to the AC saying we’ve been collecting this data and we find that ‑‑ here’s what we found and the AC has found that there are no changes to policy needed?

John Curran: Right. So at this time there hasn’t been a staff assessment to this policy. But I don’t see anything here that looks problematic. And I don’t see the loss of those stats being a problem.

Lee Howard: And generally if there was concern they would bring it up with their policy concern report.

Sean Kennedy: Sean Kennedy, XO. I agree with the cleanup overall. I actually think 4.2.5 could be useful if you got rid of the “for informational purposes” and ARIN to analyze continuously, but I think it’s useful for web hosting companies, particularly via shared hosting, to provide some technical justification for how many IPs they are assigning per URL and why, if they’re doing one per URL.

So it’s something that we do as an ISP for our customers. And we expect that if we ask they’ll show they’re using SSL certificates per domain or something else.

Paul Andersen: You’re not opposed to them continuing to get the addresses you just want the justification so it will be required.

Sean Kennedy: I think it’s a good hurdle for them stating their policy as far as domains and IP addresses.

Paul Andersen: Would the removal of this not cause still the need to justify?

John Curran: The policy as written doesn’t change the requirements to justify your request. It actually removes the need to collect additional information.

So to the extent they were issuing a request, they’d still have to ‑‑ they’d still have to qualify for it. It’s just we wouldn’t need the information for purely statistical purposes.

I’m not sure how many additional web hosting requests we’re going to get past 2014.

Sean Kennedy: I agree. So it’s a small nit. But I do think it’s a useful thing, and it’s something that we’ve built into our policy for assignments.

Paul Andersen: You’re supporting it in general?

Sean Kennedy: Support it in general. That’s the only nit.

Paul Andersen: Thank you. I’d ask if you are going to comment on this you approach the mic.

That includes remote, sir.

Mike Joseph: Mike Joseph, Google. Minor point of clarification. The current section 4.1.5 states that the determination of IP address allocation size is the responsibility of ARIN.

However, the change to that section would say that the determining the validity of the amount of requested IP address resources is the responsibility of ARIN.

Does that mean that ARIN could not, as its current practice does, change the address allocation size during the course of a request, because today’s ARIN practice would appear to be that if a request is received, ARIN will often without permission of the requester simply issue a different sized block at the conclusion of the request ‑‑ would this mean that ARIN would not be able to do so and would require the requester to submit a properly structured request for a different size that they would have otherwise approved?

John Curran: This doesn’t change the practice at all. I guess I would not agree with the characterization that ARIN issues a different size without the permission of the requester.

We will tell a requester you don’t qualify for what you asked. If you go up one bit boundary, you do qualify; do you want it.

We never force you to take that. It’s up to you whether you want to continue your request. All this says is that it is not the responsibility of ARIN to determine the IP allocation. It’s up to you to ask for what you want. It doesn’t actually change how we’d be processing requests in any way.

It just recognizes that if you want to request a /22, or you want to request a /20, or you want to request a /17, you can do that. The current policy text says we’ll tell you what your request size is, thank you very much.

This allows you to request the size that you want and removes the ambiguity where ARIN is directing you what your request size has to be. Okay?

Paul Andersen: Given that clarification, any comments on that or your support or not support of it?

Mike Joseph: I have no further comments on that. In general this seems reasonable and uncontroversial.

Paul Andersen: Thank you. Last call to approach the mic or start typing or we’re going to close the mic.

Going once, twice, three times. I think it would be useful to if people think it would be good as Recommended Draft Policy.

Okay. So I’d ask those that are supportive of ARIN 2013‑7 as been presented, first raise your hand if you’re in favor of the text. And then secondly raise your hand if you’re opposed.

So those in favor, please raise your hand nice and high until I ask you to put them down. If you can hear my voice, you’re free to show support. Or not.

John Curran: If you’re raising your hand, your elbow should be straight. If your elbow is not straight, you’re doing something else.

Paul Andersen: No hanging elbows, please.

John Curran: Thank you.

Paul Andersen: We have a count. Now lower your hand.

Lee Howard: John owes me a massage.

Paul Andersen: Not commenting on that, sir.

Those opposed, raise your hand as demonstrated by Mr. Curran. Don’t see any.

On the matter of 2013‑7, those that are in favor, 11. Against, 0. We pass off to the AC for their consideration. Thank you.

John Curran: Very good. We’re going to move right ahead in our agenda.

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

John Curran: Next up is Draft Policy ARIN 2014‑1 Out of Region Use.

Martin Hannigan: Mr. Chair, point of order. So I have an interest in 2014‑7 with respect to the Micro Allocation Conservation Update. Do you know when that’s going to be in the schedule?

I have to leave, I have a conflict but I’d like to be back and participate in that discussion, if I may.

John Curran: Because we publish the agenda in advance, we can reorder it, but we need to also tell the remote participants, give them time to know it’s going to be changed. If we handle it immediately after the break, is that soon enough?

Martin Hannigan: I should be able to be back by then, actually.

John Curran: It will definitely be after the break.

We’ll have the original order, and micro allocation will be after the break. So continuing on in our present order, the out of region use is ARIN 2014‑1.

Okay. Draft Policy 2014‑1, Out of Region Use. It was proposed in December 2013 as ARIN Proposal 192.

The shepherds: Milton Muller, Stacy Hughes, Bill Darte. The Advisory Council accepted it as a Draft Policy in January 2014. The text is available online and in your Discussion Guide. It’s been posted to PPML.

Again, to continue its process from Draft Policy to recommended, the AC needs to know if it’s good number policy, which the policy process defines as fair and impartial, technically sound and supported by the community.

Those are the questions we’re trying to addressing. The AC needs to know should it continue to work towards those goals or get rid of it.

I’ll open it up to Scott who will do a presentation.

Scott Leibrand: I promise I’m not going to do all these presentations. This is the last one I’ve agreed to do. If I do anymore, it will be their fault.

So the problem statement here is that the current policy doesn’t forbid or clearly permit out of region use of ARIN resources.

We have discussed this several times at previous ARIN meetings in the context of proposals that would restrict the out of region use of ARIN resources.

We’ve heard loud and clear from the community, this community, in particular, that there are a lot of problems with such restrictions, and those proposals did not get anywhere close to consensus. The author feels the next logical step is to discuss a proposal that clearly permits out of region use with a couple of appropriate limits and with some additional details that we’ll talk about shortly, with operational practice and such.

This policy proposal would add a new section to the NRPM that defines and permits out of region use. It would require that such out of region use be verified the same way that in region use is verified and would specifically authorize ARIN to contract with out of region providers if necessary to verify that use.

The idea there being the requester may not speak English or not be in the time zone and may be more convenient for the verification to occur with a third‑party acting on behalf of ARIN.

It does define some out of region use that is considered incidental. In particular, if you have a need for a small address out of region, it considers that to be incidental and does not put any of the other requirements of this proposal on to that use. It’s simply allowed and not a big deal.

It exempts critical infrastructure from any classification of out of region. The idea here being that most critical infrastructure is small and in the grand scheme of things is not going to require any additional special verification or otherwise.

It says that if you use resources simultaneously in and out of region, for example, for anycast, then if at least one of those instances is in the region then the use is in the region, you don’t have to count it to out of region use.

So very specifically, the policy text says that if any of these are out of region, then your use is out of region unless you get one of the other exceptions that we just talked about.

So if your customer is being billed to an out of region address or serving them out of region address or your POP is out of region, then it’s considered out of region use. It’s still allowed but it’s considered out of region use.

ARIN may engage independent external entities to assist with the verification of information related to any resources used outside the region. I’m not sure what ARIN would choose to do in this case.

I could imagine there would be a third‑party contractor. I could even imagine they might contract with another RIR to do this verification, but that will be totally up to ARIN. This just explicitly authorizes them to do whatever they need to do.

If you’re requesting less than a /20 of v4, less than a /36 or equal to a /36 of v6 and up to 10 ASNs incidental use, don’t worry about this. If you’re critical infrastructure, don’t worry about this. If you are doing anycast, don’t worry about this.

So the questions for the community, the most important one is should we be trying to put a policy in place that clears up the status of out of region use.

Right now the de facto ARIN policy or ARIN practice is that most forms of out of region use are acceptable as long as there is a router that advertises the route in the region. So you can put the least specific tie‑down on a router in California and use all the addresses out of region.

There’s not a lot of clarity in the community as to what exactly that policy is, what’s allowed, what’s not allowed, is it useful to clarify this in the direction of allowing it?

Or because they can already do whatever they need to do to verify utilization and because it’s already allowed, is this a no op and we shouldn’t do it?

Or, conversely, there are people who still think it’s desirable to limit out of region use and that it’s possible that we should do that. If you feel that way, I think you need to address the questions here of why haven’t we been able to come up with a policy proposal that would do that effectively that can gain support.

And I would encourage you, if you oppose this for that reason, to come up with an alternative that would be better. So those are the discussion questions that we, the AC, had for the community, but I’m sure you guys have lots of things you want to talk about as well.

So I’ll turn it over to Paul.

Paul Andersen: Thank you. Just a small thing. I know none of you are reading your email. If you’re checking out tomorrow, they sent a message about hotel rooms and the impending storm. If you were checking out tomorrow, just check back because you have to take an action by noon, apparently. So just bringing that to your attention.

Can they hear me? Also just testing with this mic to see if the remote can hear.

Unidentified Person: Use the other mic.

Paul Andersen: I’ll use both if I have to. Not a problem. On this item, we have people lined up.

Mike Joseph: Mike Joseph, Google. This is an interesting take. We oppose 2013‑6. So I suppose this is simpler. I do have some comments.

First off, the criteria under X‑A, I think, is a little bit unnecessary and potentially problematic. The customer changing a billing address should not change the nature of a utilized resource, in my opinion.

Imagine a cloud hosting customer, for instance, where the cloud resources were in North America but the customer suddenly requests their bill to be sent to Asia, I’m not sure that will change how you account for those resources, and that presupposes you have a billing address for the customer to begin with as opposed to an email and you can tell me what region an email address lives in. So I think that one’s problematic and should be struck.

But, more generally, I would observe that this policy goes out of its way to define out of region. And not too poorly other than the aforementioned correction. And then further goes on to say but it doesn’t matter. Except insofar as the Board may decide to account for it differently later, which is an interesting dance in policy to affect Board billing practices.

But I do raise the question, I think, to staff, which is that if this Draft Policy were to pass, it does observe at the end that this does not cover the criteria under which an organization may apply to ARIN for resources, merely how the currently held resources utilized by that organization would be measured with respect to overall resource utilization efficiency.

So I do raise the question that if this were to pass, what yardstick would ARIN use to determine if the requester is legitimately entitled to obtain resources from ARIN?

Paul Andersen: Staff?

John Curran: This policy proposal actually is relatively new and therefore staff assessment has not yet been done on it. In looking at it, I will tell you that there’s a ‑‑ it’s not intended to change the current criteria for issuing space, it just opens it up to more possible requesters.

So whatever policy you request under would still be the policy you request under. Whether it’s initial, additional, it doesn’t change that criteria. It does acknowledge we can accept requests that have out of region use.

Mike Joseph: That would be helpful clarification, because to the point in the discussion, it’s been our observation that ARIN staff is observing a very conservative point of view with respect to out of region resources.

In fact, some of the assertions made during the presentation I think are incorrect that out of region resources are currently viewed permissibly by ARIN.

John Curran: We’ve identified request templates that have language that is unnecessarily strict, and as I noticed on PPML, we’d like to fix that with the community intent once we can discern what that community intent is.

Mike Joseph: I was referring to RSD statements actually. But in any case, yes, I agree that this is not a no‑up. I think this is, quite frankly, necessary to give guidance to staff as to how they interpret resource justification.

But, again, I raised the question back to staff: Not under what policy would an entity obtain resources, but how would the entity itself be vetted?

If, for instance, an Asian ISP with no US or North American operations were to come to ARIN and request resources, would that request be granted?

John Curran: So all of their use would be out of region use according to paragraph X, right?

Mike Joseph: The X.

John Curran: New section X.

Mike Joseph: Yes. All it would be out of region use according to X.

John Curran: And under incidental use, okay, out of region use of ARIN registered resources by an organization that totals less than these thresholds are considered incidental. So if all of that use was incidental, okay, ARIN’s mission is still to provide, manage and allocate resources in the region. So this makes it clear that that incidental use isn’t a problem.

Mike Joseph: I’m still not convinced you’ve answered my question. But thank you, John.

John Curran: Okay.

Paul Andersen: Before you disappear, you know that famous question I have to ask you.

Mike Joseph: I withhold opinion on this policy absent a more complete staff assessment.

Paul Andersen: To clarify that, for those not as familiar with the process: A staff and legal assessment would be done prior to it entering the next stage. It’s requested by the AC when they think they’ve got the text locked down, just for those that may not be as familiar about the process.

Mike Joseph: But to be clear. I do agree this topic needs to be taken up and I commend the author for attempting that.

Paul Andersen: So noted. Thank you, sir. Next at the mic.

Sean Kennedy: Sean Kennedy, XO. I’m not going to say anything that’s new. But 10‑A is a nonstarter for us.

Paul Andersen: X‑A, you mean.

Sean Kennedy: X‑A. Our IP admins don’t have access to customer billing data. We want to make a technical justification. So they’re not going to look at MRC and other data in deciding whether to assign IPs. So we don’t want to go down that road.

I probably do have more than a /20 of customers that have gotten /24s over the year that have a billing address overseas and I have no idea about that. So I would already be having out of region use, and it’s not clear from the policy what that would mean for me in the future.

So I do wish that that be struck. I do support overall the out of region use, but before supporting this proposal I’d like to see the staff assessment and to be certain that it doesn’t make the policies more permissive, because we do make things work with the current policies. So let’s make sure that it just clarifies them.

And, lastly, I think it’s definitely more clear in its execution and writing than the proposal in the past. So good job from the AC on that part.

Paul Andersen: Don’t run away. And obviously that input can be taken into consideration by the staff when they’re doing their analysis.

Scott Leibrand: You said you wanted to make sure it’s not more permissive. Not quite sure what you mean by that. Could you clarify?

Sean Kennedy: So are there any cases where, for instance, the incidental use part of this would provide a means for the ARIN admin to assign IPs where they wouldn’t have in the past under the current policy.

Paul Andersen: Could there be any unanticipated consequences, is what I’m hearing ‑‑

Sean Kennedy: I’m not ARIN staff, that’s why I’m asking them to review that, not me.

Paul Andersen: Staff will take that into consideration. But before you run away, if I did hear you, you are in support of the context, but you would like to hear some of this text addressed.

Sean Kennedy: Yeah, I’m not personally convinced it’s necessary. But it’s obviously something we’ve talked about in various incarnations, maybe half a dozen times.

So if there’s interest, there’s something that’s well written, let’s get the staff assessment and discuss it one more time and decide.

Paul Andersen: Thank you, sir.

Lee Howard: I’m still trying to make sure I understand what the proposal says. It looks like it says ‑‑ I think it says two things.

I think one thing it says is that the definition of incidental use means that address space is evaluated for determining whether there’s sufficient utilization for an additional allocation.

Incidental space is evaluated the same as any other space and it says out of region space is evaluated as the same as any other space.

Scott Leibrand: But ‑‑

Lee Howard: But what?

Scott Leibrand: I didn’t read the rationale because it’s really long. I mean, I read it to myself, I didn’t read it to you guys because it’s really long.

[Laughter]

Scott Leibrand: The rationale speaks of the possibility of the Board setting a different fee schedule for out of region use than in region use.

If the Board were to decide to do that, then the definitions defined in this policy might be what they use to do that.

If you think that’s going to matter, then you probably care about the exact definition of out of region use. If you don’t think that’s going to matter, then the statement that whatever we define out of region use as it’s okay is what this actually does.

Lee Howard: If I hand waive the billing implications, billed in lira or yen or whatever, then spoken as a former treasurer, then what this says is addresses ‑‑ addresses used out of the ARIN region can be used as justification for additional resources in the ARIN region.

So this would only apply then for organizations that already have addresses and are coming back for an additional justification, whether they got those addresses from ARIN or another RIR or pre‑RIR structure?

John Curran: Staff assessment has not been done on this policy. It’s a brand new policy. This does not, as I read it, apply only to existing organizations. It could be used for a new request.

Lee Howard: I don’t think it can because it says addresses used outside of region can be used as justification. It doesn’t say addresses potentially used, that may be used out of region.

I don’t think that a brand new start‑up ISP in Fiji is going to be able to come to ARIN under this proposal and request a /20, not the way it’s currently written.

John Curran: If that organization in Fiji has a headquarters in California and therefore is in the region, able to request and it has utilization out of region of some resources, it could be resources from ARIN or from another RIR. And we will consider that usage of resources in considering their request.

So the fact that they ‑‑ the fact that they are showing up and saying we want additional address space and there’s going to be numbers of customers out of region making use of them and it’s based on this address space usage, also out of region, we would consider.

Lee Howard: That’s how I understand it. There’s a bootstrap problem. They must have already had address space utilized under the policy proposal as currently drafted.

In other words, they have to use some IPv6 addresses and use that as justification for a v4 request or go buy some IPv4 addresses if they’re a new organization, show utilization in order to come back and get additional address space.

John Curran: The phrase incidental use ARIN resources which imply they already have some.

However, I’m not sure ‑‑ and we have to do staff assessment ‑‑ it’s not clear that incidental use is tied to the prior sentence of verification of out of region use.

Lee Howard: Where I’m going with this is I don’t think I can support new organizations getting new allocations out of region of IPv4 addresses from ARIN. So as written, I think I could probably get behind it.

But opening it up to say: Guess what, ARIN is now the RIR for all new organizations worldwide is a little bit too far, but I think the AC is going to have to clarify that.

Geoff Huston: It will only be a couple of months.

Lee Howard: As Geoff points out, my next comment would be: This does solve the problem of ARIN not handing out addresses out fast enough, since APNIC went through its last one and a half /8s in three months.

Geoff Huston: In one month.

Lee Howard: Thought it was more than that. As soon as this is implemented, we’re done in v4. It’s very interesting. I’d like to see further analysis when the AC presents this at the next Public Policy Meeting, there will have to be an analysis of the intersection of this proposal and the transfer policy also, because justifying resources applies not just to ARIN allocations but to transfers, and we may want to go further and say let’s not do this in v6, I don’t think it’s necessary in v6.

Paul Andersen: I think we should take that feedback, staff can use that when considering their analysis, and the AC can consider it when they want to take an accept. Thank you, sir, if that’s all your comments.

One second, Mr. Huston. We’re a little bit behind. I think we’ll catch up in the second half. But if you’re going to comment on this, I’d ask you to approach the mics before Geoff is done and then we’ll close the mics.

Geoff Huston: Geoff Huston, APNIC. My comment is really editorial rather than opinionated.

The editorial comes in X‑1 and X‑2 where the text explicitly says ARIN registered resources and I’m not really sure that’s what you meant. Previously we had this model that someone came to ARIN for their global network, only ARIN, justified need, allocation, put it all over the world, that was fine.

Other folk went to multiple RIRs and had separate conversations about each regional deployment. Now, this kind of opens up a strange door that goes, I go to APNIC and I get some resources, and I go to ARIN and get resources, but I’m not necessarily doing my deployments within each region.

And I think your intent as authors of this was that when someone comes to ARIN and says I’m going to use it all over the place, you really are looking at their resources they got from all the RIRs, not just from ARIN. And that means a certain amount of additional overhead in mapping organization names, because we might use different names on different regions: Who is this person or this entity across multiple RIRs.

And you’re going to have to kind of have to delve into what they told each RIR and what resources are out there. So my point is I’m not sure you really meant ARIN registered resources in both X‑1 and X‑2. I think you probably meant all resources held by that organization in the totality of the RIR system.

But the wording I leave up to you. But I do flag the inter‑RIR coordination effort will be higher going down this path.

Paul Andersen: Thank you for that, sir.

Geoff Huston: I’m neither for nor against this, obviously.

Paul Andersen: Editorial feedback. Mics are closed unless, are there any out of ‑‑ sorry, any out of room comments? Out of region on the mic ‑‑ you’ll flag it if there’s such the case.

Barry Dykes: Barry Dykes, ViaWest. I agree that A should be stricken from X-A, but I’m a little bit confused what the purpose of B is if it’s not the same as A or if it’s not the same as C.

Scott Leibrand: I can comment to that. If you have a T‑1 running to some island in the Pacific from the West Coast, for example, and you give them a /24 to use at the other end of the T‑1, the service address is the other end of the T‑1 which is in some Pacific island, that would be out of region use. It might be incidental because it would be small, but out of region use.

Barry Dykes: Why not the same as C? I assume they have something there.

Scott Leibrand: It’s possible to have addresses assigned to circuits ‑‑ if you’re an ISP you are not necessarily justifying based on what the customer has at the other location. You’re just justifying based on the customer service address and that they requested stuff.

You don’t necessarily need to verify. If B is there, you don’t need to verify the actual location of their equipment, you just have to say my circuit delivers at that address; done.

Paul Andersen: You’re asking, sir, what’s the difference between a customer service address and technical infrastructure address?

Barry Dykes: If you need IP addresses at ‑‑

Paul Andersen: That’s your question, though.

Barry Dykes: Yes. If you need IP addresses at a location, you’ve got something there, why isn’t that covered under C?

Scott Leibrand: Because the “you” is different. You might be the end‑user that is requesting space from the ISP. The ISP is the one going to ARIN. So for an end-user request I agree they’re the same thing. For ISP request, they may be different.

Barry Dykes: Okay.

Mike Joseph: Mike Joseph, Google, again. I’d like staff clarification, please. Currently RSD’s practice is to request requesting entities including current ARIN resource holders when requesting additional resources where the new resources will be used.

John Curran: Correct.

Mike Joseph: How does this policy change that if at all?

John Curran: So we’ve already had circumstances where we’ve had to, for purposes of anti-fraud efforts, ask people not only where the resources will be used but in the case of hosting customers where the customers are coming from. Because we have some very creative use of VPNs to effectively move demand into the ARIN region.

So that practice would actually become much more common. We would be asking the customer information to determine if someone was relying on usage, we would need to know whether or not that usage was out of region use and whether it hit the incidental limits in this policy.

Mike Joseph: You keep saying incidental limits in this policy, but it would seem whether it hits the incidental limits in the policy, the policy still says it should be permitted.

John Curran: The question is whether or not ‑‑ it will ultimately come down to the text as policy and whether or not those limits are referenced or not.

As I said, there’s no direct reference of incidental use other than the section incidental use.

Mike Joseph: I get that, but even if that section weren’t there, the policy would still seem to suggest that out of region use is now permissible under this policy.

Is that not correct?

John Curran: Right. So noting Geoff’s nuance regarding ARIN registered resources, such use of ARIN registered resource is justified for additional resources. And they would be out of region if any of the following are located outside the region.

Whether or not we would need to determine whether or not the resources were out of region depends on whether or not, A, limits apply, due to incidental use. B, a separate price schedule applies. If neither of those apply, I’m not sure I actually need to know whether or not the usage is outside of region.

Mike Joseph: Understanding that staff assessment is not yet complete.

John Curran: Right.

Mike Joseph: But based on your initial interpretation of the policy, if I were to request resources for my POP in London for the exclusive use in London, would that be permissible should this policy pass?

John Curran: Again, we haven’t done the staff assessment. As I look at this, this says that the ‑‑ to the extent that you have resources out of region, ARIN registered resources ‑‑

Mike Joseph: Let’s say I ask for new ARIN registered resources to use out of region.

John Curran: Right. But you don’t presently have any in London.

Mike Joseph: Let’s imagine I don’t.

John Curran: Right. Which is quite likely actually, but it’s possible because people get an address block and they use it for their global network.

Mike Joseph: Imagine that.

John Curran: If it were in London for London, not current ARIN resources supporting it, I don’t think it allows or changes in any way our ability to approve that.

Mike Joseph: You’re saying whether or not this passes you would still not approve that?

John Curran: The staff assessment has not been done. We don’t know that.

Mike Joseph: Thank you.

Paul Andersen: Could we get the last one. Next speaker, sir.

Joe Provo: Joe Provo, Google. I overall applaud the effort to actually try to set the ambiguous topic that evolved over time in the RIR systems with this. I do think there’s some subtleties that, well, Geoff already got into, but one thing he didn’t hit that I was thinking of was the concern about once the inter‑RIR communication has to be ramped up, there may be some data sharing problems in certain legal spheres regarding customer‑specific information.

And I think everything else I had to say was already said. So thanks. And no, I cannot either deny ‑‑ neither support nor oppose. I’m sorry, I’m hearing my phone ringing over there.

Paul Andersen: Last speaker.

William Sherwood: William Sherwood, Limelight. Kind of a more general comment, I guess. I suppose there are going to be a number here who don’t necessarily take the same position I do. With regards to out of region use, I’ve always considered it to be very impolitic to use address space obtained from one RIR within another RIR’s zone.

Occasionally this cannot be avoided, for example, my own company: When we were trying to establish a presence in Europe and later in South America, it was simply more straightforward for us to utilize our ARIN space immediately.

The problem with that, of course, is once addresses get entrenched, it can be very hard to withdraw that space and return it to its proper region.

It seems that certain aspects of explicitly permitting use of address space within another RIR can potentially step on the policies of those other RIRs in terms of how they interact with their own customers. Then you have a common customer and that customer being treated differently, one RIR to another. And that seems to be an area that could cause some considerable concern. Possibly legal or financial but more probably just political.

My personal philosophy on this is rather than seeing a statement that explicitly permits or explicitly prohibits use would be one that maintains a bias towards strongly discouraging that, realizing that occasionally you aren’t going to get around it and it has to be done and occasionally there’s very valid justification for wanting to do it.

But the other part of that is there is an ever increasing reliance on the accuracy of various geo-location services; and whenever you go out of region on address assignment, that tends to confuse things.

As a representative of a content provider, content profusion provider, I can tell you clearly that’s one of the things that causes enormous number of problems, is trying to map content and services as close to the customer as possible, partly based on geo-location and ending up with the wrong guess because the information that you’re able to dig out based on their IP address turned out to be wrong because of an improper use or inadvisable use of address space. So I’ve got to say that I think this policy as stated is probably not taking quite the right tack.

I very much agree that this needs to be clarified. This is something that’s always been an open question and how it’s treated within an organization largely depends on not so much what ARIN says but what the opinions of those running that organization say.

So I guess that’s the sum of my comments. I would much rather this be a ‑‑ we allow this because we realize it has to happen but we strongly discourage it.

John Curran: Can I ask you a question about your comment?

William Sherwood: Sure.

John Curran: Are your remarks equally to IPv4 and IPv6?

William Sherwood: Thank you for reminding me. I think there’s applications for v6 on this policy, and I think that the language could probably transfer fairly directly without significant modification.

So I’m going to have to say at this particular point, I would say I’m neutral but leaning towards oppose.

Paul Andersen: Glad all I have to do is wave the mic and people can say whether they’re in favor or not. Got you well trained.

One last comment from Scott and then we’ll wrap it up.

Scott Leibrand: Channeling the author and the AC, in an attempt to convey the AC intent. The intent of the author, as I understand it, of the first section of section X, which is ARIN registered resources may be used outside the ARIN service region and are valid and such use is valid for additional resources, the intent here is if you have no space out of region and you come saying I need a block for London, that that would then be allowed under this policy.

Obviously we’ll need staff assessment. If it says that our language didn’t accomplish what we intended it to accomplish, then we’ll change the language.

But for purposes of saying whether or not you’re in favor of this, I think the author and AC’s intent here is fairly clear as delineated in that first sentence of section X.

It’s also the author’s intent that this does apply to v6. In fact, he thinks it’s more important for v6 than v4, particularly because if you come to ARIN with a properly structured request, you should be able to get a /32 or larger. That, in many cases, is the only block you would need for your entire global network.

The author has specifically stated on PPML and elsewhere that he doesn’t see any point in making every network in the planet get five IPv6 blocks to run a global network when they could just get one. So that’s definitely a consideration when you’re evaluating this policy.

Paul Andersen: Thank you. I think we’ve got enough feedback for the shepherds to work with. So I don’t think we need to ask a question at this point unless, Mr. Sweeting, do you have any objection?

Okay. So we’ll hand it back over to John to see what we’re going to do before the break.

John Curran: We’re going to break. Okay. So we have the next policy is Draft Policy 2014‑4, which was remove the Web hosting policy. However, I have never seen a policy proposal get completed in six minutes. And so since that’s ‑‑ since we’re six minutes from the break, we’ll actually break early.

I will see everyone back here ‑‑ we have a half hour break. I’ll see everyone back here at 11:30. So it is currently 10:54. I will see you at 11:30. Thank you.

[Break]

Draft Policy ARIN-2014-2: Improving 8.4 Anti-Flip Language

John Curran: Okay. Welcome back. We’re going to resume with ARIN Policy 2014‑2, Improving 8.4 Anti‑Flip Language. And I want to point out that we have an hour and 20 minutes to get through these.

So history, January 2014, Policy Proposal, Bill Darte, Owen DeLong, the shepherds. The policy text you have in front of you and online, safeguard as always, is this fair and impartial, technically sound and supported by the community?

Problem statement. The current language: Source entities within the ARIN region must not have received a transfer, allocation or assignment of IPv4 Number Resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not apply to M&A transfers.

Now that it occurs to me I’ll have Dan come up and do this.

Dan Alexander: Good morning. So the gist of what the author of this proposal is suggesting is that when the anti‑flip language was originally incorporated into the transfer requirements, the intent was so that people wouldn’t obtain an allocation from ARIN and then turn around and sell it and go back for more.

But what they’re suggesting is that the current wording poses a problem in that large companies with subsidiaries and a collection of organizations, they can’t transfer blocks within themselves because they’ve run up against this anti‑flip language.

So what they had proposed is to add the red text to the existing section to exempt the transfers within organizations and their subsidiaries. And that is the gist of the change.

So the questions become should an organization be barred from transferring an existing block to another RIR as part of a reorganization just because they’ve received assignments or does the clause and subsidiaries open policy language to abuse. And based on your opinion, if you have any suggestion for alternative wording.

Paul Andersen: Thank you for being so succinct, trying to get us on track. Invite if anyone in the room would like to comment on this. I see Mr. Howard standing, thank you, sir.

Lee Howard: Lee Howard, fulfilling my regular role.

Could you flip back to the proposed language, only one sentence. This looks to me like the intent of this proposal is to affect organizations rather than blocks, and my understanding of the anti‑flip language is that it would affect blocks.

The idea is, gee, if you’ve been able to convince somebody to transfer a block of addresses to you, then you shouldn’t be able to flip that same block of addresses that should be locked down for 12 months, I guess, it is. And it doesn’t affect M&A transfers, which is sort of implied, that’s current language, implied question in I think the next slide about open questions.

So I guess what I’d like to see is a restriction on transferring blocks of addresses rather than what organizations can do.

John Curran: So you propose anti‑flipping approach which is based on a block that has been transferred being prohibited from transfer for certain amount of time?

Lee Howard: Yes.

John Curran: But that’s not what the current language says. The current language is the language in black which simply applies to organizations. So this enhances the current language and the current approach proposed different tack on it which may or may not be better. But is a different way of solving that problem.

Lee Howard: I would go further and imply that this is completely the wrong approach.

Scott Leibrand: Scott Leibrand, responding to Lee’s comment. The language that’s in black that’s current policy was intended to prevent the case where someone gets, has a bunch of space, gets a new block from ARIN and then goes and sells off their other space that they already have.

So this is based on the idea that IP addresses can be somewhat fungible if you have dynamic addressing and such. And so just restricting the individual block you receive from them being transferred out doesn’t fix the problem if you have another block that you can just transfer instead.

So that’s the reason for the current black deck. The proposal here asserts that that is a too restrictive form of anti‑flipping and that there should be a caveat that if you’re not going and selling it off on the market to someone else but you’re just transferring it to your own subsidiary, that that should be fine.

Now, the language that you’re talking about, I think, actually might be in the other side of the transfer policy already. There may be an individual block anti‑flipping. There are two different types of anti‑flipping language in section 8 already. This is one of them, and the author feels it’s too restrictive wants to relax it. That’s the part we’re discussing.

But I think the block‑based stuff is already elsewhere or deemed to be not good enough when we originally did it.

Paul Andersen: Is that just a comment or do you have a view on the proposal as well?

Scott Leibrand: That’s a comment. As a member of the AC I haven’t yet formed an opinion on this and I’m looking for community feedback.

Paul Andersen: Thank you, Mr. Howard. You escaped, unfortunately, without stating as such, I believe.

Lee Howard: I said I opposed.

Paul Andersen: You’re quite right. As you say that ‑‑ he’s quite correct. Let me just turn on the right brain again. Thank you.

Brandon Ross: Brandon Ross, Network Utility Force. I’m strongly against this policy. I believe that anything that reduces the liquidity of IPv4 space trading hurts all of us and makes it more difficult to continue propping up IPv4 for as long as we need to get to v6.

Paul Andersen: Okay. Oppose. Got it that time. I apologize to Mr. Howard.

Brandon Ross: I’m opposed.

Paul Andersen: Again, don’t all approach the mics at once. If we have any remote participants, perhaps? Hopefully they can hear. I’ve been told to switch back to this mic.

Stacy Hughes: They can hear you.

Paul Andersen: Okay. More feedback, standing up halfway, maybe again.

Brandon Ross: It’s been pointed out to me that I may have misinterpreted the policy. So I’ll need to reread it. So you can withdraw my objection for now.

Paul Andersen: So withdrawn. So we’ll close the mics or ask anyone remotely to start typing. Seeing shaking of heads. The homies are quiet. I’ll need a moment after that.

So I think we’ve gotten some feedback on this unless, Mr. Sweeting, you’d like any further feedback for the AC?

Okay. Thank you all for your consideration on this. And we will ‑‑ I’ll turn it back over to John.

John Curran: Thank you. I remind everyone to speak close to the mics when you’re speaking ‑‑

Stacy Hughes: I got one.

[Laughter]

Paul Andersen: You got a live one?

Stacy Hughes: Andrew Dul, comment: This policy proposal makes a significant change to the ability of an organization to transfer a block outside the ARIN service region.

Until the inter‑RIR transfer policy was adopted, the ability of an organization to move their block to another region was largely restricted.

Paul Andersen: Thank you. I’ll now turn it over to John again.

John Curran: Okay. We’re going to pick up on schedule.

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

John Curran: Next policy proposal is Draft Policy 14, Remove the 8384 Minimum Ipv4 Block Size Requirements.

Okay. As noted, this is a new policy proposal submitted in January. The shepherds are Owen DeLong and Bill Darte. It was accepted as a Draft Policy by the AC.

It is a work in progress. And so the AC is trying to figure out if it’s good number policy, is it fair and impartial, is it technically sound and is it supported.

I’ll now turn it over to Dan to give the AC presentation.

Dan Alexander: So on this one, this one’s actually even shorter than the previous one, because ‑‑

Unidentified Person: Switch mics.

Dan Alexander: This one is actually a little shorter than the other one in that what the author is suggesting is in the current sections of the transfer proposals, there is a /24 minimum saying only blocks of a 24 or larger will actually be accepted as a transfer.

What he’s suggesting here is that that requirement be removed and any size be allowed. Essentially section 8, 2, 3 and 4 remove the clauses in saying minimum transfer size of a /24.

So what we’re soliciting here is opinions about whether that’s a good idea, bad idea, and whether it should be allowed and what are some of the implications.

Discuss. Mr. Howard.

Lee Howard: It’s great that you remember my name. Having to come up and identify myself because that’s the rules.

Lee Howard. This is a terrible idea. Please don’t do this. Would you like my opinion?

Paul Andersen: In favor or against?

Lee Howard: This is essentially proposing that not only deck chairs but individual components of deck chairs may be rearranged. This is stupid. V4 is dead. Deploy v6.

Paul Andersen: Thank you. Would anyone else like to comment on the concept? It’s a very simple proposal.

Scott Leibrand: Scott Leibrand with Limelight Networks’s hat on. But mostly speaking for myself. Just not ARIN AC. I’m not speaking for them.

There are a number of organizations that have requested transfers of /32 because they don’t understand how the Internet works, and they want their IP address.

I think there are even individuals who have requested transfers of /32. These may or may not have gotten to ARIN as actual requests but there are people who want to transfer their IP. I don’t believe our policy should allow such.

If there’s a good technical justification for reducing the minimum transfer size from 24 to something smaller, I might be in support of that. But eliminating it completely I think is a bad idea.

Paul Andersen: Thank you, Scott. Stacy, do we have any remote participation? Do you got one?

Stacy Hughes: Let me check my homeys.

Paul Andersen: I’m uncomfortable saying that. I don’t know why. We’ll be closing the mics if there’s no feedback on this proposal.

Stacy is shaking her head. I’ll turn it back then ‑‑ thank you for the feedback. I’ll turn it back over to John.

Draft Policy ARIN-2014-4: Remove 4.2.5 Web Hosting Policy

John Curran: Thank you, sir. Okay. We’re going to resume with Draft Policy ARIN 2014‑4, which is Remove the 425 Web Hosting Policy. Okay.

Another new policy proposal January of this year. John Springer and Andrew Dul are the shepherds. It’s in your Discussion Guide and available online. It has been posted to PPML and is presented for the community for discussion.

The AC is looking for feedback regarding whether it’s fair and impartial, technically sound and supported by the community.

And I will now turn it over to John Springer to do the AC presentation.

John Springer: Thank you, John. Hello, ladies and gentlemen. Good morning. So this may look familiar. This is an item that is substantially similar to something else we looked at earlier.

The problem statement on this particular proposal, Draft Policy is “Section 4.2.5 is technology‑specific language that’s not current with modern network operation needs and practices. We should remove it to make NRPM clearer.”

There’s the current wording. It’s been in place since July of 2001. It’s ‑‑ I say functionally identical to the last bullet item of 2013‑7. The differing problem statement is there. The author has been asked and answered that he would specifically like it submitted and considered separately from 2013‑7 and would like it considered independently. However, I think the AC, if we decide to move 2013‑7 to recommended Draft Policy, we’ll do something else with this.

It should be noted that although the Draft Policy says that information will be collected and analyzed, that it has not been. And that it’s not necessary to do so going forward. Does the community see a need for this information to be collected and possibly analyzed? Discuss.

Paul Andersen: Shocking presentation. No. Thank you, John Springer. And I did confirm also with John Sweeting, so, yes, obviously as a clarification, if 2013‑7 was to be adopted, this would render this null, since this is the author’s wishes, but it’s effectively the same change or part of, sorry, 2013‑7.

We’ve discussed this earlier, but I’ll open it up again if someone wants to bring up a new issue or comment. We got some feedback on Web hosting earlier today.

Has the break and some caffeine changed anybody’s views? If you could ask, Stacy, your homeys if they’ve got anything.

Lee Howard, even this will not cause you to ‑‑ I’ll give it a little time in case the remote, the snow is causing some increased latency, unfortunately.

Unidentified Person: Snow inside the fiber.

Paul Andersen: They don’t protect it. They don’t expect the snow. Okay. Calling it once, twice, three times. Closed. Thank you very much.

I’ll turn it back over ‑‑ thank you, John Springer. Turn it over to John Curran.

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

John Curran: Thank you very much. Moving right ahead. Next policy proposal is Policy Proposal Draft Policy ARIN 2014‑5, which is Remove 7.2 Lame Delegations.

Okay. Introduced in January 2014. Stacy Hughes and Rod Seastrom are the shepherds. Accepted as a Draft Policy.

The ARIN AC, it’s available in your guide and online posted to the PPML. ARIN Advisory Council needs your feedback whether it’s good number policy, is it fair and impartial, is it technically sound and is it supported by the community.

And I will now turn it back to John Springer to do the AC presentation.

John Springer: In case you haven’t noticed, these are attempts to do some NRPM cleanup. Section 7.2 was established a decade ago but the audit function that it requires were never put into place.

The author asserts that lameness in IN‑ADDR is orthogonal to demonstrated need and as such shouldn’t be in policy and how to run things like Whois, IRR components should not be in policy.

There is the policy statement and implications. So generally we try to keep operational practice out of NRPM.

A question for the community: Is there something special about IN‑ADDR.ARPA that makes it different? And, if so, does that extend to IPv6 IN‑ADDR.ARPA? Properly running IN‑ADDR.ARPA like choice of upstream provider may affect ISP’s end‑user experience but is that any of ARIN’s business?

Anybody have anything to say?

Paul Andersen: Thank you, John Springer. You’re all very quiet when it comes to removing sections. Interesting.

I’d ask anyone online to quickly comment or someone in the room that would like to speak, perhaps Lee Howard.

Lee Howard: Sure. Lee Howard. I remember having this debate 12 years ago.

Paul Andersen: Not quite. This was actually my first policy proposal when I was a shepherd back on the AC. I remember it well.

Lee Howard: I remember having fairly emotional debates about how bad lameness was, that it was fundamentally broken. And I oppose this proposal.

Paul Andersen: Thank you, sir. Central mic.

Geoff Huston: Geoff Huston, APNIC. I don’t care whether you do this, obviously. But I do know, however, in some recent work on securing the routing system, an alternative proposal to RPKI actually based itself completely in its trans modal in the reverse DNS and it was a thing called rover, and the idea was it pushed information in the DNSSEC side reverse DNS and pulled out credentials.

So if we all walk away from this, we’re walking away from that as well, in theory. Just be aware that some folk have different assumptions what the reverse DNSSEC is good for and you might not find that everyone wants to walk away at the same speed as you. Frankly, I don’t care one way or the other.

Paul Andersen: Thank you, Geoff. Central microphone.

Scott Leibrand: Scott Leibrand. Question for staff and community. My impression from the PPML discussion is that since ARIN changed to using a per zone/per block model, that they haven’t really been doing this per server‑based thing that we instructed them to do a decade ago or however long it’s been. And, therefore, removing this doesn’t actually change operational practice.

However, if as Lee suggested that is something that is still needed, or if as Geoff suggested there may be other reasons for doing something, it would seem that we actually need new guidance to ARIN as to what they should be doing in the new world of delegation of individual blocks and it’s hard to say the server is entirely bad if it’s just this one block that’s not responding, et cetera, et cetera.

So I think we either need to get rid of this or we need to have a new proposal that does the opposite. But the current status quo is rather silly because we’re instructing ARIN to do something they can’t do, and that’s dumb.

John Curran: In 2009, Mark gave a presentation at the ARIN meeting where he noted that the definition of lame for a server when what you’re testing is individual zones is somewhat not conical and therefore needed clarification from the community.

If folks want to remove this from address policy, that clarifies the situation, obviously. If folks want us to do something here, it is possible for us to go to the step of marking servers for blocks that aren’t responsive.

Going to the next step of actual removal, I will say once I understand what you’re advocating, we need to do a legal review, because it’s not clear that removal of servers from records is a fair risk trade‑off for ARIN to do.

So what I need is I need either you guys to remove it or for you to indicate that you want to proceed with marking and/or marking and stripping. One or the other, though, I do agree, Scott.

Paul Andersen: Thanks to the good people at Google, just to clarify, it was 2005 that this policy went in.

Rear microphone. Speaking of Google.

Heather Schiller: Heather Schiller, Google Fiber. The existing policy that we’re proposing to remove altogether already says that you should remove lame servers. So I’m not sure why you’re saying you need to remove lame servers when the policy already says you should remove servers.

John Curran: If the community wants us to strip the DNS records of lame servers, I’d like a conical definition of lame added to this policy. Because when we do that and someone comes back and says you impacted our business, I want to say, yes, we ‑‑ you ‑‑ all you, impacted their business. And right now you’ve not given us that canonical definition that can be coded.

Paul Andersen: Refresh your browser. You need to have the AV working to hear that. Hopefully Stacy will pass that on. (Lost Audio)

Mike Joseph: Michael Joseph, Google. I take no position on this particular proposal, but I would observe that removing servers for having a lame delegation pointed to them would be potentially problematic if someone else pointed the delegation to them.

Paul Andersen: Thank you.

Unidentified Speaker: We’re back.

Paul Andersen: With that, I’ll close the microphones, unless there’s anyone else who wants to comment on the policy or question that Andrew quickly posed.

Thank you all for your feedback. I’ll pass it back to John Curran for the next item.

Draft Policy ARIN-2014-6: Remove 7.1 (Maintaining IN-ADDRs)

John Curran: Excellent. So we are moving ahead to Draft Policy ARIN 2014‑6. Remove Section 7.1, Maintaining IN‑ADDR.

Okay. Per Policy Proposal 198 introduced in January 2014, Rob Seastrom and Stacy Hughes, shepherds. Accepted as Draft Policy posted online and in the Discussion Guide.

It’s a work in progress and the AC needs your feedback on it regarding whether it’s fair and impartial, technically sound or supported by the community.

And once again I will turn it over to John Springer.

John Springer: So another NRPM cleanup policy proposal. The author observes that 7.1 attempts to dictate operational practice again for managing IN‑ADDR.ARPA. And operational practice oughtn’t ought to be in the NRPM. 7.

.1 is silent on IPv6.ARPA which works fine, thus demonstrating that ARIN’s staff technical judgment on implementation is, as usual, sufficient.

Policy proposal recommendation is to remove 7.1 entirely. Again, operational practice generally doesn’t go in the NRPM.

Does the community feel that there’s something about IN‑ADDR.ARPA that makes it different and if such a condition exists, does it extend to IP6.arpa?

Paul Andersen: Thank you, John. More reverse DNS, more removal. Lee, you’ve been beat.

Martin Hannigan: Martin Hannigan, Akamai. IPv6 anybody? Like we seem to be playing Ping‑Pong with these policies.

So remove IN‑ADDR.ARPA, put this back in, two policies for the same thing. What’s going on? The stuff’s been in the NRPM for years, don’t we have better things to do? Thanks.

Paul Andersen: Can I take that as nonsupport?

Martin Hannigan: I could care less.

Chris Spears: Chris Spears, Internet Two. IPv6 already delegates ip6.arpa ‑‑ so IPv6 policy, 6.5.4 already delegates it to ip6.arpa to the recipient.

If we take out 7.2 or 7.1 or both these two policies and there’s nothing guiding IN‑ADDR.

Paul Andersen: John, is that your interpretation?

John Curran: You said 7.5 presently does where?

Chris Spears: 6.5.4. Sorry. 6.5.6 reversal code.

John Curran: 6.5.6. Reverse lookup. 6.5.6 seems to be fairly clear that we delegate responsibility for the reverse lookup zone and that service providers who do assignments out of an allocation in turn delegate to the assigning organization the responsibility if the assignee asks.

It’s fairly complete. You’re saying it doesn’t work without seven?

Chris Spears: I’m saying if you remove this, then if you remove 7.1 ‑‑ is this 7.1 or 7.2? If you remove 7.1 or this section entirely, is there anything that speaks to IN‑ADDR?

John Curran: I see what you’re saying.

Chris Spears: So IPv6 policy currently addresses it where the 4 doesn’t.

John Curran: It would be nice I guess to have language that actually relates to reverse lookup in the IPv4 policy to make it clearer. And that’s probably a good cleanup if section 7 goes away.

Paul Andersen: Thank you.

Lee Howard: I would agree that parallelism, parallel construction of policies makes sense in this case, and I would like that to include reverse addressing. If you’re authoritative for addresses, then you ought to be authoritative for zone.

Paul Andersen: Sight for sore eyes. Haven’t seen you for a while.

Leo Bicknell: Leo Bicknell, Farsight Securities. Could you go back to the second. I just wanted to take issue with the bottom point while I do not have off the top of my head the exact statistic for how much IPv6 has been deployed.

I will quote Geoff Huston roughly earlier that it is a barren wasteland on the edges of the Internet, I think is how he phrased it. I’m not sure that taking the current state of IPv6 as representative of, well, anything is a good idea. So that bullet point just struck me as all kinds of wrong.

Paul Andersen: No view on the proposal? Just a comment?

Leo Bicknell: I think Martin kind of touched more on my general thought. I think ARIN needs somewhere some policy on IN‑ADDR.ARPA. It is quite clear to me that there are many policy proposals attempting to address that in multiple ways and depending on which are passed or do not pass we could end up in a really good or a totally absurd place. And so given that there are so many, I don’t know how to take a position on one.

Paul Andersen: Point taken. Thank you. We’ll close the mics. If there’s no ‑‑ there’s no remote participation.

Stacy Hughes: There is.

Paul Andersen: Of course, anytime. Stacy Hughes.

Stacy Hughes: Andrew Dul. At this time I’m opposed to this policy. While I agree the text is out of date and probably should be updated, I don’t necessarily agree that the section should be removed.

Reverse DNS is an important part of the services that ARIN provides to address holders.

I believe that it is wholly appropriate for the NRPM ‑‑ I got you Andrew ‑‑ to contain a section describing how ARIN should implement our DNS services to address holders.

Paul Andersen: Thank you, Stacy. Thank you, Andrew, and thank you everyone for your feedback on this.

Thank you, John Springer, and turn it over to John Curran. I think we’ve caught up on time.

John Curran: Yes, we have. So back on schedule here.

Draft Policy ARIN-2014-7: Section 4.4 Micro Allocation Conservation Update

John Curran: We’re going to move ahead to Draft Policy ARIN 2014‑7, the Section 4.4 Micro Allocation Conservation Update.

Very good. Okay. History: It was submitted as ARIN proposal 200 in January 2014. Andrew Dul and Rob Seastrom are the shepherds. The policy text has been put on line and is in your Discussion Guide.

It is a Draft Policy that has been presented for community discussion. The AC needs your feedback regarding whether or not it’s fair and impartial, technically sound and supported by the community.

I’m going to turn it over to Dan now. Yes, Dan. Very good. And he’ll give the AC presentation.

Dan Alexander: Hello again. So in this case the suggested proposal is that the current wording of the policy for getting an allocation for an IXP is that two operator ‑‑ a minimum of two operators get together to justify an allocation from ARIN.

What the suggestion that was raised was that this presents possible situations of abuse as the free pool gets depleted, and it’s suggested that maybe that bar is set too low.

So what the policy statement suggests is that the minimum requirement be raised from 2 to 3 to hopefully prevent that potential for abuse. There’s actually a fair amount of discussion on the Mailing List about this.

For those who enjoy that reading, it probably would be a good visit to the Mailing List. The two sides of the discussion have kind of settled around a number of people agree that the bar is too low and that it should be raised.

One point that was made on the other side was for smaller countries in the ARIN region like the Caribbean who have a difficult time possibly getting three people together that this could cause issues for them. So there’s two sides to this discussion and we’re interested to hear more points of discussion from those in the room.

Paul Andersen: Last policy of the agenda here is some vibrant debate, hopefully.

Brandon Ross: Brandon Ross, Utility Force. I’ll reiterate what I said on the Mailing List, which is if you take two companies, you can easily take three companies.

So this does nothing to prevent abuse. The tiny amount of address space we’re talking about will do nothing to preserve the free pool for more than a few seconds. Therefore, I am against the change in policy was that a good start.

Paul Andersen: Go ahead.

Dan Alexander: One other point that I’d offer to the room, as information, while it doesn’t suggest future behavior, just information for consideration is looking at the ARIN websites, there’s less than 70 allocations that have currently been made for this purpose. To give you an idea of scope.

Paul Andersen: Thank you. Next speaker. Martin Hannigan.

Martin Hannigan: Open Access Association. I’m on the board of directors. I’m not necessarily expressing an opinion of the membership, but I wanted to point to the fact that there is an association that is tackling what is apparently the third world condition of IXPs in North America which includes the ARIN region.

There’s a standard that the community developed called OAX‑1. There’s a definition of what an IXP is, and it was fully debated within the community. There was a consensus process. There was public notice and all that fun stuff related to openness and transparency.

With that said, I’m going to shift hats.

Paul Andersen: Did the ‑‑ since you mention that, did it relate to this change? Are they saying policy ‑‑

Martin Hannigan: It was established before this policy was submitted to ARIN.

Paul Andersen: My question being you brought that up. Does the policy speak to the two or the three?

Martin Hannigan: The standard ‑‑ OSX‑1 specifically states that an IXP is defined as three parties.

Paul Andersen: That’s what I wanted to clarify.

Martin Hannigan: Now I’m going to shift hats. Speaking for Martin, not representing anyone.

So I am the author of the proposal. The purpose of the proposal wasn’t to combat abuse. It was to encourage conservation of the /16 that we have reserved for future growth in IXPs.

As I previously mentioned, the state of IXP is unusually broken in North America when you compare it to other regions in the world, and we’re working very hard to improve that situation.

As you’re probably aware a number of IXPs have announced service in the states, New York, Virginia. There are public plans with respect to Chicago. We have a new entrant, Omaha. We’re working closely with a number of parties.

We’re also, or I’m also willing to work with parties in the Caribbean to help them to establish minimum of three participants and bring the tomatoes to the soup, so to speak, and bring some content.

In fact, we’re actually doing that. The purpose of some of this work is to help people to establish these exchanges, not to thwart them. An observation we have when you use, for example, the PCH map directory, and you go through and actually check on the entries in that directory, the vast majority of the entries that are listed is two participants are either dead or the space is being used for personal, that’s being consumed personally.

I proposed an alternative to this policy on the list. So one the underlying text, I suggested that because there’s already text like that in the existing policy. Don’t really care if that goes away or not, if that’s the purview of the staff or the Board, that’s fine by me.

Secondly, I think that the alternative is that ARIN immediately or we move to, and this is a big step for me, modify section 12 and start to conduct audits of people that get this space. If they don’t actually use it for its intended purpose or succeed, I think success is key, I don’t think we want to assign space with pending exhaustion to people that are not going to succeed. We should help them to succeed. We should do things like develop programs.

For example, there’s a pairing program being developed in OIX to help people fund these things and get certified and meet those minimum standards that the committee was polled on that said this is what we want from IXPs.

And, granted, the Caribbean is what the objection seems to be about and it is unique, and I think that a lot of people want to help to make things succeed. But I think that we need to start with some realistic criteria, and I think that this is fairly reasonable and simple. And that’s it.

Paul Andersen: You’re supportive of the text?

Martin Hannigan: I support it. It’s not about shutting down IXPs, per se, in the Caribbean, it’s about using the resources properly and getting some successes.

Paul Andersen: Thank you, sir.

Go ahead, sir.

Mike Joseph: Mike Joseph, Google. I oppose this policy. First, tackling the latter portion first. I believe the existing 4.4 language oversteps the scope of the NRPM and I believe that the underlying section here further oversteps the scope.

It should be the proper domain of the Board to determine how organizations are classified for the purpose of payment of fees and to explicitly call out the taxable status of an organization in the NRPM to determine fee structure is in my opinion wholly inappropriate, particularly considering that the ARIN service region may include countries in which the proposed NRPM language is not applicable.

So I think it’s important that the Board have the leeway to develop the most appropriate language and policy for determining the fee structure for critical infrastructure and IXP assignments.

On the first portion, I’m sympathetic to the abuse concern here. I could certainly see some potential for abuse. I would be interested to hear staff opinion as to whether or not they’ve seen any abuse of this policy to date.

But I can see also a potential chicken and egg problem. You have your first IXP participant and you want to give them addresses, but you have to tell them to wait until somebody else shows up before you can give them their addresses. And I can see that being a problem.

So I’m not sure it’s necessary to change it to three but I would be interested to hear staff’s experience on this point.

Paul Andersen: Don’t run away. First John Curran.

John Curran: Two questions. First, with respect to the scope issue regarding whether this text is within scope of the NRPM, I believe that we can, in the staff assessment, make sure we address that and figure out the right way to phrase the intent.

There is certainly a distinguishing organizations for purposes of whether or not they qualify for resources and whether or not they’re treated as end‑users or ISPs is perfectly appropriate and part of NRPM. I agree the fee question is not an NRPM issue, but we’ll pick that up in the staff assessment of the policy.

Mike Joseph: I would suggest that nonprofit status might not be an NRPM issue either.

John Curran: I understand it. Unless it affects what resources parties are entitled to because the NRPM has allocation or assignment policy that directly is germane to one or the other.

Mike Joseph: I agree that would be different policy.

John Curran: That’s a different question. It would be in scope foolish policy, but the fee question I understand.

The second question you ask is about abuse. I don’t think abuse we see much of with respect to this. But recognize there’s a difference between abuse and aspirational use. And a party that gets an address block and doesn’t fulfill their goals and dreams is not abuse, but it’s fulfillment that didn’t happen. And we do have quite a bit of that.

Dan Alexander: One question I wanted to ask. If we back up from the idea of the difference of two and three being a matter of abuse, as Marty tried to clarify, that the three adheres more to an industry acceptable definition, do you have an opinion about that?

Mike Joseph: So first the larger portion of my objection is about the second half of the text, but concerning the first portion of text, I would be comfortable saying that there was an intent to have more than two participants, but that withholding the space until the third shows up would be potentially problematic.

I’m not sure how to best capture that in policy and I don’t take a strong position on the two versus three, though.

Paul Andersen: Thank you.

Heather Schiller: Heather Schiller, Google Fiber. So I’m opposed to the policy as written mostly because of the second statement that’s been added about IXPs as nonprofits. In regards to the two versus three, there’s a total of like 66 current IXP allocations.

So we’re not talking about like a huge number of allocations that I think will have a significant impact. So I’m not ‑‑ I mean, it raises the bar. What? Barely? I think someone on the list said raise it to five or something else. That’s fine with me, too.

But the part about IXPs formed as nonprofits. So there’s far more ‑‑ at least grammatically the way it’s written all others would be considered ISPs.

In the context of the larger 4.4 section, implies that the folks who get critical infrastructure space for non‑IXP purposes would be considered ISPs as well. So there are far more of those allocations than there are of IXP allocations.

And far more of them are currently end‑users and would be adversely impacted by becoming ISPs, financially impacted. So I think that that policy text has more implication for the non‑IXPs than it does for IXPs, whether they’re nonprofit.

Paul Andersen: You’re talking about the fact this this says “all.”

Heather Schiller: Because you only see the one section of 1.4 which is a larger piece of policy. I don’t think you have the entire statement. So the 4.4 is the entire micro allocation section, which my other micro allocations are made for other types of critical infrastructure like DNS operators.

So the way that it’s written, it implies that that part applies to DNS operators as well. My point is there’s far more than those type of allocations.

Paul Andersen: Heather is correct. Page 42 of your book, section 4.4 actually has other paragraphs that are not here.

So you might want to consider that, both the AC and the membership communities. All right. Last comment. We’ll close the mics. If you’re going to speak on this item, please either start typing or approach a mic. Otherwise, we’ll close it after this gentleman starts speaking.

Name and affiliation, please.

Phil Rosenthal: Phil Rosenthal, IS Prime.

Perhaps a better way to look at it is not for initial allocation but looking at it as audit over the past year of activity.

I know with some exchanges that we’ve been looking at that are launching now, there’s a number of participants talking about joining. Every single one of them are content. I’m a content company. We’re interested in joining, but there isn’t necessarily much value necessarily in actually joining when there is no eyeballs on that exchange.

That gets into way beyond what your proposal is, of course. But my point is that these exchanges do not grow explosively or spontaneously, they grow organically. If you say you have to have a minimum of X number of participants day one, it’s possible you will never have that. And after six months you’ll get a few people that will join, it will attract others.

If the exchange failed, take the space back, it’s out of a special block that shouldn’t be used for anything else right? So…

Paul Andersen: Would you be supportive of this or would you feel ‑‑

Phil Rosenthal: I think that it needs more text. I think it should be audit rather than initial allocation. So as it is written I’m against it.

Paul Andersen: Microphones are closed.

Any remote? Next microphone.

Martin Hannigan: Martin Hannigan, Akamai Technologies. So, sure, the second half of that ‑‑ again, I’m the author of the proposal. I put it there to clean up, I think, if I recall correctly to clean up some existing language.

So, sure, clean it up, and I have no opposition whatsoever to having that adapted to whatever you want it to be.

With respect to the two versus three, renumbering is easy, especially when it’s two to three. And there are other instances of the NRPM where we suggest renumbering is easy as well.

And, again, it’s not about abuse, it’s about conservation. And the 16 that we put aside for DNS infrastructure and for exchanges, I believe at this point is going to be fully utilized in a rather rapid manner in the next 36 months.

So I’m just seeking to raise the bar a little bit. By the way, if you guys want to go to five, that’s perfectly fine by me, too, because again renumbering is easy.

Paul Andersen: Thank you. Last comment.

Chris Grundemann: Chris Grundemann. I had a question about the /16 that’s reserved, because I didn’t remember. It says the end of the policy term. Is that still time‑based where it gets released into the free pool after three years, or is that /16 reserved for one structure, period. I don’t remember.

Paul Andersen: Asking whether the /16 will eventually go back.

Chris Grundemann: Because the policy still says “a /16 of IpV4 address space in reserve becomes restricted as defined,” blah, blah, blah. “If at the end of the policy term there’s unused address space remaining in this pool,” and it goes on to say it will be released. I think that’s just hanging on text. But I don’t remember this.

Unidentified Person: I thought it was 36 months was the option.

John Curran: At this point we ‑‑ at the end of the policy term ‑‑

Paul Andersen: Give us a second.

John Curran: Right. At this point the policy term is no longer defined.

Heather, you were going to say something.

Heather Schiller: We asked that last time.

Unidentified Person: Go to the mic.

Heather Schiller: I’m looking for Leslie, because the AC asked that last month. And I thought that what we said was it was going to be kept indefinitely; they didn’t want plans to release it.

John Curran: Right, there’s no longer a reference, an antecedent, for that phrase.

Paul Andersen: Thank you, Heather, for that clarification.

Leslie, go ahead.

Leslie Nobile: What I said to Heather, if we counted back to the day the policy was implemented and went 36 months, it would be March 2016, I think I told you, that we would release the space. But that the current policy doesn’t have a term limit. It’s not defined in the current policy.

John Curran: The AC should take it upon itself to add that to this policy, either to remove the expiration or set dates certain.

Paul Andersen: Thank you, John. AC can take that into consideration.

Heather, did that clarify or confuse the matter?

Heather Schiller: No.

Paul Andersen: Thank you.

Martin Hannigan: So with respect to that question, I actually made that change to that specific policy as well. And I specifically recall my intent was that I believe once we dipped into the last /8 that allocations would come from that block and 36 months later, whatever was left in the block, would go back to the free pool.

And my intention when I wrote that was that we weren’t providing a crutch for people to hobble along with on v4 forever, we were giving them an opportunity to get started and get their asses over to IPv6.

Paul Andersen: I think as John Curran stated, it would be helpful if the AC could clarify that language.

We had closed the mics. But anything else on this last point that people wanted to address?

Mr. Sweeting, John Sweeting, is there anything, further input you need?

Okay. Thank you very much for your participation. I’ll turn it back over to John Curran.

Proposals (193, 199 and 201)

John Curran: Thank you. Okay. We’re now coming to the last portion of the policy consultation. And what we have is we have proposals, three proposals that John Sweeting is going to just let the community know are underway now. These are not yet draft policies. The AC is still working on the text. But they’ve received them from submitters.

And so, John, if you want to come up and talk about Proposals 193, 199 and 201.

John Sweeting: So 193, 199 should be fairly quick. We probably won’t have, ask for much discussion on that.

But 201 will probably get some good discussion going.

On proposals under the new policy process, proposals come in. They go to the AC. The AC works with the author. The author controls that proposal until such time as it’s determined to be clear and in scope. Then the AC can move it into a Draft Policy status, and that’s when it gets posted to PPML and we start looking for input based on the policy itself trying to create good policy.

So these proposals are still with the AC working with the author trying to get clear problem statement and making sure it’s in scope.

Most likely these proposals will be on the ARIN 33 agenda in Chicago, and you should see them probably on PPML after our next, after the AC’s next meeting, which is the third Thursday of this month.

So the 193 is alignment of 8.3 needs requirements to reality of business. And 199 is to resolve conflict between the RSA and 8.2 utilization requirements.

Most of you might have seen these. I think David Huberman, the author, posted these to PPML, but I’m not sure there was a whole lot of discussion on them.

ARIN Proposal 201 is to remove sections 4.6 and 4.7 from the NRPM. And this is the Board policy suspension action that was taken earlier this year when it was pointed out that there was an actual danger to ARIN there, if these sections remained in force and could be used.

And basically that was somebody with any company with a fairly really large bunch of addresses could go into ARIN and ask for a really big aggregate to take away and renumber into overtime which I think under one policy it was 12 months. Under another section for different reasons it was 24 months.

So, anyway, at this time, getting down so low in the free pool it was what if a company that had a /8 aggregate came in said they wanted, if they had all their addresses together, came in, said we want a /8 to renumber into so we have just one aggregate. So I believe that’s why the Board took that action.

It was on the list. There was a lot of discussion. And in accordance with the PDP, the AC had to make a recommendation on that suspension which we agreed on in our last meeting, was posted to the list, and it’s still there, still can be commented on. It had to be there to take comments for 14 days.

But the gist of the AC’s recommendation was to continue ‑‑ continuance of the suspension. And we also submitted ‑‑ I believe Dan Alexander is author of record, but it was an AC decision to submit that proposal to remove those two sections from the NRPM.

So that’s where we are with that. And we would like to hear discussion on that now if anybody would like to ‑‑ since it’s out there on the list and we can take discussion on it, I would like to hear that.

Leo.

Leo Bicknell: Leo Bicknell, Farsight Security. I see why 4.7, the aggregate, is very problematic. So I have no issue with that going away whatsoever.

4.6, I can understand from reading the text how there are potentially some problematic elements.

However, I can also think of some not very non‑problematic potential uses of 4.6. I believe, and I would like to be corrected if wrong, that, for instance, if a legacy address space holder had way more address than they actually needed and wanted to return that and renumber into a smaller block, they may well use 4.6 for that purpose. And in that sense, while it may tie up more address space for a short period of time, it would actually lead to the return of usable address space to the community.

And so maybe some timeframes and stuff need to be addressed in 4.6, but I think removing it would possibly preclude people from doing that, which would be a bad thing.

John Curran: Given that there is a large amount of address space out there, someone that wanted to downsize into a slightly smaller amount of space such as a legacy /8 holder, could say they need, oh, the equivalent of 3 /11s to renumber their current /8 usage. That’s still a substantial amount of space to suddenly lose out of the free pool.

ARIN’s happy to entertain that if that’s what the community wants. But it would be very difficult to handle a large number of amnesty requests which brought the free pool to zero and then rely on being able to get that space back. It could put us in a very difficult ‑‑ because we have to get the legacy block back. It could put us in a very difficult situation.

So if the upside is seen as important enough for that, it would be good for the community to set under what practices and what circumstances and why it’s desirable.

We suspended both because both have risk.

Leo Bicknell: Sure. I guess my thinking in broad terms, because I’m certainly not prepared to offer specific language that, for instance, limiting someone under 4.6 to being able to get no more than 20 percent of the free pool remaining for that purpose may provide that safety valve that it can’t be instantly drained while still allowing, to the extent the free pool does allow, the exchange of space and thus recovering space down the road. It’s a net gain for the community just delayed.

John Curran: We haven’t had anyone exercise these policies in five years. It’s a great doorway to have for someone to walk through, but I’m not sure people are actually looking at that wall anymore.

Leo Bicknell: I’m hoping that runout makes some people look at that. But I agree that they are unlikely to walk through the door.

Paul Andersen: Thanks, Leo.

Lee.

Lee Howard: Lee Howard. Have you looked at the routing tables for specifically the address blocks of legacy holders, especially large holders?

It does not look to me that the kinds of organizations that Leo is talking about ‑‑ I don’t think they’re people who have large blocks of address space who would want to renumber into largish blocks that would be risky for ARIN and don’t have enough space within their existing block.

So, for instance, legacy /8 holders who would need three /11s, has that and can renumber into part of their existing /8 and return the rest, I would love it if they would return the rest to ARIN but I think it would be more likely they use the transfer market for the rest of the space.

But that opportunity still already exists and I don’t think that we need to risk the free pool for that.

Having said all of that, I think that any organization that was going to renumber taking advantage of these policies would not be able to renumber before the free pool is exhausted.

So we would be giving up free pool space and then maybe getting some more later, maybe. So I agree with what the suspension the Board has done and support the proposal that the AC’s considering right now, and do be 6.

John Sweeting: Any comments?

Marty, do you have something?

Yeah. Thanks. Go ahead, Mike.

Mike Joseph: One of the sections about 4.6 is it presupposes ‑‑ it presupposes an exchange against a free pool. But the other thing it clarifies is something somewhat distinct from that, which is the no penalty for returning point of 4.6.2, the first clause of 4.6.2. And particularly the first sentence of 4.6.2 which states: “ARIN shall seek to make the return of address space as convenient and risk free to the returning organization as possible.”

Given that this now has been suspended by the Board, what risks does an organization now observe in the return of address space to ARIN and how would returning address space to ARIN affect that organization’s further dealings with them?

John Curran: So you can return address space very risk free. I’ve worked with a number of organizations to do that over the decade. And so there’s no risks.

The circumstance of risks described in the amnesty policy is the case where you wish to renumber and return. And the admonishment in the policy text is that ARIN should not create undue timelines or thresholds so that your renumbering plan is endangered.

You must renumber in six months. Well, I didn’t get the equipment I needed; I can’t finish the project. Well, we’re taking the block back and have a nice day.

In the case where someone’s renumbering out of an existing block into another one, ARIN has to have the flexibility to work with that. That also is one of the reasons why the amnesty approach or aggregate approach, when we’re renumbering and someone says I’m running into difficulties, it makes it particularly difficult for ARIN to ever predictively know we’ll get the space back that was assured as a result of the amnesty or the renumbering request.

But absent those uses, just plain old returning of address space, I can make that very risk free.

Mike Joseph: Including subsequent requests.

John Curran: Including subsequent requests, absolutely.

Mike Joseph: Thank you.

Paul Andersen: Just a comment from Gary Bermaster: While there may be a theoretical use of 4.6 to return space, I would find it surprising if any organization would actually consider doing so. The risk likely exceeds the potential benefits. Suspension was appropriate and the section should be removed.

John Sweeting: Thank you. Anyone else?

(No Response)

John Sweeting: Then I’ll turn this back over to John. Thank you everyone for coming. The AC got a lot of useful information out of this.

Closing Announcements and Adjournment

John Curran: Thank you, John. Okay. We’ve got some closing announcements. I’ll just quickly move through them.

First and foremost, this is good preparation for our upcoming Public Policy meeting which will be ARIN 33 in Chicago, Illinois, in just a couple of months, 13th through the 16th of April.

One more thing, we’ve had discussions in the past that people get all excited about all the conversation that’s happened here and they want to make progress, they want to meet with the shepherds and talk about new text and all that other good stuff.

So we’ve arranged for a room, if you want to go from here to another room and work with the members of the AC and further talk or brainstorm, you need to grab them. There’s no assurance they’ll be available. But I see John and I see other AC members here.

The boardroom on the sixth floor is available for people who want to do workshop editing of these proposals. But you’ve got to find a cooperative AC member to work with.

It’s on the sixth floor, and it’s open now through 5:00 p.m. We’ll be doing that after our Public Policy session so people have a way to follow on while the ideas and juices are still fresh.

That’s it. I’d like to thank everyone for coming. It’s been very successful, and I hope everyone continues to enjoy NANOG. Stay safe. There’s some storm coming involving ice, but hopefully that won’t affect the meeting within here.

Take care. Enjoy your day.

[Applause]

[Meeting adjourned at 12:45 p.m.]