ARIN PPC at NANOG 57 Transcript - 5 February 2013 [Archived]

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

Opening And Announcements

John Curran: Okay. I’d like to get started. Welcome. This is the ARIN Public Policy Consultation at NANOG 57. I’m John Curran, President and CEO. I’d like to do a little bit of introduction about this session, and I will then bring up, then invite up some other speakers who will actually run it.

So first: Public Policy Consultation is an open public discussion of Internet number resource policy held with ARIN facilitating the in‑person and remote participation.
We hold these at our public meetings, but we also can hold them at other forums with the approval of the Board of Trustees, including NANOG.

So it’s a little bit of a new thing for us. Figured we would get input on the policies from a greater audience than just the ones who happen to stay after a NANOG meeting to catch ARIN or come out specifically for us.

Today’s agenda has three proposed policy changes: Draft Policy 2012‑2: IPv6 Subsequent Allocation Utilization Requirement. Policy Proposal 182: Update Residential Customer Definition, Not to Exclude Wireless as Residential Service; and Draft Policy 2013‑1, which was ARIN Policy Proposal 183, which is Section 8.4 Transfer Enhancement.

We’ll also have an Open Microphone for policy issues where people can raise topics that they think should be worked on or things that need to be looked at. And you can find each other and get together and work on policy proposals.

So let us move right ahead. Remote participants. We have remote participants. If you’re a remote participant, or if you’re watching us from NANOG, please go to ARIN PPC. You can get the Discussion Guide that has all the policy proposals in it.
This is being webcast. There’s a live transcript. The meeting materials are downloadable. There’s a chat room, if you’ve registered for the chat room. And there’s an online virtual microphone queue. And you can participate when we do a show of hands for indicating policy support.

Rules and reminders: The Chair, in this case ARIN’s Vice Chair, Paul Andersen, will moderate the discussion of the draft policies, so all can speak and all can be heard.
Please state clearly your name and affiliation each time you’re recognized at the mic. That’s also a NANOG thing and they nicely have the microphones already labeled.
Please comply with the rules and courtesies in the Discussion Guide. If you have one of these nice yellow Discussion Guides, there’s a bunch of courtesies in them.
At the head table: Paul Andersen, our Vice Chair and Treasurer; myself, John Curran, President and CEO. We have Chris Grundemann from the ARIN AC. Robert Seastrom from the ARIN AC; Stacy Hughes from the ARIN AC and who is also our Jabber monitor, and John Sweeting, who is the Chair of the Advisory Council.

So I’ll move right in. For each policy, I’ll introduce the policy proposal. I’ll turn it over to the representative from the ARIN AC who will do their introduction to it, and then we’ll open it up for questions and discussion.

ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement

John Curran: First policy is Draft Policy 2012‑2: IPv6 Subsequent Allocation Utilization Requirement. Its origin was as ARIN Proposition 159 in November 2011.
AC shepherds Heather Schiller and Cathy Aronson. It was presented at both ARIN XXIX and ARIN XXX, and identified as needing more work.

The text and assessment is online and in your Discussion Guide. Online, the URL is there. The intent is for ISPs that have begun using IPv6, but may not have sufficiently planned for longer-term growth, to receive an additional allocation. One should set up your v6 allocation plan. If you find out that you need more resources, you shouldn’t have to necessarily change the plan just because it didn’t work out perfectly.

There are no similar proposals or discussions in the other RIRs. Staff comments and issues: These are online in the Staff assessment. We think we understand the intent of the policy, but the new policy text has a sentence which says “having allocated more than 90 percent of their serving site blocks to serving sites and have sufficient actual utilization of their serving sites to continue to justify the block size being utilized for all serving sites as specified in Section 6.5.2 as unclear.” Staff has suggested slightly clearer text, which says: “Has allocated more than 90 percent of total address space to serving sites with block size allocated to each being justified based on the criteria in Section 6.5.2.”

Slightly different but more clear when you look at it.

We recommend that, but we understand the intent of the policy proposal either way.
Legal assessment: The policy does not create significant legal issues.

And now I will open it up to the ARIN AC shepherd, Rob Seastrom.

Rob Seastrom: My summary about this is to tell people that we’re still evolving in the way that we’re laying out IPv6 networks. And particularly in the case of very large service providers, we need a little bit of flexibility to be able to do that as best practices evolve.

And that needs to be policy that is commensurate with our mission of stewardship but also recognizes that the IPv6 world and the IPv4 world are completely different in terms of what adequate stewardship actually means and how plentiful the address space is.

Do we have any slides up here at all? Okay. Problem statement is that we have artifacts of the IPv4 scarcity and slow start thinking. This policy attempts to mitigate that to a certain extent by allowing a longer term planning window and allowing some mid‑course corrections as the space is rolled out and the service providers network with customers actually on it.

So text part one: I’m going to read directly from the slide here because we’re actually discussing what the policy proposal actually is. We’re adding a Section 2.14: Serving Site.
“When applied to IPv6 policies, the term serving site shall mean location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence, Data centers, Center or Local switching office or regional or local combinations thereof. It does not require the implementation of such aggregation routing, only the implementation of an addressing plan that is sub-netted along these topological boundaries to support the ability to aggregate.”
So that text there is new.

Part two, Section 6.5.3, we are adding: “An LIR qualifies for a subsequent allocation if they meet any of the following criteria.” We’re adding, “has allocated more than 90 percent of their serving site blocks to serving sites and has sufficient actual utilization of their serving sites to continue to justify the block size being utilized for all serving sites as specified in 6.5.2.”

Okay. So those are the changes. And ARIN analysts take a liberal view of what’s considered justification here. This is not the regime that you’re used to in IPv4 work. We look at every single allocation and every single SWIP record under a microscope to determine its provenance, whether it’s properly ripe and all that. This is a cut up your network in a way that allows for sufficient growth and a good runway so as not to be architecting one’s numbering strategy every couple of months as the network grows. And if one does that, with a reasonable set of expectations for growth, over time they will inevitably prove to be wrong. You’ll see fractionally more growth in New York than you will in LA. You’ll run out of stuff in Chicago.

Something will happen where you need more address space. Everything that you put out in the network is eminently justifiable and that you need more address space because you aren’t out in sufficient places to justify it in a way that would be justified under the scarcity regime. And at this point you want to be able to get more addresses without blowing up all the planning that you did for the nice hierarchical addressing scheme.
So I’d like to open up the microphones for discussion. I see people are leaving the room already. Wow, that must have been really exciting.

John Curran: Paul will moderate.

Paul Andersen: If anybody has any discussion or feedback, again the purpose of this section is to give feedback to our Advisory Council who is responsible for moving these proposals forward. If anybody would like to speak whether they’re in favor, against, I think this is a problem we’re solving. Right mic.

Lee Howard: Lee Howard, Time Warner Cable. It is my observation that whenever we have an open mic session or some kind of discussion somebody has to go first or the conversation never gets started.

It sounds like this is potentially a slight but not significant liberalization. There could be potentially a few more blocks of addresses coming out. Anybody feel like nodding or shaking their head? Nobody’s shaking or nodding their head. Looks to me like potentially slightly more liberal. In that sense, I think that’s probably a good thing as we are still in fact learning better ways to do our address allocation and assignments internally. So sounds like probably a good idea.

Paul Andersen: So you’re in favor of the direction?

Lee Howard: Sounds like probably a good idea.

Paul Andersen: Center Mic.

Jason Schiller: Jason Schiller, Google. ASO AC. As written, Google, myself and my colleagues, were opposed to this text when we discussed it last for a number of kind of nitpicky issues. All in all, I think the sentiment is it is a good idea.

I’d first like to backpedal through the room and talk about why this proposal is before us. And that’s because awhile back we changed the initial allocation for IPv6 policy and we made that more liberal. The problem was most of the ISPs that came qualified for a /32, they got a /32. And based on the policy as is written at that time, it had to be fairly well utilized before they could come back for more.

When the initial allocation policy was changed, then anyone who hadn’t gotten space could suddenly qualify for much more space. So the idea here was to put the subsequent allocation policy in line with the new more liberal initial allocation policy. And I support that. One of my concerns as written with this policy is, if you go back one slide, the definition of serving sites. And this is going to get complicated, so I apologize. But one of my concerns is when the initial, when the new initial allocation policy was passed, it was believed that you could use serving sites and aggregation as a way to size how much ISP addressing you could get but have no intention of implementing such aggregation or hierarchy. And then the expectation is that you could come back with a single serving site, qualifying for being out of address space as a single serving site and get additional space. But the amount of additional space you could get would again be calculated on the formula that takes the hierarchy and oversizing into account.

The way the definition of serving site is going to newly be defined suggests that you actually have to put that addressing plan into effect in order to make use of this oversizing. So the question is: Why make that change? Well, I’m going to answer that question, actually.

Paul Andersen: That makes it better. Mr. Schiller.

Jason Schiller: So the answer to that is there’s also been discussion about how is this dealt with when you have a hierarchy of serving sites. For example, you have an edge router that’s aggregating customers, a number of edge routers in a single location, aggregate up to a hub aggregation router, carve your network into metros or regional blocks within a single continent.

So if one takes the original formula where you take your most heavily-loaded serving site and count the number of elements underneath it and multiply that by the number of serving sites, if you do it up your hierarchy, you can qualify for much more address space. And the concern was that people would come up with interesting and complicated hierarchical addressing plans, just to qualify for additional IP space.
And the goal with this text was to try and say: You’re actually going to subnet your numbering scheme along the lines you described. And I think that that makes good sense maybe to restrict people coming up with crazy hierarchical schemes.

But I think it’s important to not change the rules that existed in the now current initial allocation, which is that you can certainly simply use this hierarchical map as an oversizing number to determine how much address space you can get.
So we need to try to figure out how to balance those two things. That’s my advice.

Paul Andersen: Mr. Seastrom wants to respond and Mr. Curran. Stick around for a second.

Rob Seastrom: Jason, I had a question. Since you said people would ‑‑ with the understanding that one actually needs a budget to put equipment out there and subsequently number it and needs customers on that equipment to be able to justify coming back under this proposal, I’m going to ask you rhetorically, I don’t want you to actually name names here, but who are these people who would be doing this, how many of them are there in the world?
And does this possibility of a corner case for hoarding something that’s an incredibly plentiful resource, in a corner case where the number of organizations that might try it might for some weird reason might be something that would be able to be counted on one finger, is that a reasonable thing to be worried about?

Jason Schiller: To respond to you ‑‑ Jason Schiller, Google ‑‑ I think the number of companies that would benefit from having much more larger oversized chunks of address space are few and far between, I think more than one but probably less than 10, probably now in the neighborhood of five.

And I think if those companies are allowed to scoop up extra address space in the grand scheme of how much space is available in IPv6, it’s negligible. However, I think that we also need to write good policy that has the support of the community and will pass through the Public Policy process. And I suspect there are people who have concerns, even given how small the extra address space would be consumed is in the face of the total v6 pool and how few companies potentially would be interested in exercising this.

Rob Seastrom: Okay. Thank you. I just wanted to point out that any policy out there is absolutely subject to loop-holing and abuse by people who have the right spirit. So thank you.

John Curran: This is John Curran and regarding the Staff’s interpretation of both of these. So this policy proposal if adopted would allow another way for someone to get an additional allocation, which is necessary because right now it is possible by following your addressing plan to find yourself in an end case that wouldn’t allow you, hence, the additional bullet under 6.5.3.b. With that fixed, I think it’s now feasible, if the community wants to, to require organizations to actually make use of the addressing plan that they showed up with when they requested their address space and not throw their routing balls out but their actual addressing plan is as they described it.

It is true that the way around the corner case in 6.b, in the past the answer has been it really doesn’t matter what your plan that you justified your v6 allocation is, you can go do something else. And that’s necessary if someone’s going to find themselves in a dead end. Now if you adopt this policy proposal and you’ve added to 6.5.3.b, the text that allows someone who has run out of serving site blocks to get another allocation, then it’s no longer necessary for them to be able to rearrange their addressing plan, then it’s worth holding them to the addressing plan.

We have ‑‑ the one problem with people, if they’re not held to their addressing plan, is, as Jason said, convoluted hierarchical assignment schemes actually use a lot of bits very quickly. You find yourself down in the /16s and /18s more rapidly than you might imagine. So I think if the community recognizes that this prevents an organization from getting stuck with its addressing plan, because now if they went out of serving site blocks, they have an option. Then the text of serving site is quite reasonable. If you didn’t have 6.5.3.b, then the one change might leave some organizations in a bind.

Jason Schiller: Jason Schiller, Google. So in the event that somebody decides to build a flat New York with no hierarchy, they have a single serving site, they can certainly use up all the available blocks in their serving site and qualify to come back and get more space as you just described. I’m not concerned about that piece.

The piece that I’m concerned about is when such a network comes back, how much space do you qualify for? And under the current initial allocation, they can pick some hierarchy in their network as a serving site and count the number of elements under that serving site and then multiple that across the number of serving sites and then round it up to a nibble and come up with some sized chunk of addressing.

If they then turn around and do a flat network and run until they’re exhausted and qualify to come back for more, can they use that same formula that says N number of things under a serving site, times N number of serving sites, comes to this, round up to a nibble? And based on this text I think the answer is no. And that’s kind of changing the rules, because I think the intention of the subsequent allocation was so you could apply under the same policy as the initial allocation, which this is a difference.

Paul Andersen: So, Jason, just to clarify, I think you earlier said that you do support the concept of the problem trying to be solved. Do you have any concerns with –

Jason Schiller: There’s two prongs here. On one prong you want to make sure that we’re giving sufficient address space and dealing with hierarchy. And some of the language in the text is to try and constrain use of hierarchy just for the sake of getting additional addresses.

There’s some collateral damage along with that text in that it now changes the intent of the initial allocation as well. Because currently as written the initial allocation allows you to come to ARIN and say: Look, I don’t ever plan on having hierarchy in my network. However, I want a chunk of addresses that’s this big based on this formula of N number of units under a serving site times N number of serving sites, even though I never planned to have hierarchy in my network; this will change that.

Paul Andersen: John has one follow‑up. Go ahead, John.

John Curran: So you are correct. The change to 2.14 being a definition actively changes more than just subsequent allocations. It changes how we will interpret initial allegations, requiring people to have some fidelity to the plan that they actually use; you’re correct.

Paul Andersen: Seeing no one else at the mic, I’d like to move to close the mic. If you had a comment or a point you’d like to make either in support or against this, I’d ask you to move quickly. I’ll look over to Ms. Hughes, and nothing in the remote participation. So with that I will call the microphones closed and activate our unique team of pollers, if possible. And they’ll give me some thumbs up.

So I’d like to pose the question to the room: On the matter of Draft Policy ARIN 2012‑2: IPv6 Subsequent Allocations Utilization Requirement, I’d ask those who support the direction that this policy is generally taking, I’d ask all those who ‑‑ are you the test pattern? Those who are supportive, in favor. Those who do not support the direction the policy is taking, raise your hand high. Good. One in favor, three against. Goes to the Advisory Council for consideration. Mr. Chair.

ARIN-prop-182: Update Residential Customer Definition to not exclude wireless as Residential Service

John Curran: Thank you, Vice Chair. Now we’ll move on to the next policy change. We’re discussing ARIN Policy Proposal 182: Update Residential Customer Definition to not Exclude Wireless as a Residential Service.

History: Was proposed in October 2nd, 2012. AC shepherds are Dave Farmer and Chris Grundemann. The text is online and in your Discussion Guide. We change the definition of residential customer. Removes the requirement that Internet access is provided at a physical residence, thus broadening the definition of a residential customer to all noncommercial users. That’s the Staff understanding. There’s no similar proposals or discussions to our knowledge at other RIRs.

Staff’s Assessment: It’s a policy proposal right now. Note the AC is working with the originator to ensure we have a clear problem statement and clear policy text as required under the revised PDP that we just adopted. And the Staff legal assessment will be performed once the AC has taken the text and submitted it to us.
So I’m going to introduce now Chris Grundemann to talk about the Advisory Council and ARIN Proposition 182, this policy proposal.

Chris Grundemann: I’ll start with the policy proposal author’s problem statement. I’ll read it out here. There’s no difference between mobile and fixed aggregation and address assignment architectures in the real world of real networks. Consequently, ARIN policy should not assert there is a difference.

We’re still working with the shepherd to kind of more clearly define typical need. I can tell you that some of the discussions that I and David and other AC members have had with the author ‑‑ the primary intent here is to change this definition in order to apply the residential broadband policy in the current NRPM to mobile providers, mobile subscribers as well as fixed line and wireless, fixed wireless broadband subscribers. And I believe the reason for that, the reason for that is the residential broadband policy currently allows for a 50 percent utilization rate rather than 80 percent utilization rate. So that’s what this is really about, is the ARIN policy should not assert there’s a difference. What that’s alluding to is 50 percent versus 80 percent utilization rate for residential subscribers versus mobile subscribers.

So the current text is fairly simple. It strikes “at a place of residence” and adds “regardless of OSI layer one or two technologies.” Effectively changing the residential customer definition to instead of define a residential customer, it now defines a personal user, basically, someone who is not a commercial user of the service.
With that, I think I’ll open up the mics.

Paul Andersen: This is a proposal, not yet a formal Draft Policy. And it would be also very useful if people feel that the problem statement is a problem worth solving. Even if you don’t want to comment on the specific text, that would be useful.
I’ll open the mics, ask those who might want to comment approach. Right mic, sir. Name and affiliation.

Jason Kleberg: Jason Kleberg, T‑Mobile. Good overview. Again, the purpose here is really for policy parity when the ‑‑ we believe when the policy was written, the functional pieces on the wire line network, whether it be a B res, CMTS, CSLAM historically the policy was written for efficiencies. With the evolution of the wireless network, what we’re proposing are for like functions of the network that the policy be the same. Essentially that’s what we’re asking for.

Paul Andersen: Thank you. Center microphone.

Matt Pounsett: Matt Pounsett, Afilias. I’m trying to piece together exactly how this all fits together. As far as I can tell, Section 2.13 is definition that is only applied in privacy issues. It changes the definition of residential customer. And the only places where the term “residential customer” appears is talking about Whois privacy.

Chris Grundemann: You’re exactly right. But the current text, proposed text, does not do what the author wants to do. But what we’re trying to discuss is what the author actually wants to do, and we can figure out the text later. So I think you’re absolutely correct. The definition was tied specifically to the residential customer privacy policy. That’s the only place in the NRPM the term is used. So changing the definition does not do what the author thinks it does. But still addressing the problem is ‑‑

Matt Pounsett: And I guess the other main comment I have is that there’s still a massive problem in this problem statement, because it doesn’t actually describe a problem. It describes they can do it so I should be able to, too.
The cable access providers had to go through a huge amount of work to justify changing the way allocation worked, because of the way CMTSs operate. As I understand it, this is what we’re comparing to, right?

I see no justification here for doing that for any other type of access. There’s no explanation of why it’s necessary. It simply boils down to they can do it; I should be able to, too. And I don’t think that’s a good enough justification.

Paul Andersen: So you’re not supportive of this?

Matt Pounsett: No, it’s entirely possible reframed with lots of explanation about exactly how this works and why it’s necessary, I could change my opinion; but the way it’s written out now, no.

Paul Andersen: We can ask the author.

Jason Kleberg: Jason Kleberg ‑ T‑Mobile. I’m not the author, but ‑‑ we’re all on the same page. It’s our understanding that obviously we’re after Section 4.3.2.7; and as interpreted by the ARIN team that this would be ‑‑ the intent was to address Section 2.13 so that it could be interpreted for parity. And I can understand that the cable and other wire line folks did have to do a lot of work back at the end of the day. They did it for efficiencies in working with ARIN and for allocation, and we applaud that. But we’re saying is we have the same type of problem, we’d like to share in some of those efficiencies.

Paul Andersen: Our policy, as you flip madly through the book looking for 4.3.2.7, you’ll notice it’s not there. We did identify unfortunately very late a printing error, but if you wish to follow along you can just go to the ARIN website and see the current versions of PDP. And I’ll turn it over to Mr. Curran. Apologize for that.

John Curran: If you need to go to the ARIN website, pull down policies, pull down NRPM, you’ll see the text 4.2.3.7, which applies to residential subscribers, and it’s what would end up being implicated in this.

Paul Andersen: Staff, do you feel that 4.2.3.7 is being implicated by this?

John Curran: So under 4.2.3.7.3, there’s a section called Residential Subscribers, which describes a alternate policy used for residential service areas of 50 to 80 percent utilization. So changing this definition would allow use of that residential subscriber section and the 50 percent utilization, which is what they’re trying to effect. You can’t discern that from looking at the Discussion Guide. You can if you go online.

Paul Andersen: Thank you for that clarification. Center microphone, please.

Brandon Ross: Brandon Ross, Network Utility Force. I don’t believe the IP on my cell phone should be SWIPed. As far as the rest of the efficiencies, I don’t see why one very specific technology, which is wireless, necessarily should be changed because it’s sort of like residential. There might be something I’m not getting about it. I think there probably is. But it seems to me that we have rules for different technologies sometimes as exceptions for reasons. And so if that’s what we should be discussing, I don’t think this is the way to go about it. But I’m for changing the definition just because it’s the definition that seems to make sense, but I don’t really think that’s the right way to do this, I guess. But I’m also very confused, so if I just confused everyone else, then maybe you should just ignore me.

Paul Andersen: So you’re in favor of changing it to effect the privacy issue but ‑‑

Brandon Ross: Correct. If there was ever any question about the privacy issue, which I don’t think there ever was, then, sure, but otherwise I think we should discuss the real issue, whatever that is.

Rob Seastrom: Hi, Rob Seastrom, ARIN Advisory Council. And I work for a big MSO, which is also a small NVNO. So I know enough about this technology to be dangerous and probably make some very bad assumptions. So I’d appreciate it if our colleague from T‑Mobile could sort of inform the discussion a little bit and explain a little bit in more technical detail about what’s going on, because to me foreign agents and home agents look a lot more like a LAC LNS pair than they do like CPNSs. The CPNS type architecture, expanding into new areas, was very much limited in where you can put stuff physically by the characteristics of the artificial glass plant and physics. So there was this requirement that the addresses actually physically live on the box. It would be as if the addresses had to be on the tower itself in a mobile sort of situation.
And I’m confused as to why, when ‑‑ if you’re going into a new area, that was the whole driver behind the 50 percent requirement. And if you’re going to go into a new area, you need to be able to get more address space to put on that particular box, which is going in that particular physical location.

I’m curious as to what’s driving this from a mobile phone sort of perspective. I don’t know what the appropriate term of art is here, but I hope that we can, in the discussion, decouple and not use the term “wireless,” because it unfortunately conflates people who are wireless ISPs, WISPs doing 80211 type stuff, which very much has the same problem as the cable modem stuff pre‑cable bundle in spades from the discussion about 3G, 4G, LTE‑type of technology. So if you could provide some more technical data to shape that discussion, I’d appreciate it. Thank you.

Jason Kleberg: Jason Kleberg, T‑Mobile. You raised some valid points here. Functionally, what we believe 4.2.3.7 was written for again is a B res, CMTS, CSLAM. It’s a functional piece of infrastructure aggregating subscribers at the end of the day. And that’s where they anchor where their home, their IP addresses, where IP addresses are, pools are configured, allocated and dispersed to users.
So again, it comes down to fundamentally the planning, design piece of it. But again that’s our interpretation of why that section was built. So a TMTS equivalent to wireless would be GTS, something that essentially anchors the customer, when they’re within the geographic boundaries of the services as IPs would live on.
I apologize, that’s a little bit vague. If you guys have some additional specific cases, questions, things like that, I’m happy to expound on it.

Paul Andersen: Mr. Curran.

John Curran: Actually, probably the easiest way to think about what the issue might be defined as, if you look at the present residential customer definition, it’s for individual persons who receive services at a residence, fixed wireless, as some of us lived with in the OMDS phase, actually could be considered a residential customer. Okay? And would actually meet. What doesn’t meet is service through a personal user who is in a geographic area but presently has no residence and is within the service area of a cell. That ARIN would not consider meeting residential customer, where a fixed point‑to‑point wireless we would.

It’s really ‑‑ the definition, the term fixing this to wireless parity is actually probably defined as, better defined as fixing it for mobile parity, which is what’s being sought. Do you concur?

Jason Kleberg: I think it makes sense. At the end of the day it comes down to resources and allocation rights. So, again, our interpretation of ‑‑ we didn’t see a need and why this was proposed of whether a person was physically or billing‑wise tethered to an address or if they’re within a geographic zone. The purpose of some of the ARIN records are for geo-location and upstream pieces. Some other things we could probably be educated on, but we really saw it because we can identify customers to an area that there is commonality in the function of the equipment and thus the request. Are there additional requirements or needs for direct physical tethering that direct, that would require physical ‑‑ just historically it’s been outlined in the policy. Likely because that’s what the solution was at the time, I think.

Paul Andersen: I understand. Mr. Sweeting had a question.

John Sweeting: John Sweeting, ARIN Advisory Council Chair and Time Warner Cable. What exactly would you use as the problem statement? What’s the problem you’re facing that you’re looking to solve? If it’s just ‑‑ I think what people are saying, you’re saying it’s just not fair, that’s our problem, but you must have a technical problem you’re trying to overcome that you’re facing each day.

Jason Kleberg: Absolutely. Jason Kleberg, T‑Mobile again. Really it’s efficiency in working with the ARIN in allocating resources. We believe that this policy was written for that very reason; otherwise everybody would adhere to the normal 80 percent, but there’s efficiencies in infrastructure serving larger masses. So the request really is for policy parity for v4/v6 feature type allocation.

Paul Andersen: I’d like to go to remote participation, been patiently waiting. I’d ask, though, before if anybody would like to make comments, approach the mics. We’ll have to close microphones shortly.

Stacy Hughes: Cameron Byrne, author of the policy, has a comment. He says that ARIN Staff describes residential policy is at 50 percent and ARIN Staff references the definition we are trying to change.

Paul Andersen: Thank you. Far mic.

John Springer: John Springer, Inland Telephone ARIN AC. Inland Telephone is also the majority partner in Inland Cellular Telephone. So I’m in favor of moving this proposal forward in the policy process. But I have some heartburn about the problem statement. There’s a lot of blank assertion that takes place in some of our policy proposals. And this is a good example of it. I’d like to see that fleshed out a little bit more. But I do support advancing the proposal in the process.

Paul Andersen: Last call, otherwise we will close the microphones, unless I see someone moving now.

I think based on the discussion ‑‑ and this is for the proposal phase ‑‑ we’ll pass the feedback back to ‑‑ is there one more comment?

Chris Grundemann: Chris Grundemann, ARIN AC. As one of the shepherds of this proposal, I’d really like to ask anyone who is in favor of this proposal moving forward and see if the problem ‑‑ to seek me out or come and let us know because we’re trying to better define the problem statement. Because I think what we’ve heard over and over again is that the current policy isn’t like ‑‑ but the current policy didn’t come about out of a vacuum, came about out as a specific technical need that was expressed and solved. And what we’d like to do is identify what that technical problem is and then solve it in the best way possible. So getting that more concrete problem statement rather than I don’t like what the policy says is going to be very helpful moving forward.

Paul Andersen: Took the words out of my mouth. If anybody has input, please join the list or Chris in the hallway. We’ll take the input that we have gathered here and pass it on to the AC for consideration.

ARIN-2013-1: Section 8.4 Transfer Enhancement

John Curran: We’ll move ahead to the last policy proposal of this session, and that is Draft Policy 2013‑1, Section 8.4: Transfer Enhancement.

Origin: It originated as ARIN Policy Proposal 183 in October of 2012. The AC shepherds are Scott Leibrand and Heather Schiller. The text is online and in your Discussion Guide. What’s not in your Discussion Guide is the NRPM section that applies. Again, you’ll need to go to the NRPM online. This deals with Section 8. For remote participants, you’re already following, that’s fine.

ARIN Staff summary. We have not done a Staff assessment. But it would allow Inter‑RIR ASN transfers. In looking at the text, there are no similar policy proposals or discussions, and staff assessment has been posted last week for discussion per the new PDP. Staff assessment will be performed upon request of the AC, once the text is fully developed.

One note that came out in the reading that we did is that it, by substituting IPv4 and ASNs for presently where it says IPv4 number resources, there is one little nit case where currently the Inter‑RIR transfer policy, in one of the bullets, precludes a participant from taking part in a transfer if they’ve already conducted one.

And the question is whether this ‑‑ a literal reading would say if you have transferred an ASN or v4, you can’t transfer an ASN or v4, and potentially that might want to be respectively. If you transfer to v4, then you cannot participate in another transfer for 12 months or if you transfer an ASN, you can’t. But that’s a very small nit. The policy change is very simple, and it’s a consequence of the simplicity of the text presently.

So I’m now going to let the shepherd come up and talk about Section 8.4: Transfer Enhancement.

Rob Seastrom: I think you said that Scott and Heather were the shepherds. It’s actually Scott and me. I don’t really look like Heather.
[Laughter]

So the problem statement is that we’re looking to encourage recovery utilization of idle resources. You can already transfer ASNs within the ARIN region. It’s already covered by existing policy. Harmonizing that policy with transfer policy that allows us to transfer Number Resources outside of the region. The text change is: Change all occurrences of IPv4 number resources to IPv4 number resources and ASNs. And change all occurrences of IPv4 address resources to IPv4 number resources and ASNs, only in Section 8.4, which is the transfer outside of region policy. I guess we’re at the end of the slide deck.

Paul Andersen: So we’ll open up the microphones to those that would like to talk either in support or against this Draft Policy 2013‑1. Again, Mr. Howard is standing up.

Lee Howard: Lee Howard, Time Warner Cable. A number of people, at least one, has done an analysis on how much address space could actually be transferred, IPv4 address space could essentially be transferred between a market or between regions or anything. Or maybe I haven’t shown you guys that analysis yet, and I do it with the next email. Has anybody done an analysis on how many ASNs might be transferred? Is this a big problem? A small problem? A potential problem?

John Curran: First, note that this is presently, if adopted in the ARIN region, one hand clapping. A matching policy would need to be adopted in another region to allow Inter‑RIR ASN transfers. If that were to occur, then we could figure out what’s potentially available to transfer. I’ll note that we have had within the ARIN region three ASN transfers. I’ll talk about that at NANOG tomorrow when I give the ARIN update.

So ASN transfers aren’t unheard of. People are asking ‑‑ the policy proposal would suggest potentially, the Draft Policy, suggests potentially that if an ASN transfer is useful, potentially could be useful Inter‑RIR, but I’m not actually sure, unlike v4 that has a run-out condition, I’m not actually sure why an operator would need to transfer at all. So I don’t know if there’s a lot of demand. There’s certainly a lot of supply.

Lee Howard: Can I follow up on that question? Can I follow up on that answer? Are you ‑‑ so the transfers that have happened, are those specified transfers, are those merger/acquisition transfers?

John Curran: Specified transfers I believe, yeah, all three specified transfers of three ASNs, they’re listed in the Staff’s files.

Lee Howard: The reason I asked is because you said there’s no run-out of ASNs the way there is in v4 address space. But there are different sized ASNs. Much like there are different sized ISP addresses. I could imagine there being some connection there and some people want shorter ASNs or lower-numbered ASNs or magic-numbered ASNs or something. But I don’t know. That’s what I’m trying to figure out is whether we need to spend time on this.

John Curran: So currently we still have the shorter ones, though. So I’m not sure, and we may have them for some time. So it may not be due to lack of availability. I do understand some people like ASNs that look pretty. And that might be pretty pattern or lower. But I don’t think run-out is a driver at this point, if that’s the question.

Paul Andersen: Mr. Howard, are you here to speak in favor or against?

Lee Howard: At the moment I’m opposed, because it doesn’t actually look like it’s needed, but I would be happy to entertain that it is.

Paul Andersen: Thank you, wonderful input. Center microphone.

Matt Pounsett: Matt Pounsett, Afilias. My comment is sort of related. On the one hand I understand the urge to symmetry. I’m not exactly sure this is necessary. Like we have ‑‑ there is no RIR that is running short on ASNs. I don’t really see a particular reason to spend the time on this unless somebody has come up against a specific problem that needs fixing. So, yeah, I’d say I’m against it unless we can clarify that somehow.

Paul Andersen: Thank you.

Jason Schiller: Jason Schiller, Google. I agree with the two previous speakers against for the same reason. But in terms of symmetrical‑ness, which is a desirable property, apparently, why would we not also include IPv6 number resources? Don’t you think having asymmetrical policy is important?

Paul Andersen: But you’re opposed to this as written? Do you want to respond to all IPv6 might not be included?

Rob Seastrom: Because they weren’t in the policy proposal as originally submitted by the author.

Paul Andersen: We had three people so far, anybody who wants to come and speak in favor? Anyone want to speak? Remote participants potentially coming in?
Mr. Grundemann.

Chris Grundemann: Chris Grundemann, ARIN AC. I don’t hold a position. I may poorly paraphrase it. There’s been discussion on PPML regarding rationale for ASN transfers. And one of them was basically along the lines of purchasing an ASN for the peering advantages. So there may be an ASN that folks like to peer with. If you were able to buy that number they may just want to peer with you because you have that number. That was listed as the reason on the Mailing List.

Paul Andersen: Just giving us a point of information on the report. Mr. Schiller?

Jason Schiller: Jason Schiller, Google. I think the point was slightly stronger. In the case of some legal contracts, the ASN number might actually be included.
So by grabbing hold of such a number, you may have legal rights to peer.

Paul Andersen: Last call for microphone call‑ins. Mr. Howard.

Lee Howard: Lee Howard, Time Warner Cable. Took me a minute to sort of digest what Jason just said as a nuance of Chris’s comment. I think what Jason said: If I’m able to buy, let’s say, AS 701, that’s a funny looking AS, let’s say I can buy AS 701 for $500, but there’s contracts in existence which would give me rights. I would then have legal rights based on existing contracts to require others to peer with me based on the fact that I bought an ASN. The law of intended consequences trumps contract law. Let’s not do this.

Paul Andersen: Center microphone.

Martin Hannigan: Marty Hannigan, Akamai. I think you’re a little incorrect there. Most agreements are not codified in contracts. They could be terminated at any time. In fact, it’s even easier to terminate a peering agreement with a contract and just stop sending prefixes.

Paul Andersen: Mr. Hannigan, are you in favor or against this policy?

Martin Hannigan: I’m the author of the policy proposal. There were a few different reasons I proposed it. One was symmetry. And another was theoretical transfer between multiple entities, international, Akamai International DB, Akamai Latin America, Akamai North America, Inc., et cetera, et cetera. That was some of thinking. I was also the author of the current inter ‑‑ the transfer policy that we have now that allows specified transfers, sales, purchases, whatnot. And the motivation there was simple. There’s a lot of kind of underground ASN transfers that happens. The Whois is not accurate. There was an effort there to kind of help correct that.
It did happen. Things are documented as done. John demonstrated. Same things happening internationally. Will it stop the cogs of commerce if we don’t ask for this proposal? Of course not. If you want to have an accurate Whois, everything above board, you might want to consider it.

Paul Andersen: Thank you, sir. Front and center microphone.

Brandon Ross: Marty said what I was about to say. If you don’t do it, people are going to find some other way to do what they need to do and build on, if you want the peer question, if their AS number changes, that’s a perfectly good time to say, oh, by the way, I actually didn’t want to bother updating your config, I’ll just de‑peer you.
So I believe the record, keeping the records accurate, that is more valuable than the time we’ve already spent discussing this, and I don’t really see the downside. So I am in favor.

Paul Andersen: Thank you. Last to Mr. Howard.

Lee Howard: Lee Howard, Time Warner Cable. To respond back to Marty who was responding to me. I don’t disagree with your characterization of existence of contracts and how contracts work and what clauses are usually in those things.
I was specifically responding to Jason’s assertion, and if stipulating that, then that’s my conclusion. I think we’re on the same page, as far as I could tell.

Paul Andersen: Thank you. The microphones being closed, I’ll talk about remote participation. It takes an extra second.

I’d like to take a poll now, our last participation polling of the day here. So just gives us a moment. If you can hear the sound of my voice you’re eligible to put your hand up either in favor or against the question of whether or not you support the direction of this policy. So I’d ask on the matter of Draft Policy 2013‑1, Section 8.4, Transfer Enhancement, all those in favor of the direction of the policy statement, please raise your hands high or vote via remote participation. Please keep your hands up until I tell you to put them down, as we look for a signal.

John Curran: If you could raise your hands nice and high, that would be helpful. The ceiling is sufficiently high. You will not hit it.

Paul Andersen: You’re good. Put your hands down. Now I would ask for all those who are opposed to the direction this policy is taking, if you could please raise your hand nice and high.

Okay. Thank you. Okay. And the envelope, please. On the matter of 2013‑1: 61 in the room. In favor, 12. Against, five.

This, along with the input, would be provided to the Advisory Council. This concludes the policy section. I’ll turn it over to Mr. Curran for our open microphone.

Open Microphone

John Curran: Thank you, Paul. Okay. At this time we’re going to have an open mic section. And that will ‑‑ going one back here ‑‑ that will be open for any policy matters people want to discuss. In particular, if you have new policy areas you want worked on, this is the time for you to express your concerns and have others hear them, find similar minded people to work on your policy proposal.

So the microphones are open. If people would like to raise matters about Number Resource policy, now is the time. Yes, Lee Howard.

Lee Howard: Lee Howard, Time Warner Cable. This is a very handy document that’s been printed out for us. It’s also a very heavy document. How many trees gave their lives that we might have this for this hour?

John Curran: As far as ‑‑ it’s an excellent question, actually. So we do a number of things at ARIN that aren’t necessarily as green as they might be. Amongst other things, we have meetings where people fly around and go to rooms. ARIN does actually, for the travel we sponsor, we do actually pay carbon offsets, because it’s the right thing to do.

We do try to avoid producing unnecessary paper and have gone to, in our regular policy meetings, we’ve gone to consolidated guides and less paper. We thought for kicking off these at NANOG it might be good because not everyone is practiced at bringing up the Draft Policies on the NRPM. Even though you had more practice looking at the NRPM this time around because of the guide, I think we’ll probably continue with paper for a few of them. But once people become practiced, if people don’t need them, potentially we can omit them or have a stack of them on request and not presume everyone in the room is going to need one.

Jason Schiller: Jason Schiller, Google. My laptop screen is small. I’d like to have the text printed out. I’d be happy to preorder it at the time I sign up for the meeting.

John Curran: Thank you, Jason. Martin.

Martin Hannigan: Martin Hannigan. 20/30 vision with a plus 1 correction in my left eye. If you’re going to print them, please don’t use yellow; I can’t see it.

John Curran: Okay. Point taken. Discussion remains open. Anybody who would like to talk about that or any policy matters? I will note that we are the last session of the day. We’re sort of all between you and your first evening refreshment. I’ll keep the microphones open for another minute or two.

Remote participants, any questions? I’m closing the mic shortly. I’m closing the mics.
The microphones are now closed. I’d like to thank everyone for participating in the Open Microphone. I’d like to thank you all for participating in ARIN’s first Public Policy consultation at NANOG.

Thank you very much.
[Meeting adjourned 5:36]