ARIN XXIX Public Policy Meeting Draft Transcript - 24 April 2012 [Archived]

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

Opening and Announcements

John Curran: Good morning. If everyone would come in and be seated, we’ll get started. Apparently last night was a great social because some people haven’t made it back here yet. The room is sparser than it was. I’d like to thank our sponsors for connectivity, Telus.

[Applause]

John Curran: I’d like to thank last night’s social sponsor, .CA.

[Applause]

John Curran: Rules and reminders. Our chair will moderate discussions of the Draft Policies so all can speak and be heard. Please state your name and your affiliation each time you’re recognized at the mic. Please comply with the rules and courtesies in the program.

Today’s agenda: We have the ARIN Consultation and Suggestion Process Report. We have a report of projects that have been suggested to us that are awaiting prioritization. I’ll give some comments on the Policy Development Process Update. And we’ll have an IANA Activities Report that Elise will give. We have AFRINIC and RIPE Reports. And we will also hear the NRO Number Council Report and the NRO Activities Report today.

And then, finally, we’ll have a policy experience and implementation report, which is where we talk about the staff views on what policies have issues or might be something for people to consider.

That will actually be just before the Open Policy Hour, which is our BoF where we talk about new policies and consideration of policy changes that aren’t yet proposals or Draft Policies.

We are going to have quite a few policy discussions today. We have Draft Policy 2012‑3: ASN Transfers. And Policy 2012‑1: Clarifying Requirements for IPv4 Transfers. We’ll do those this morning. And then this afternoon in the Policy Block we have IPv6 Subsequent Allocations Utilization Requirement. And Draft Policy 2012‑4: Return to 12 Month Supply and Reset Trigger to /8 in the Free Pool.

It will be a very busy day. At the head table I have our chairman, Tim Denton. I have Bill Sandiford on the AC. I have Bill Woodcock, Chris Morrow from the AC. I have Rob Seastrom from the AC and trustee Paul Vixie. And that’s actually the first time I’ve never not blanked on a name.

[Applause]

John Curran: So with no further ado, I’d like to start right off. First report that’s coming up is Nate Davis will give our ARIN Community Consultation and Suggestion Process Report.

ACSP Report - Reveiw of Open Suggestions

Nate Davis: Good morning, everybody. As John mentioned, I’m Nate Davis, Chief Operating Officer for ARIN. I’m going to go over the open suggestions we have. But as a little bit of background, for those of you that don’t know, ARIN operates a community ‑‑ or, excuse me, a Consultation and Suggestion Process for those things that are of interest to the community that ARIN do but are outside of the Policy Development Process.

And typically we use this to capture input from the community regarding new versions of the RSA, LRSA, and other matters that are important to ARIN. When we put out consultations, we have a little bit of a problem, and that is that we don’t receive a lot of feedback. Sometimes we get one or two folks that provide feedback, and that’s about it. So we’re really looking to everybody to go through the consultation process, if you will, go to the website and comment on these open suggestions.

Let’s see. What we’re doing now is we’re queuing suggestions that have merit but are not implementable right away, and the purpose of that is so we can survey the community and get feedback. And we do that two weeks in advance of the meeting, and we ask that you discuss and write those and provide us feedback. And it’s intended to aid us in how we prioritize overall projects for ARIN in addition to some of our strategic initiatives.

We have seven active suggestions that were part of the open suggestion review period, and we’re looking for the community to go out to ARIN Consult and note whether each of these projects, the seven, have any merit. Are they worth doing? Is it something ARIN shouldn’t be doing? Any feedback that you can provide regarding the scope or any other thoughts. We’re really looking for feedback. And if you can provide a ranking, that would even be better, because that gives us some reference point as far as what’s important to the community in terms of what ARIN should be working on.

So you have in your meeting folders, you actually have these suggestions listed, these open suggestions listed. Or you can actually go out to the website at that URL at the top of the screen and provide your input. So the handout is for reference for you to review, and, equally, you can go out to the website to provide that feedback. So the suggestions that we have are 2012.2, Web‑based Whois Results Improvement; 2012.1, Restore Some Email Functionality; 2011.29, Add Links to Query Responses; and 2011.21, ARIN Online User Interface. 2011.17, that’s actually a typo. That’s Access Controls to APIs. 2011.7, Display Agreements Associated with ORGs. And 2010.7, IP Whois Community Reporting System.

So starting first with the Web‑based Whois results, it proposes that Web‑based solutions ‑‑ or, excuse me, that Web‑based Whois search results display the item that you searched at at the top of the result page, top of the results page. So when you put in a query, it doesn’t necessarily keep what you searched for at the top of the results. And if you get many layers into actually doing these queries, you can lose track of actually what the search results represent.

So staff has taken a look at that. The engineering department estimated it’s about 268,000 to do that. And it would involve a significant amount of reengineering and retesting, particularly the Web proxies, to reflect the query along with the query results. Restore some email functionality. Request that we have email confirmation of submitted IP requests or submitted templates that provide full updates to that email when the ticket is updated and additionally includes the ability to reply to the email in order to interact with ARIN Online.

Now, this is interesting because the reason this is being brought up is any submissions for request through ARIN Online, actually you have to go back in your ticketing, go back into the message center for ARIN Online, and this is asking for that information be sent via email back out to the person who submitted the request. So staff has estimated that for engineering it’s going to be a little over $36,000, just under 37,000. But there’s some limitations in our estimates, so we need you to take that into consideration; that ARIN Online users would have the option to receive the email from ARIN Online in addition to the messages being posted to the message center. Additionally, these emails would not include any attachments that possibly might be associated with that, and that the user would not be able to reply in email at this point back into the ARIN Online system.

Add links to query response. So requests that if you’re in Whois, and, for example, you submit a Whois request and that block actually resides in the RIPE region, that we come back with the link ARIN Online ‑‑ or, excuse me, Whois comes back with the link and provides that link to RIPE’s Whois so that you’re immediately taken there and can do your search there. Engineering has estimated that this would cost about $99,000 to do. And upon entering a query, Whois query, for a block administered by another RIR, and this is ‑‑ I use RIPE as an example, but this is actually functionality that is being suggested for all other RIRs, that a user receives a hyperlink to that RIR’s Whois record search rather than the specific record for that RIR Whois.

ARIN Online user interface. Immediately bring back a request to the resource templates for the convenience of those who understand and like them and also have a UI person come in and take a look at our overall user interface that we have with ARIN Online, go through that with a fine‑tooth comb and make improvements and suggestions and so forth.

ARIN was unable to provide, if you will, a level of effort at the time, but one of the things we’re planning to do is, pending budget approval, actually propose we have a UI expert come in and take a look at the entire interaction process for ARIN Online. With regards to reinstating resource request, that’s the piece that we didn’t actually estimate, and then part of this suggestion included bringing back some email functionality, which we just mentioned.

Define access restrictions for API. So this is the ability to define access restrictions for each API generated. These restrictions would allow the registrant to specify exactly which RESTful and, therefore, template actions may be performed using key, including separation of read/write access for each type of modification. It should also be possible to limit the API Key to performing actions on behalf of the POC. So there’s ‑‑ sort of this is two items, if you will, is one access controls associated with the API and then underneath that also associated with the POC. So there’s engineering associated with this as a result. It’s about a one and a half million dollar estimate according to Mark and his team when they look at this, because there’s several layers of complex coding that has to take place to satisfy this requirement.

Display agreements associated with organizations. And this is really the ability to have agreements and associated with organizations’ resources so that folks who come into ARIN Online can see which agreements are ‑‑ and version number is associated with not only the organization but the resources. For the purposes of estimation, we took the resources piece first, and that came out to a little under $19,000. And that would include we’d provide at the resource level the RSA, including the version number, LRSA and its version number, and that the information would be shown for NETs, ASNs, but not necessarily ORGs. But it would provide that information of interest at the ORG level.

And then IP Whois community reporting problem. If you’re familiar with it, we have a fraud reporting system which is if you go to our static website, you’ll be able to submit any type of issue that you believe IP numbers were used in the commission of fraud. And so in that similar fashion, if you will, we would actually provide a Whois reporting system, and this would be on our static website, and it would be an ability where folks can actually identify any problems associated with IP Whois and report those back to ARIN for research and correction as needed.

So staff estimated it to be about $52,000 plus a little bit of effort on implementation and training and so forth and communications around it. And, again, we would provide a form outside of ARIN Online so you wouldn’t have to log into ARIN Online to actually report this. It would be on the static portion of our website, and there you can report stale or invalid Whois information.

So, again, I encourage everybody, please, to take a look at these suggestions, provide your feedback to ARIN Consult, and we’ll have this consultation open until the end of this month, the 30th of April. Alright. Any questions? All right. So the next thing I’m going to talk about is unplanned functionality, I believe.

Projects Awaiting Prioritization

Nate Davis: So it’s projects awaiting prioritization. A little background on this. We have internally generated ideas. We sometimes get them indirectly from the community on things that ARIN should consider that don’t come through the process, come through informal consultations or things we recognize internally that we probably should at least discuss with the community in improving ARIN Online or other pieces of things that ARIN does in fulfillment of its mission.

One may conclude in looking at these on the website that these are things that we’re actually going to plan to do, and they are not. So I wanted to make that clear. These are things we’re considering doing, but, again, we’re looking for community input so that we understand whether it’s something we should consider, we should budget for, and we should plan on doing. For background, I wanted to talk about what we are planning to do this year. So that that’s clear. We have hosted RPKI coming out, which Mark will probably discuss in his presentation later in the meeting, and that is currently slated for Q2.

Following hosted RPKI we have the delegated RPI model which allows ISPs to actually issue their own certs, and that is for Q3 of this year. Then managing unmet IPv4 requests. These are requests that come into ARIN. And ARIN at some point is not going to have the address space at that time to satisfy the request. So as a result of that we need to build some functionality into ARIN Online that provides for that. The request comes in. We essentially approve the request, but we don’t have the address space at that time. And issuing that address space would be dependent probably on returns or what we have available at some point later in ARIN’s pool.

Secondly, payment integration. One of the last key pieces that we need to do is to integrate our internal accounting system with ARIN Online so that folks can actually pay bills through ARIN Online for services that ARIN provides. So we would be able to provide you to take a look at your outstanding invoices with regard to your balances and to make payments through ARIN Online. That is designated for Q3 this year. And then, lastly, is SWIP Easy, which is creating a Web‑based reassignment and reallocation interface within ARIN Online. It’s really intended for those who perform occasional reassignments and reallocations and those who manually complete their templates otherwise.

So those are the things that we have planned so far for this year. So we have lots to do this year and, as with any type of projects, these may be shifted around depending on such things as policies that are ratified by the board or other conditions as ‑‑ in the ARIN environment that may change. So let’s talk about an overview. So in addition to the planned functionality, as I mentioned, we keep track of these internal recommendations, community thoughts and so forth for service, those that we generated internally. These await priority, prioritization, planning, budget approval and so forth before we start on them.

So, again, we’re encouraging the community to provide us some feedback regarding these additional services that may be of interest to everybody. You can view these projects at www.arin.net/features. Or if you navigate through the website, it’s actually under Number Resources, Upcoming Functionality, from ARIN’s home page. Shortly after the break I think it is we’re actually going to launch the survey on this where we are looking for everybody to go in and give us some sense of ranking and importance of each of these projects awaiting prioritization.

That is what the survey looks like. It’s one page. It’s real easy to fill out, and you just pick No. 1 through No. 9, I believe it is, and provide us feedback on what’s important, what’s most important to what’s least important. And these are the nine: Extended Stats Files, DNS Improvement, Streamline Transfer Service, Member Voting Functionality within ARIN Online, Integration of Internet Routing Registry, Lame Delegation Reporting ‑‑ something we haven’t talked about in a while ‑‑ Additional Test and Operational ‑‑ excuse me, Additional Operational Test and Evaluation Services like including Whois in that, Alternative RPKI‑like Services, and Retrievable Meeting Registration Data.

So the extended stats file is enhanced NRO statistics as agreed upon by the NRO EC for improved reporting to the community. Within the ARIN community we don’t have any context whether this is important to all of you or not. It’s something that the NRO is planning to do, but we’d like to get feedback from the community regarding the importance to all of you.

DNSSEC, we need to ‑‑ we probably need to ensure that those folks using DNSSEC are subject to an RSA, LRSA, and in that, again, we’d like to have some feedback from the community regarding that. Streamline transfer service. Leslie loves this. And that is that our transfers are manual. And it makes it difficult in registration services, and it also makes it difficult for those who actually interact with ARIN to process transfers. They’re not automated in the sense that they probably could be. We’re increasingly seeing transfers. It would be interesting what everybody feels about that and whether that’s important to you.

We also have integration of legacy membership and voting functionality within ARIN Online. That way we maintain your information when you register to vote, and that we conduct all those, conduct the voting, the elections and the entire process through ARIN Online. The only downside of that, something for all of you to consider, is if you don’t have an ARIN Online account, you would actually have to get one to do this. So there’s tradeoffs on both sides of that. And interested to hear what folks’ thoughts are. All right.

Integration of Internet Routing Registry. This appears to be what we think is the next logical step for the IRR, which is to integrate it with ARIN Online, because we manage all the registration data there. And, lastly, lame delegation reporting. Resurrect lame delegation functionality within ARIN Online. If the community recalls, they asked us to do this. We had to stop doing it in order to transition to our delegation model within ARIN Online, and now it’s something that we’re interested to know if it’s still important to the community or not since we’ve been offline with lame delegation reporting for some time now.

Operational tests and evaluation services. So for everybody, we do have an OT&E environment for you to test and use off production. And we’re thinking about adding Whois to that. RPKI‑like services, improvements to RPKI using alternative methods and distribution and signing methods. If that’s something ARIN should at some point pursue, we’d be interested to hear that.

And then retrievable meeting data. Again, this is the ability to ‑‑ once you register for an ARIN meeting, that information is signed rather than having to put it in again each time for each meeting. And that may be a benefit to the community. So, again, we’ll have a survey later that’s going to go out, and we’d like your feedback through that. If you have any questions, please feel free to catch me or any of the ARIN staff if you have any questions regarding the survey or any further details you need concerning any of these projects. And I will take questions. Yes?

Heather Schiller: Heather Schiller, Verizon Business. Can you go back I think three slides? You said how many years have you stopped doing lame delegation reporting?

Nate Davis: Where is Mark? I want to say at least three.

Heather Schiller: And everyone was making a big fuss yesterday about reverse after you try to notify a company? Just saying like if you’re not even telling people that they’re lame for three years, like how many people are really going to be impacted by having it pulled in consequence to having bad contact info or not reassigned?

John Curran: Heather, is that a request to get that one done quick?

Heather: No, I’m just saying like people are fussing that ‑‑ yesterday that it was ‑‑ you even used that you’re hesitant to take action that has an adverse impact in someone’s business. Well, I remember we had all these problems with folks being lame, trying to notify them. No one cared. So I think the percentage of people who are going to care is probably lower than ‑‑ saying that this stick that we were discussing yesterday is probably not as big a stick as everyone is making it out to be.

John Curran: Right. Remember we suspended this because we also had people saying stop contacting my customers and telling them there’s something they need to do. So that’s why we suspended it. If we want to resume it, there’s work to be done given all the changes that have happened in that time.

Nate Davis: All right. Any other questions? Just a reminder, again, yes, a survey coming out probably at the break, and we look forward to folks’ input. Let me, before I finish, give it to Mark.

Mark Kosters: This is to kind of help the audience here understand a little bit more about what lame means and the relevance to reverse. Lame is the case where your servers are pointing to a place where they don’t exist. And those servers who don’t exist can’t answer for you. And that is the thing that lame was actually detecting, was to see whether or not those servers actually worked. In the case of actually taking away working reverse delegations, which was the discussion yesterday, that’s a separate matter and it does have some operations in that.

Nate Davis: So, Mark, question, if I could ask you. How long have we ‑‑ I want to say it’s three years that we have not been doing lame delegation reporting. Is that correct?

Mark Kosters: It’s been approximately three years.

Nate Davis: Yes, okay. Center mic, Heather.

Heather Schiller: I understand that it’s a separate matter, but from a technical perspective, the impact is the same. That’s all I’m saying. That whether the server doesn’t ‑‑ one way or another, you’re not getting an answer back.

John Curran: So, Heather, what I’m trying to figure out is does this mean you want us to get that lame reporting done or not? I’m trying to ‑‑

Heather Schiller: No, I’m not saying anything ‑‑

John Curran: About the lame reporting itself.

Heather Schiller: About the lame reporting itself. I’m talking more in reference to the discussion yesterday about the effectiveness of polling numbers.

John Curran: Got it. Okay.

Nate Davis: Yes, back mic, please.

Michael Sinatra: Michael Sinatra, ESnet, speaking for myself. I mostly agree with what Heather is saying, but I do think there are different issues. If you do DNS badly, you have bad DNS. If you do DNS well, you have good DNS. If you do DNS well and you do bad reassignments, then we’re going to make you have bad DNS. That to me doesn’t make sense. It’s a punishment that makes you lamer than you already are rather than making you better.

John Curran: Okay.

Nate Davis: Good feedback.

John Curran: Let’s take the compliance requirement discussion to the Mailing List where we discuss policy proposals. Okay? Most important thing people need to realize is there’s a long list of things that people have requested; there is a short amount of budget. There’s only so much the ARIN Board would like us to spend and draw down from reserves to also do some of this work. We need to have prioritization so we present those into future budgets in the right order.

Nate Davis: Center mic.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC, speaking primarily as myself and in my role as a professional services agent at Hurricane Electric. We have a lot of situations where IP resource requests are a collaborative process, where different people contribute different parts of the data and you have to meld it all together. That’s easy to do by passing around an email template. It is virtually impossible to have a collaborative process with the current structure of ARIN Online. For building a resource template, it is utterly impossible to have multiple people work on the same ticket the way ARIN Online is currently structured.

We don’t get full‑text email updates, so we can’t easily pass around the results of the template process amongst each other and work on it. And it gets even more complicated when we’re dealing with a resource request that is being done on behalf of one of our customers where we’re doing it as a professional services engagement. I suspect there are other people and other organizations that share my pain in this regard, and I would like to encourage them to make ARIN aware of the need for an email‑based template for those requests on that basis. Thank you.

Nate Davis: Good input. Thank you, Owen. Center mic.

Cathy Aronson: Cathy Aronson, Cascadeo. What he said. We have the same problem with customer collaborative requests. And the fact that there are multiple levels of forms that you have to fill out makes it really hard for them and really hard for us.

Nate Davis: Thank you, Cathy. Center back mic.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire speaking on behalf of myself. I would like to emphasize the limited budget can only do certain things, and continuing with lowest common denominator email templates rather than some of the more pressing issues, I’m concerned that continually the lowest form gets looked at, and I do not consider that to be a good use of resources.

Nate Davis: Thank you, Kevin.

John Curran: The survey will help us understand the view of the community on these matters.

Nate Davis: So, as it turns out, one of the things that’s interesting, in addition to what John mentioned with the budget balances and what ARIN needs to focus on and so forth, is that we have a roomful of people who provide us input directly. There’s typically a number that get up and speak. What folks don’t realize is that behind the ARIN application, if you will, we have 49,000 people that are signed up with ARIN Online accounts. And we have actively at least 5,000 users per month. And so the appeal during this discussion is actually, please, let us know your feedback, because it helps us understand and put things in perspective with regards to all the folks that we have that are using the application.

And the few that are speaking here are on the list and so forth may represent a silent majority, and that’s a question that I’ve talked with staff about and so forth. And we look at RSD, we ask what kind of feedback they’re getting. I ask Mark and say are we hearing about things like this through engineering, our ARIN‑tech‑discuss list and so forth. So, anyways, just again an appeal for getting this feedback to us. Center back mic.

Aaron Hughes: Aaron Hughes, 6connect. I believe last meeting we had this discussion as well, and the suggestion I made was that we should rename the ARIN Online session to something more like development discussion and discuss budgetary concerns in balance with actual needs and not just listen to the squeakiest wheel at the microphone and execute. I believe that disappeared from the agenda entirely and would suggest that it’s still the right forum and not just surveys.

Nate Davis: Good input, Aaron. Let me ask you something. Would that be beneficial ‑‑ are you suggesting that be done at every meeting, or could we do that at one of the meetings per year? What’s your thoughts on that?

Aaron Hughes: Due to the nature of operational impact, I would strongly suggest those are at least the October meeting, two may be excessive a year, but I am certainly in favor of input from both sets of communities.

Nate Davis: Very good, thank you. Anyone else? All right. Thank you very much.

[Applause]

PDP Update

John Curran: Okay. Brief update on the Policy Development Process. We’ve been ‑‑ for more than a year and a half now we’ve been working on a revision to the PDP. We actually sent it out to consultation, the results of the PDP Comm. We had a Policy Development committee. We didn’t get closure. There were some very problematic, little sticky issues. And we’re getting closer.

I’m working with the AC this week, and the Board will be talking about some proposed changes, and then we’ll send it out to consultation probably in a week or two. We have new draft documents. I want to highlight the top‑level changes that we see happening in the Policy Development Process. First, let me talk about the issues. These are the issues that the PD comm highlighted and issues that have come up in the process of revising the PDP. Not clear whether the proposal ‑‑ we’re not clear when and whether the proposal author or the AC controls the policy proposal.

You folks who have submitted policy proposals, sometimes you’re like, well, I want to change it and sometimes I don’t know if the AC is supposed to change it. There’s some interesting questions about that. And it creates a little bit of confusion, because the AC meets on a schedule and the proposal authors may be revising and submitting revised work on a schedule. There’s nothing to say those schedules align or match any particular timeline. Policy proposals can be abandoned by the AC, expressly. Some people have said too expressly. There’s a petition process, but there’s some cases where we’re not even sure we know what the policy proposal is. We have the text. But we don’t know what they were trying to solve.

And so it would be nice if we knew we had a clear proposal. And then if it’s abandoned because it’s not valid, well, okay, it’s abandoned. But let’s make sure it’s at least understandable. Not clear when policies are being presented at a public meeting whether they’re going to be recommended for adoption. This actually has come up, is that policy proposals that are presented, you’re not quite sure whether the AC is going to take them for adoption. The most frequent question I get asked is: Am I going to see this again, is it going to come back to another meeting. To some extent, if the AC is proposing that something’s ready, it’s going to be sent to the Board, that should be identifiable to the room.

And no clear record of consideration of concerns raised. So we have this question of whether or not, when a concern is raised and it’s been considered and it’s been determined, that, okay, it’s a concern, but it’s addressable. You know, a small segment of the community has raised an objection which, in the balance, is decided as worth the risk. We don’t really record that anywhere, and that means that it’s very hard for someone coming after the fact to say, well, I raised an objection, was it considered.

Did you folks actually say you thought about it and decided it’s still worth proceeding? So given those concerns, actually a very light touch set of changes is what I’m bringing to the AC for their discussion, and because they’re the ones who have to turn the crank on a policy proposal process, to some extent they get the first set of feedback. But then as soon as they get their feedback we integrate it, we will send it out for community consultation. So some of the things we’re looking at. First, try to clarify some process issues. Keeping policy proposals when you submit a draft ‑‑ when you submit a policy proposal, keeping it under control of the originator. Because the originator may revise it. He may have new ideas. He may have new issues. So this keeps it under the control of the originator until it’s clear, what used to be a clarity in understanding process. Once the shepherds and the originator agree it’s clear, it becomes the AC’s and it’s a draft and it’s no longer under the originator. We want you to work with the originators, if they’re available.

But the point is there’s a very distinct handoff between this is going into the process and now this is in the process and owned by the AC. And I think that would help understand. We also want the shepherds to be charged at the beginning of the process with actively getting a clear policy proposal. Okay? Even if you don’t think it’s a great idea, it would be good to at least get it clear, make sure you have a clear problem statement and some clear problem text, and then once it’s clear and it can be considered by the community and everyone’s looking at the same thing, then it’s time to weigh in on the technical merits and whether it’s fair and all those other issues. And then we want to bring the Draft Policies to the meeting. It’s possible that a Draft Policy will come to the meeting and it will only need ten minutes, because it’s in the middle of extensive revision.

But one of the big things that ties the AC up is trying to decide: Do we bring this to the meeting or do we not bring it to the meeting. If they don’t bring it to the meeting, the questions come up of where it is anyway, so we might as well take all the ones that are clear and are being worked and have them all on the agenda, even if it’s only for five‑minute update, to let you know by the shepherds what’s going on with the policy proposal. Revised PDP attempts to clarify the policy documentation issues. And so what that means is sometimes we have people who write policy text and then write the rationale that’s sort of the problem they’re trying to solve. We have some people who write a problem statement and then write the text. Then they try to always have a problem statement, here’s what’s wrong with current policy and here’s the text that proposes to change it.

And if we can get that to a common format, that’s what happens in a lot of other RIRs, that will help you guys in looking at these proposals as they come in. And then regarding documentation, getting the AC to say we considered this, we considered these other views, we consider it worthwhile, getting the AC to document why it is that the concerns raised are considered on the whole worthwhile or not worthwhile. And this may take a little bit of work, but it gives us a better record of what we’re doing. It makes sure that if the policy text changes significantly, people know they have to go back and update this to make sure you’re actually talking about the policy proposals that will be ultimately recommended to the Board. So what do we end up with? We end up with a process that has a couple of states for the policies.

Policy proposals are we’re working with the originator to understand the problem as they see it, their proposed solution, and make sure it’s clear. It’s up to the originator to get text that the shepherds consider clear. And once they do, it’s in the process. Draft Policies. We have a nice clear problem, we have clear text, and we would like to hear discussion about it. This is the same old process we know today. Give feedback, good and bad, whether it’s unsound, whether it’s unfair, whether or not no one needs it, and the AC does the same job it always does. And then things that come here as recommended Draft Policies are the AC’s thought all about that. It’s gotten input on that. And based on the input so far, it is fair, it is technically sound and it is supported and they intend to recommend it at the end of the meeting based on the feedback, obviously, based on their learnings, they want to recommend that for adoption.

So this is a very high level. And people can say, well, I don’t really see what’s changing. It’s changing. If you’re an AC member you can look and say I see what’s changing. I’m going to walk through it with them later this week, and then we’re actually going to walk through the drafts, the actual changes, and those will get sent out to the list, but directionally I wanted the community to understand what it is we’re trying to do. And I’ll take questions. We have time for questions. Yes?

Aaron Hughes: Aaron Hughes, 6connect. One thing I didn’t see up there that I would suggest adding in the same spirit is to have the staff assessment be after text is agreed upon by both the shepherd and the originator so as to not double the staff effort.

John Curran: Yep. That’s actually something we’re going to talk about, yes. Rear microphone. Jason.

Jason Schiller: Jason Schiller, Google, NRO NC. Could you go back a few slides to where you talked about what will be discussed in the meeting.

John Curran: What we discussed in the meeting.

Jason Schiller: I think you had a slide that said text that’s not yet a Draft Policy proposal will be discussed and it might only be a five‑minute update.

John Curran: So it’s the question is what is part of the policy process and what isn’t. Draft Policies are going to get discussed for advancement, recommended Draft Policies. If you want to talk about policy proposals in this meeting, we can set up BoFs and we’ve talked about how to give the AC slots to do that. The only concern is to recognize the originator is still changing the proposal. So you don’t want to put too much time into it until at least everyone’s agreed here’s the problem you’re trying to solve.

Jason Schiller: So I think one of the processes that I’ve seen in other communities is to have this kind of workshop time where people can get together and actually as a group craft and refine text and get cleaner, concise text that everyone is comfortable with.

John Curran: Right. Hopefully the shepherds and the originator can do that. But they should also be able to ask for a workshop and have time here. We started that a little bit with the lunch table topics, but we think it’s quite fair for the AC to say we want a 30‑minute workshop because we’re going to work on this with anyone who is interested.

Jason Schiller: Okay. I was reading something different in the slide that’s not there. Thank you.

John Curran: Okay. Yes?

Sam Weiler: Sam Weiler, SPARTA. I’d like to see the Policy Development Process less dependent on these physical meetings. While I think the key to that is getting more meaningful dialogue on the mailing list, I think in the process we also need to take the meetings out of the critical path. And I hope that you’ll look at doing that as you’re doing these revisions.

John Curran: So actually you’re ‑‑ I didn’t put you up to saying that. But I could have. We are making the process independent of the Public Policy Meeting, but we’re allowing the possibility that the Public Policy Meeting is one way to review that you’ve got consensus, but at some future time we might do it as an online poll, if you had a sufficient online poll. Another way it might be done is we might actually have a consultation at someone else’s meeting. You could imagine us using a slot at a NANOG meeting to do a policy consultation.

So the process is while it does say you’ve got to be able to show that you had a simultaneous discussion, not email, a real simultaneous discussion and you had the ability for questions and answers, there’s nothing to say that even that a few years from now might not be an interactive online WebEx or hangout. So we’ve tried to lead towards that path, obviously actually making use of that has to be when the community feels comfortable with those kind of things. Thanks. Yes? Mr. Darte.

Bill Darte: Bill Darte, ARIN AC. Could you go a couple of slides forward again towards the end of your presentation. So what I hear oftentimes is that proposals that don’t end up on the AC’s docket, we abandon them for some reason, there’s no visibility into why that happened or whatever. So, I mean, this ‑‑ I don’t know whether you want to speak to it now, but it’s clear that a lot of people think that when a policy proposal, clear or ‑‑ assuming clear under this is abandoned by the AC, that that somehow gets published in some detail and all the considerations of why that was abandoned, wasn’t advanced to a Draft Policy status, is important. Will new PDP cover that as well?

John Curran: So in the revised policy proposal, the goal is to work with the originators to get it on the AC docket, not to reject it. The only reason you should be rejecting it is someone submits their shopping list as a policy proposal, or they submit a policy proposal that has nothing to do with Number Resource administration and it’s out of scope. To the extent that someone’s rejected in the policy proposal phase, it actually is a big issue. Meaning, if they petition it, it isn’t even an AC petition, it goes to the Board of Trustees if successful. We shouldn’t be rejecting things that we’re trying to clarify and improve; things should become a Draft Policy and then the technical discussion. The fairness discussion should start. Okay. That concludes the presentation. I thank everyone. We’re going to move on at this point to ‑‑ yes, Scott?

Scott Bradner: Scott Bradner speaking as someone who has worked on this particular issue quite a bit. I would ascribe more intelligence to the AC than this last little bit seems to. If somebody comes to ‑‑ makes a policy proposal which is against ARIN’s principles, I want the AC to be able to say it’s against ARIN’s principles and should not see the light of day and explain that, but I don’t think that the AC should be told that they have to hold their noses and put something out that they think is wrong.

John Curran: Fully agreed. But the rejection should be for a reason that’s understandable. So the next thing up on our proposal is the Draft Policy block. I’m going to double‑check. Yes, we are in the Draft Policy block. First policy proposal up for policy consideration is ARIN‑2012‑3: ASN Transfers.

Draft Policy 2012-3: ASN Transfers

John Curran: And the ASN Transfers history of the policy proposal started as ARIN Proposition 157 in September 2011. AC shepherds, Scott Leibrand and Bill Sandiford. AC selected as Draft Policy in March 2012. Current version is the 14 March 2012 text. The text and the assessment are online and in your Discussion Guide. Summary. Allows organizations to transfer ASNs in addition to IPv4 address space in the 8.3 Transfers to Specified Recipients section of NRPM. Status at other RIRs. No similar proposals or discussions.

Staff comments, issues, or concerns. If implemented as written, the 24‑month utilization requirement in 8.3 would not apply to ASN requests since 8.3 clearly says “how the addresses will be utilized.” Staff would apply the current ASN policy which requires an organization to be multihomed or to immediately become multihomed. Resource impact minimal, three months. Really not hard to move ASNs. Legal assessment. This creates no concerns and may actually facilitate bankruptcy proceedings when ASNs are involved. PPML discussion. 56 posts by 23 people. Three clearly in favor ‑‑ six in favor and three against in 56 posts.

Some sample comments. “Adopting this policy will allow ARIN to get out of the way and legitimize what’s already transpiring on a regular basis. It’s a good thing.” “I think we’re seeing enough problems created by allowing transfers with IPv4 that unless there’s a truly compelling argument for doing this with ASNs and none has been presented we should at the very least hold off on expanding to ASNs until such time as we sort out the issues with IPv4 transfers.” “I support this proposal and would suggest that just as it specifies IPv4 in the 8.3 text it should specify 2‑byte ASNs.” “So what I’m hearing the RPKI experts say is that ASNs at least from some point moving forward might actually need to be eternally unique, and that in all cases of mergers, acquisitions, or bankruptcy, ARIN should issue a new ASN in exchange with some period of overlap in order that reputation is not migrated.”

This discussion did move a little bit into use of ASNs and routing and resource certification. Okay. That is the introduction of the policy. At this point I’ll invite Scott Leibrand up to give the AC presentation.

Scott Leibrand: Good morning. This one is a fairly straightforward proposal with a few implications. So I always like to start with the problem statement as John outlined in the PDP that kind of sets the basis. There are obviously organizations out there that would prefer to have a low‑numbered ASN to a high‑numbered ASN. I think we’re in the 40,000 range right now for newly issued ones, for purposes of, for example, doing peering. So there’s some demand for that kind of thing. And it’s currently not being met, except either via mergers and acquisitions or if you already have an ASN. There are organizations that have ASNs that they’re not using. I haven’t counted the number in the table, but it’s a lot less than 40,000.

So this proposal is very simple. We add two words to the NRPM. We add “and ASNs” to what we can transfer under 8.3. Why? What would it do for us? So there are ‑‑ like I said, organizations would like a low‑numbered ASN for various reasons. It’s more memorable. It’s a lot easier for your peers to remember. It’s easier to type into the routing config and not typo. As Owen pointed out, they liked to typo my ASN when I was at a former job because it had lots of repetitive numbers, so it’s memorable, but not very easy to type without errors. If it were a three‑digit ASN, that would be less of an issue.

There is a possibility that we may exhaust the 2‑byte ASN pool, and there may still be some legitimate technical demand for 2‑byte ASNs, in which case this would address that. I don’t know how big of a benefit that will be, but it’s a possible benefit. There are states that ‑‑ as the legal comment said in the staff ‑‑ or legal assessment that have ASNs involved, and under current policy those are not allowed to be transferred. Bankruptcy courts like to transfer what they consider assets, and, in my opinion, we are treading dangerously if we have policy that conflicts with a court order. That sets bad precedent for a lot of other things, and we’ll probably hear some discussion about that later.

There have been some drawbacks highlighted on the mailing list discussion. A lot of those concerns center around the thought that ASNs have reputation, whether it’s an informal reputation or a technical one with the RPKI concerns, and that those ‑‑ that transferring those ASNs may allow an organization to get someone else’s reputation and do something bad with it. There are more general concerns that IPv4 transfers haven’t had enough time to work themselves out. We still have potential issues with that, and there are people who want to wait on doing ASN transfers until those issues are addressed. And there are questions around whether this is a pony.

So we already saw the staff and legal assessment. I just want to comment on the first ‑‑ on two items. Yes, that’s exactly what we intended in terms of 24 months has nothing to do with ASNs. That applies to v4. So the staff interpretation of that exactly matches the intent as I can see it. And to reiterate what counsel said in the comments, I think it more or less speaks for itself. So it’s time for discussion. So when you come to the mic, please state your name and affiliation and if you are for or against the policy proposal as written. Geoff.

Geoff Huston: Geoff Huston, APNIC. I’m actually neither for or against the proposal, but I’m kind of wondering what the role of the Atlantic Ocean has to do with this. Over there somewhere to the east is Europe. Right? Remember that? And over in Europe they manage to advertise 1,516 4‑byte ASes. Even the folk down south of this continent, if you go south you find South America, and you also find 522 4‑byte ASs. Over in Asia‑Pacific, 191. Even AFRINIC does five, and you guys manage a phenomenal 19. Is it something in the water?

[Laughter]

Geoff Huston: Maybe it’s climatic. I always thought we had the same routing equipment and the same operating support systems, so I’m kind of curious as to exactly what the environmental factor is. And I’m beginning to blame the Atlantic, but I’m just not sure.

[Applause]

Geoff Huston: Just to give you stats here, though, currently we’re going to run out the 22nd of March, 2014, at our current rate. There’s actually 3,023 left in the IANA pool. So it’s not a great urgency problem, and, as I said, quite frankly, the rest of the world doesn’t see it. To put some more numbers here, we see 38,451 2‑byte ASs in the routing space, of which half as well, 16,394, are unadvertised. So you’re right; there’s a large pool of unadvertised addresses. But I just don’t understand why this particular part of the world is so special. And that’s just got me completely beat. Thanks.

Scott Leibrand: Kevin, I think you could talk to that.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on behalf of myself. I didn’t want to talk about ponies or lipstick or anything like that. What I did want to talk about is the North American perception of 4‑byte AS holders having rabies, is probably the closest that I could think of it. But I’ve talked to a number of peers through other roles who have said they got a 4‑byte AS and then nobody wanted to peer with them. Why? Well, because we can’t get NetFlow data from who you are and see how much traffic you have, or our systems don’t support it, or it’s Wednesday and we’ve decided that we just don’t like new entrants. Well, how can you tell I’m a new entrant? Oh, I’ve got a 4‑byte AS.

The reality is we have a ton of unadvertised, as Geoff mentioned, 2‑byte ASs. There’s no reason operationally to ‑‑ there are minimal reasons operationally, but sometimes operations in politics are strange bedfellows when it comes to peering. So we have these unadvertised ASs. My suggestion is to change the wording to include the word “2‑byte,” to add an extra word, to make it 2‑byte, because I don’t believe there’s a necessity for 4‑byte. But while there is this wonderful unallocated pool that nobody is going to get back, because why give it back when it’s just been sitting there and it’s costing you nothing, so if we can get back to people who want it, whether there is a specific technical need or not, I don’t see a problem with that and I fully support this proposal.

Scott Leibrand: Owen, and then a remote participant.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC, speaking primarily as myself as an individual member of the community, though I will say Hurricane Electric will gladly peer with 4‑byte ASNs and has 4‑byte ASN support throughout the globe. This policy strikes me as the potential to be yet another great mistake of the Internet. We held our noses and we implemented NAT when we all knew NAT was ugly, but we needed to do something to make IPv4 last long enough to implement IPv6. And then as a result we failed to implement IPv6 for a very long time. And now we’re rushing to do it when we’re again running out of v4 addresses on a much shorter timetable. We held our noses and we implemented IPv4 transfers because we had to do something to make IPv4 last long enough so we could implement IPv6.

The rest of the world has managed to implement 4‑byte ASNs, and now we’re talking about holding our noses and implementing ASN transfers because we have to do something to deal with the fact that we’re too stupid to get 4‑byte ASNs working. How about we just get smarter, get 4‑byte ASNs working, and don’t make another great mistake of the Internet. Thank you.

Scott Leibrand: Remote participant.

Bill Sandiford: Yeah. Chris Grundemann from CableLabs and the ARIN AC states that he’s neither speaking for or against at this time, but says: We should weigh the necessity for this policy against the known and as‑yet unknown dangers associated with the paid transfer of Internet Number Resources. As you consider this policy change, please ask yourselves is there enough need for the transfer of ASNs to mitigate the risks involved.

Scott Leibrand: Thank you. Mr. Ryan?

Steve Ryan: Thank you. Steve Ryan, ARIN general counsel. I’m not speaking for or against the policy, but I have to provide a data point. There is currently a bankruptcy case pending where there’s a potential contract to transfer an ASN that makes it a live case in controversy and takes it from being a theoretical issue for bankruptcy courts to an actual issue. I’ve managed to delay briefing that case, and the court wants to cooperate with ARIN’s policies and has on other occasions, but we now have an actual live case for controversy. So, from a lawyer’s standpoint, it’s more convenient if you pass this policy, and I simply wanted the community to know that; that there’s an existing matter there. But we’ll deal with it either way. If you do it or you don’t do it, we’ll still respond appropriately.

Scott Leibrand: Thank you. I believe Mr. Bradner was next.

Scott Bradner: Not speaking for or against the policy as a Board Member, but I will note that the only downside I can see is that Bill Woodcock might have to withdraw some T‑shirts.

[Laughter]

Scott Leibrand: Marla?

Marla Azinger: I speak in favor of it. I understand the plight to get everybody to do the next best thing. But there are downstream customers that aren’t going to do the next best thing for a very long time, and that’s going to break your connectivity with them and you’re going to have issues and the NOC is going to be pissed. So there’s more to it than just that we’re slow minded in some areas. But it’s just reality. And there are other entities that want ASNs of that certain type, need it, can use it, but they actually can’t justify it because there might be internal battles within an enterprise that they can’t cough up the required information that the RIR is asking for.

And while that sounds like a pissing contest that an entity needs to solve on their own, it is, but at the same time that’s also why this requirement is sitting up there in front of everybody today, because there are a lot of different scenarios that exist that you probably never would even imagine exist but do that make this requested.

Scott Leibrand: Heather?

Heather Schiller: Heather Schiller, Verizon. So the 8.2 Transfer Policy from mergers and acquisitions does say number resources. So it’s my understanding that ASNs can be transferred as part of a merger and acquisition. And I think that that likely covers the majority of cases where the transfer is in order to minimize disruption on customers or because the entire network is being transferred or moved. So I think the majority of ‑‑ I think how this is going to get used is more for people who want a particular low ASN or vanity ASN, or whatever the case is, and so I don’t feel that that’s ‑‑ it’s not as much of a technical reason in order to maintain a particular network. So I’m not in favor of the policy.

Scott Leibrand: Thank you. Bill?

Bill Sandiford: Bill Sandiford, ARIN AC, speaking for myself. I am in favor of the policy. I’m not of the belief that this is people’s ‑‑ this policy is people attempting to dodge 4‑byte ASNs, because there’s no real reason to dodge it. It’s literally what’s been identified in Scott’s slides, some people just want lower ASNs, easier to number, easier to remember ASNs, and I don’t see a lot of damage being done by allowing this.

Scott Leibrand: Thank you. Marty?

Martin Hannigan: Martin Hannigan, Akamai Technologies and elected Advisory Council member. I’m going to speak not for the AC but in that capacity. I’m the author of this proposal, and the reason ‑‑ the motivation for me to put this forward was that a few people in the peering community came to me and said that they wanted to do some ASN transfers and it wasn’t clear to them that they could do it legitimately using ARIN policy, and, hence, we have this proposal here in front of us today. It has nothing to do with 4‑byte ASNs.

That was never a consideration in writing the proposal. I had a few questions related to the drawback, if you could back up to your slides. RPKI concerns, I think that’s valid. But I guess I need to understand what are those concerns, because saying that they may need to be unique in the future sounds like a red herring to me. My understanding is ‑‑ and please correct me if I’m wrong because I’ve had this understanding for a while ‑‑ that not only when staff does their assessment related to policy that if there was a security issue, they would probably raise a red flag there as well. I did not see that in the staff assessment.

John Curran: So someone who decided to transfer their AS number would obviously need to understand the implications of doing that with respect to resource certification. There’s no way we could warn someone, because that may be exactly their intent. They may be acquiring a company or something. But it’s only a concern to the extent that a party can do a transfer without the authorization of the ASN holder. And that isn’t a security concern; that’s a much larger concern on several fronts. There was no staff comment because it’s obvious that a party who transfers the ASN would have to understand the consequences of it.

Martin Hannigan: True. And, again, I just want to underscore that point and say that as far as the technical concern goes, I do not believe that one exists. But I am not an RPKI expert. And if there is one in the room, I wouldn’t mind being supported or shout it down.

Scott Leibrand: I believe there’s an RPKI expert trying to clear his throat. Go ahead.

Geoff Huston: Geoff Huston, someone who lived about five years of RPKI. There actually aren’t any RPKI concerns. With all due respect to Mr. Curran, it’s actually the other way around. It’s not that the AS number holder authorizes the prefix, it’s the prefix holder authorizes the AS. So, in actual fact, no, it’s not a great ‑‑ it’s not a concern. RPKI is designed to reflect today’s reality. So, in other words, if there’s a registry change, there’s a certification change. If you were a number resource ‑‑ AS number holder and you went and disposed of it, the RPKI certificate you get left with doesn’t have that AS. Anything you signed about that AS doesn’t validate. It all just works. That’s not really a concern here.

Martin Hannigan: The second point I wanted to address was the one related ‑‑

Scott Leibrand: John, would like to respond?

John Curran: Meaning that they would have to authorize the transaction of selling his ASN, not authorizing routes per PKI. My use of the term “authorize” was obviously an ASN holder has to know if he’s transferring his ASN and authorize ARIN to do so.

Geoff Huston: One would have thought that the transaction couldn’t have occurred without knowledge.

John Curran: It actually doesn’t until we do.

Scott Leibrand: Okay. Marty.

Martin Hannigan: The second point I wanted to address was the reputation comment. I do believe that’s a red herring as well. But the important bit here, which didn’t get into the slides, and you did ask for feedback ‑‑ I’m sorry I wasn’t able to get that to you; I’m not trying to kind of throw a bomb into your presentation ‑‑ but the Whois component is probably the most important for the reputation, and what’s happening in the community now is that, well, let’s speculate that something like this may be happening.

You have a low number ASN. I want it. We can’t get it through the ARIN process, so I just borrow it from you. The Whois isn’t accurate and it stays that way for a long time. I think this is also ‑‑ if we are concerned about Whois reliability and accuracy, this is a proposal that actually underscores that. Thank you.

Scott Leibrand: We have two remote participants. Let’s do one of them now.

Bill Sandiford: Okay. Leif Sawyer from GCI: Slightly in favor. Providing explicit legal guidance is much more preferable to not having any guidance at all.

Scott Leibrand: That was short. Let’s do another one.

Bill Sandiford: Joe Maimon from CHL supports the policy: The potential benefits are clear, if hard to understand, for the technical folk among us and the potential disadvantages are not. I don’t believe in using runout as a tick to drag a community in the direction you want to go.

Scott Leibrand: Thank you. Kevin?

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire speaking on my behalf. I already said earlier I support this. One initial comment: This is not the same as IPv4/IPv6. In IPv4 and IPv6 there is no compatibility between the two. With 2‑byte/4‑byte there is compatibility between them. So there is no need to race towards going to all 4‑byte, because 2‑byte and 4‑byte will co‑exist with one another happily unlike IPv4 and IPv6. That was the first comment. The second thing was, and I just wanted clarification from ARIN staff, ARIN at some point switched to giving out 4‑byte ASs as the de facto standard for a little while, and that stopped very quickly. Could you talk to that for a minute? Because I think that’s very important to this.

John Curran: I think Leslie addressed it earlier, but I’ll repeat it. We did change. Instead of giving out intentionally 4‑byte ASs, we give out ASs based on the pool we have starting at the lowest. So right now ‑‑ is that correct, Leslie? ‑‑ we give out ‑‑ so right now, as we have still 2‑byte ASs and they’re in our inventory, we’ll give them out. At some point we won’t have any and it will go back to 4 because that’s all we have.

Leslie Nobile: I want to add one thing. We did this due to a policy change. That was why we made the decision. The policy said we’d issue from one single pool, one undistinguished pool. So we chose to start with the lowest to the highest, which means 2‑bytes first.

Scott Leibrand: Thank you. Geoff, are you in line?

Geoff Huston: Yes, Geoff Huston, APNIC. I’d like to just talk to those of you who seem to be suffering from short‑term memory loss and having a hard time remembering these really long AS numbers. We actually had this precise discussion with your technical counterparts over at the IETF and actually presented them with two drafts as to how to write these numbers down. And one of them was to write down two very short numbers connected by a dot, and the other one was to write down a very long number. Your technical folk appear to have better short‑term memory than you have, and they actually decided they wanted big numbers. You can have it both way, folk. You’re left with big numbers. If you can’t remember it, write it down. Thank you.

Scott Leibrand: Remote participant.

Bill Sandiford: All right. So there’s two here.

Sandy Murphy from SPARTA has a query intended for people using routing history for lots of reasons, wants to know will ASN transfer confuse routing history analysis. And Joe Maimon wanted to add to his previous comment to say: As an aside, with regards to the mystification on our region’s nonuptake of 4‑byte ASNs, I believe that a combination of lack of self‑interest, incompetence, piles of legacy equipment and configuration, stodginess, and we don’t care. We don’t have to; we’re the phone company.

[Laughter]

Scott Leibrand: Thank you. Bill?

Bill Woodcock: As someone who does a lot of routing analysis, I know that we and a fair number of other people use the AS number as a key sometimes in looking at who an organization that holds address space is. So Sandy’s point is a good one. I’m not sure that the tail should wag the dog in terms of routing and analysis driving operational policy.

Rob Seastrom: Can I speak to that? Rob Seastrom, ARIN AC. I will note that we have an existing record of reusing ASNs. How do you accommodate that now?

Scott Leibrand: Is that a question for Bill?

Bill Woodcock: So the issue is you’ve got mergers and acquisitions that happen already. You’ve got organizational name changes. You’ve got address blocks that sort of get transferred around. So far the AS numbers have been among the most stable characteristics. This is the real world. You can’t accurately depict the real world in a simplified model, like in a database, but there are people who try. And those people’s work has value, but, again, I’m not saying that we should try and simplify the world in order to make models easier to make.

Rob Seastrom: I’m just pointing out that we don’t need to look any further than the back of your shirt to say that ASNs are unsuitable for a primary key.

Bill Woodcock: I know that. I’m saying there are people who do that and that there is not necessarily a better key in the real world and that probably shouldn’t be a significant input to our policy‑making process.

Scott Leibrand: Thank you. Owen?

Owen DeLong: Actually, I think I’ll defer to Paul.

Paul Vixie: So the default is we don’t have the ability to transfer ASNs. If someone thinks we should never have the ability to do this because, for example, to think that long‑term stability in the numbers is good or because tough‑love forcing people into the 4‑byte ASN thing is good, I would recommend that such people start a policy process on that basis to make sure that you lock the language down. The actual argument that’s being made here is there’s no particular reason ‑‑ it was not intentionally left out. We didn’t think that we wanted 65,000 networks ever. We just sort of never ‑‑ it never occurred to us that somebody would want to transfer this. And that’s why it’s not in the language. And so it’s just ‑‑ it’s being offered as an improvement.

All of the arguments I’m hearing against it amount to arguments which are not present in the text of the NRPM today. So I’m a little bit concerned that we’re passing like ships in the night here.

Scott Leibrand: Thank you. Owen?

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I think that when it comes to this policy ‑‑ I don’t agree with Paul that not allowing transfers of ASNs was an oversight in the development of policy. I think that we allowed transfers of ASNs specifically in the case of mergers and acquisitions, and I think that that’s deliberate. And we allow the transfer of IPv6 addresses in the cases of merger and acquisitions, and we’ve traditionally allowed the transfer of IPv4 addresses in that case. We had a lot of discussion of what we did or didn’t want to allow in transfers when we developed Section 8.3 of the NRPM, and there was a great deal of debate about this and it was carefully considered and we specifically chose to limit it to IPv4 addresses intentionally. And that language is in the NRPM.

So to argue that the arguments against this have nothing to do with what’s in the NRPM, I don’t think it’s entirely valid. We have only gotten two reasons that people think that this policy is a good idea. One is because we feel like transferring ASNs and we think we can make money at it or whatever. And that’s all well and good and everybody wants their pony, and I understand that. But it’s a pony. And it doesn’t really have much else behind it.

And the other one is, well, we think 4‑byte ASNs are icky so we want to get 2‑byte ASNs, and that’s the only argument that I see that isn’t really a pony. And as someone has pointed out who is in favor of the policy, 2‑byte and 4‑byte ASNs are compatible and we’re not pushing everybody to go to 4‑byte ASNs; we’re just sort of saying, well, when we run out of 2‑byte ASNs we’re out of 2‑byte ASNs and people should be making 4‑byte ASNs work with their networks whether they have a 4‑byte ASN or whether they’re peering with a 4‑byte ASN and it shouldn’t really matter and you can ‑‑ even if you have equipment that doesn’t support 4‑byte ASNs, you can peer with AS 2, 3, 4, 5, 6, and it pretty much just works. Even if your equipment doesn’t support 4‑byte ASNs, it gets carried into an extended attribute and the process works. There’s a video up on YouTube that I made if you want to understand how that does.

So I don’t really see a technical benefit to this. I don’t see a benefit to the community from this policy. I see a benefit to a few people who want to transfer ASNs and they get their pony in and they get their low‑numbered, memorable ASN or whatever, but we’ve traditionally said no, that’s not something we as a community want to do. We said it with IPv4 resources, we said it with IPv6 resources and we said it with ASNs, and now we’re talking about reversing that.

Scott Leibrand: Thank you. We have a remote participant next.

Bill Sandiford: Sandy Murphy from SPARTA wanted just to respond to the answer to Bill’s question saying they were not suggesting that ASN transfer process be impacted by routing history analysis. The question was really a backwards way to get into the question of whether ARIN would maintain a history of transfers that could be used for analysis.

Scott Leibrand: Thank you. I believe center mic, Jason, was next.

Jason Schiller: Jason Schiller, Google, NRO NC. I want to address two points that Owen just made. The first one is kind of the reason that compelled this community to consider transfers, specified transfers for IPv4, and that is depletion. And I think this community is well aware of how depletion is ongoing with IPv4 addresses. But we also have depletion of 2‑byte ASNs. And I suspect this community is less aware of how that is playing out. I was wondering if ARIN staff could comment as to when they think the 2‑byte ASNs that ARIN is holding will be depleted.

John Curran: Can I ask: How does that help with this policy proposal? How does it help you decide one way or the other? That’s what I’m trying –

Jason Schiller: It goes to timeliness of when we should implement this if you think the reason we should implement this is because people can’t use 4‑byte ASNs and they can use 2‑byte ASNs and they think a transfer market might be a place to get them once ARIN depletes its stock of 2‑byte ASNs.

John Curran: We are presently recovering 2‑byte ASNs as well as issuing them. Because we’re recovering them at approximately the same rate right now as we’re issuing them, our net burn rate of 2‑byte ASNs is very hard to measure, and therefore depletion date extrapolating it is next to impossible.

Jason Schiller: Thank you. Useful information.

Scott Leibrand: I believe we have Scott, then Rob, then Heather ‑‑

John Curran: Jason, now that you have the useful information, are you in favor or opposed to the policy?

Jason Schiller: I’m neither in favor nor opposed.

Scott Leibrand: Thank you. Scott?

Scott Bradner: Scott Bradner speaking as a memory aid. Owen just said that there were two reasons that have been expressed. He seems to have forgotten that we paid a lawyer to be here and he expressed a reason. We are faced in the immediate future with a legal case where it will get very sticky if we can’t do this. That at least should be part of the discussion.

Scott Leibrand: Thank you. Rob?

Rob Seastrom: Scott provided a very nice introduction to what I was about to say. This is Rob Seastrom, ARIN AC and Time Warner Cable. It is a core tenet of more than one martial arts discipline that one does not engage force directly but rather flows with force. And there’s a huge difference between telling US bankruptcy court no, you can’t do this, sorry, have a nice day, and saying yes, you can do this, we’re trying to accommodate you, do this according to the following set of specifications. And I think that for that reason alone we really need to give this strong consideration. I think it would be a huge waste of time and effort to force a showdown over something small like this where we can accommodate in some way.

Scott Leibrand: Heather was next.

Heather Schiller: Heather Schiller, Verizon. I really should not stand so close to counsel. So in reference ‑‑ I really don’t want to address that part. So I’m going to sound Pollyanna‑ish when I say this, but I feel like this is a really important decision, because it’s a turning point in how we view resources. If they’re a community resource that ARIN is the steward of that you borrow for a period of time while you need it and you return it when you don’t and it gets reallocated to someone else, then we should leave the text alone and not make this change. And if it’s a resource that you have the right to monetize and profit from, because you want to, because you did something early on, because, for whatever reason, then make this change. Because I think what the impact will be, what we’re telling the community, is how to use and be responsible with the resources that they’ve received.

Do you hold on to it for some period of time until you can potentially profit from it and maybe people will decide that they want to do that with v6 space, although it’s huge, but, still, or do we want to foster that sense that it’s a community resource and you’ve borrowed it, used it, and you return it when you’re done. And I feel like the latter is the behavior that we want to encourage.

Scott Leibrand: So you’re saying you’re opposed to this?

Heather Schiller: That’s the reason why. And with respect to the court case that I know nothing about it and I’m not saying necessarily I want to, but if the reason ‑‑ if part of the bankruptcy proceeding is that there is one entity is acquiring the network of another entity, then the existing 8.2 transfer with merger and acquisitions should be sufficient and you shouldn’t need this in order to support that.

Scott Leibrand: John.

John Curran: Heather, I’m fairly well aware of ARIN policy. And obviously if one was acquiring another through a bankruptcy, we would direct them towards 8.2. But bankruptcy judges want to make sure that they get the maximum return for the estate, and sometimes that means different pieces go different ways. And we have seen cases where the ASN is considered something of value and that there are parties that need an ASN and would prefer to get one from an estate that has a particular low number or pattern, or whatever, than get one from ARIN. So what we’re indicating is that obviously we’re going to do what the community tells us to.

If we say no, that’s not the way ASNs are treated, those should be returned to ARIN, and then we will do that. And if the community says yes, allow those types of transfers because they put those ASNs back in use, we’ll follow that. But we’re specifically seeing now circumstances where people do want to do transfers to someone who does need an ASN, and we need the community guidance on it as to whether or not to consider that in 8.3.

Scott Leibrand: Thank you. I believe Bill was next and then back ‑‑ Heather, go ahead.

Heather Schiller: So my understanding is that the legal argument in prior cases, particularly Kremen, had been that IP addresses and number resources were like credit card numbers; that your right was to the use of the resource and not the particular number.

And I think in ASNs we’re making a change. We’re saying no, the actual order of those numbers, specific numbers in the AS, are valuable. And that’s a change.

Scott Leibrand: Steve.

Steve Ryan: You’re not correct. What we have always said in every court, not ‑‑ I’m not going to talk about any singular litigation, is that when we issue resources or if they were legacy‑issue resources that are being managed by the ARIN region, that people have the exclusive right to use those resources that is exclusive to all other people. It is not an ownership right, but it is the exclusive right to use and there is value to that exclusive right to use. And 8.3 recognizes that exclusive right to use that people can give up and provide that exclusive right to someone else who qualifies.

So all we would be doing is following the same legal theory for this policy if you approve it. If you don’t, then there will be an interesting question. And the interesting question is a bankruptcy court that has cooperated with us on 8.3 transfers will have to understand why the community did this, and the court will rule in whatever way it thinks best consistent with the bankruptcy statute, which is maximizing value to the estate to pay the creditors. Under those circumstances, the theories that we have will be evaluated by the court, but the court is used to a Ford LTD being the asset. And the judges are generally older people, generally.

For them to get their head around other theories is always exciting for them and interesting. Actually, when we go to bankruptcy court, judges perk up. They like dealing with us, because it’s sort of interesting. That said, I want to be careful when members of the community get up and say something like that, particularly someone who comes to the meetings. I just want to make sure you have the proper understanding. It’s that exclusive right. It is the right, by the way, that your company ‑‑ and I’m not going to talk about “your company” in the singular to each of you ‑‑ your company has that exclusive right to use compared to all the other companies in this room. And that is what our registry defends. And that is what is the seminal issue of value that the registry provides.

Scott Leibrand: Thank you, Steve. Bill was next.

Bill Sandiford: So I originally had one for myself, but Scott and Rob covered it. But in the meantime there’s been a remote participant. So Chris Grundemann, CableLabs, ARIN AC. I think this is specifically directed to you, John: Couldn’t ARIN supply a new free ASN when a transfer of Number Resources occurs rather than transfer the old ASN?

John Curran: That’s a question to staff. The answer is yes, we obviously could issue a new ASN. But if the ASN number they want is that particular pretty one of a certain number of digits or certain pattern, then us issuing a new one as if they requested a new one doesn’t meet what they’re looking for.

Scott Leibrand: Thank you. Michael was next.

Michael Sinatra: Mike Sinatra, ESnet, speaking for myself. That goes back to Heather’s, I think, very good point that it’s not the exclusive right to use an AS number, it’s the exclusive right to use a particular AS number that I want to use. And that isn’t something that plays ‑‑ I don’t think it plays very much in IPv4 address transfers, although maybe it does, but I think that is different from the way that we have, at least in the community, interpreted policy. That may not be the way that counsel sees it. But I think that is different from the way we’re interpreting policy. Beyond that, I just want to say that I agree a lot with what Heather said, I agree a lot with what Chris Grundemann has said, and I don’t know what’s going to happen. I don’t know whether it’s going to be worse not to adopt this policy or worse to adopt this policy.

At some point we are going to fight with the courts. The question is are we going to fight with them now or later. Is this important enough to fight over?

Scott Leibrand: Do you support?

Michael Sinatra: I don’t know whether I support it or not. One other thing to say: Joe Maimon, please come out of your shell and tell us how you really feel.

Tim Denton: Ladies and gentlemen, we’re breaking into our break time. So last three people at the mics speak to the point, and then we will be ‑‑ make the break.

Scott Leibrand: I believe David was first.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Actually, I want to thank Heather for getting up and saying what she said. While I personally support the proposal, I respect her reason for not supporting it. And it’s the only reason so far that I’ve heard that I actually respect for not supporting the proposal. And so, as I said, I support the proposal, but I think this is a watershed event and we need to think about it. I think it’s better for us to do it this way because of the court case and a number of issues. But I also respect people’s right to feel otherwise.

Scott Leibrand: I believe Jason was next.

Jason Schiller: Jason Schiller, Google, NRO NC. And I’m sorry we’re out of time on this proposal, because I think there’s another important point we need to discuss, and unfortunately we won’t have the time.

John Curran: Mr. Schiller, are you in favor or opposed to the policy?

Jason Schiller: I am neither in favor nor opposed.

John Curran: Okay. Actually, can we ‑‑ because we have limited time, can we have people who have an opinion on the policy proposal ‑‑

Jason Schiller: Can I just make my point?

John Curran: I want to encourage people, as the mics will be closing, to queue up, if you have that. Yes, continue to make your point.

Jason Schiller: Thank you. I think it’s the legal question is driving you to support this policy proposal than a better rewrite would be to simply strike the IPv4 out of this sentence so that it would read: In addition to transfers under Section 8.2, number resources within the ARIN region may be released.

Scott Leibrand: I would encourage you to work with me afterwards to propose a new policy proposal to do that. I don’t think that is the subject of this. We have one remote participant, and then Kevin.

Bill Sandiford: All right. Joe Maimon from CHL.

[Laughter]

Bill Sandiford: Don’t ask or you might get what you ask for.

[Laughter]

Bill Sandiford: “It would be nice if ARIN could formulate and publicize their exact legalistic opinion on the value being conveyed and held when being recipient of an ARIN allocation and contrast that with legacy. I myself consider that it boils down to rights and value to an entry within ARIN’s database, whatever effect that has or does not have in the world at large.”

Scott Leibrand: Thank you.

John Curran: So both the legacy RSA 3.0 and the RSA that was released this past Friday, RSA version 11, contain in Section 2 the same words that describe the rights that a party has as an address holder, and they’re identical. So they’re worth looking at. We actually just released RSA 11, and it’s the same language as is in the LRSA. Thank you.

Scott Leibrand: Thank you. Kevin?

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on behalf of myself. I do support this proposal. Heather, you brought up a wonderful topic, a wonderful discussion point, which is related to the future of how we are using our resources, and I appreciate that that came up. For me, this is 16,000, which is a very, very large number, of ASs have sat around. And why have they sat around? Because there’s no good reason to give them back.

We have started to run out of ASs, 2‑byte ASs, because there’s been no reason to give them back. There are companies that have been long gone that have ASs still assigned to them. They’re shell companies at this point, and they’re still there. Yes, things are changing. The whole 8.3 specified transfer is a shift in the community to realize that if ‑‑ even if somebody no longer has value, they hold on to it. We are seeing that over the last 20 years. They hold on to IP space. They hold on to AS numbers. And if it’s a little financial prod that is needed to be given to get that back into the hands of people who can use them, I think that myself as a community member is happy with that scenario.

Scott Leibrand: Thank you. I don’t know if I ever mentioned it. Speaking for myself, Scott Leibrand, ARIN Advisory Council, Limelight Networks, I’m in favor of this policy proposal. I believe there are some good reasons to support the proposal. We’ve already talked about them. I would encourage you, as you think about providing your feedback to the AC through this show of hands that I expect Tim to give shortly, to think about whether any of the drawbacks outweigh the benefits. One of which, I believe the key one, is avoiding a showdown with the bankruptcy court that may throw a number of our policies into question. So I support the proposal and encourage you to think about all that and think hard about what you’re going to ‑‑ when you’re going to raise your hand in a moment. Tim, can you take over from here?

[Applause]

Tim Denton: So, ladies and gentlemen, 2012‑3: ASN Transfers. We’re about to vote. Are our splendid vote takers ready with their pens and papers? Okay. So those in favor of the proposal, would they please raise their hands. Raise them high and keep them high for the time being. Now those against the proposal as written, please raise your hands.

Thank you. I’ll go for the online voters. So in the matter of 2012‑3: ASN Transfers, total number of people in the meeting room and remotely were 106. In favor were 27, and against the proposition were 11. So the Advisory Council can take this into their guidance. Now we’re going to break for refreshments, and we will be back at ten after 11:00. Thank you very much. Good morning.

[Break taken from 10:42 a.m. to 11:11 a.m.]

John Curran: Welcome back, everyone. If folks will take their seats, we’ll get started. I have seven laptops available for sale up here.

[Laughter]

John Curran: But you have to need them. Okay. We’re going to resume our Draft Policy Block with the consideration of the next policy, and that is ARIN 2012‑1, Clarifying Requirements for IPv4 Transfers.

Draft Policy 2012-1: Clarifying requirements for IPv4 transfers

John Curran: History. This started out as policy-proposal-151 in May 2011. AC shepherds, Dan Alexander and Dave Farmer. AC selected as Draft Policy February 2012. Revised current version April 2012. And of course the text and the assessment are online and in your Discussion Guide. Summary. Modifies the 8.3 transfer policy and adds an Inter‑RIR transfer policy for both IPv4 addresses only. For 8.3 transfers, the source cannot have received IPv4 addresses from ARIN in the previous 12 months and will be ineligible to receive addresses from ARIN for 12 months after the transfer. For transfers to another RIR, the source cannot have received IPv4 addresses from ARIN in the previous 12 months and will be unable to obtain additional transfers from ARIN for the 12 months after the transfer.

The recipient must qualify to receive resources under the other RIR’s policies.

For transfers to ARIN from another RIR, the other RIR must verify the source as the authorized resource holder, and the recipient may request up to 24‑month supply of IPv4 addresses. Status at the other RIRs. APNIC, adopted. A similar policy, not this exact text, but similar in intent. LACNIC, panel discussion at LACNIC 16. And similar Inter‑RIR policy under discussion at RIPE. Staff assessment. Staff will use the date of transfer approval in terms of the setting of the windows, the timing in this policy. The 12‑month waiting period will deter flipping IPv4 address space by IPv4 transfers. Other RIR communities should consider that this will not affect the source outside of the ARIN region for address coming in to the region.

The phrase “reciprocal, compatible, needs‑based policies” ensures that both RIRs have compatible Inter‑RIR policies and general Number Resource policies that are needs‑based. Implementation: Resource impact? Major. Careful coordination between the RIRs on DNS issues and updates for Inter‑RIR transfers. I’ll note this activity is already underway because of 2011‑1. There is with any Inter‑RIR transfer policy zone fragmentation, DNS synchronization, administration and operational issues regarding reverse addressing. There is, of course, resource certification implications that are quite similar, because it’s also hierarchical. Updated guidelines and staff training when necessary.

Legal assessment. No legal concerns regarding the policy except for some logical suggestions counsel has made to the policy text regarding interregion transfers. Other changes to policy appear to have solved the prior legal concerns that were expressed in the review. PPML discussion. Nine posts by five people. None in favor, none against. Question of how exhaustion of ARIN’s IPv4 space is defined in the policy.

And in earlier discussion, discussion earlier on the proposal, generated quite a bit, 62 posts by 16 people. “It’s been watered down with the requirement for a needs test by ARIN. This is something I don’t like, but the proposal still has some protections of the free pool which I think are necessary in order to get 2011 or something similar passed. I support freer trade of IPv4 addresses, and the proposal as modified still moves us in that direction.” Okay. That concludes the staff introduction. I will now have Dan Alexander come up and give the AC presentation.

Dan Alexander: Considering how much fun we had with the last one, and that was a two‑word change, this should just be a gas.

[Laughter]

Dan Alexander: Oh, let’s jump in. One of the main intent or what they were, the original author was going for here was primarily to put some clarification around restrictions to prevent unnecessary depletion of the free pool. Or also to prevent flipping of resources, repetitive buying and selling to maintain that needs basis. What I did with the text is Section 8.3 and 8.4 essentially are doing something very similar. They were just broken out to better explain the subtle differences between transfers within the ARIN region and transfers in and out of the ARIN region. But for this discussion right now I’m just going to kind of cover the main point as it applies to both.

One of the first items that is a change versus how the policy is now is there is a statement in there where interregional transfers may take place only via RIRs who agree to transfers and share reciprocal compatible needs‑based policies. This is an augment to the text that was forwarded in 2011‑1, mainly because it was just to add the word “reciprocal,” because you could theoretically have a scenario where another RIR may share compatible needs‑based policies but they could have policies that would restrict resources being transferred out of their region. So we could essentially run into a one‑way street where we’re transferring resources to another region that shares needs‑based policies, but they don’t share the same coming into ARIN’s region. So that’s one reason for that one change.

Some of the other changes were primarily applied to those organizations who would be acting as the source of the transfer. One is the source entity must be a current rights holder and not be involved in any dispute as to status of resources. The word “dispute” was brought up on the Mailing List once or twice, because it’s ‑‑ the word is a little open for interpretation, because there could be any ‑‑ there’s a lot of variance between someone’s view of dispute. That word in the policy is in reference to ARIN and their policies, not someone’s interpretation as to how the resources may be utilized or used. It’s whether there’s a dispute as to the state of the registration records.

The other item, the source entities within the ARIN region will not be eligible to receive any further resources for a period of 12 months. That was it’s a blackout period to try and prevent unnecessary depletion of ARIN’s free pool. So you can’t transfer something off that you have and then go back to ARIN and say, well, I need new space now and I get it for no cost, essentially, in some cases. The next bullet is slightly different in that someone who wants to act as a source of a transfer could not have received a transfer allocation or assignment from ARIN for 12 months prior to the approval of the request. The difference between that and the previous one is this is more to address the issue of flipping resources.

The next two items, the source entity outside of the ARIN region, they must meet any requirements defined by the RIR and the minimum transfer size is /24. These are essentially ‑‑ the /24 is already included in the language of 2011‑1. So it’s really just a carryover. And the wording of the first bullet is really more just to clarify. It doesn’t really change anything, but it’s to clarify that the policies of the other RIR are their domain. The ARIN region is not here to define necessarily policies for other RIRs. It’s up to them to set those, and then it’s up to ARIN to decide if they’re reciprocal, compatible, needs‑based. The conditions on the recipient of a transfer are essentially the same as they are now or they would be as a result of 2011‑1, which is currently, has been forwarded by the AC.

They essentially say they’re subject to ARIN policy and the needs‑based review. And to address one of staff’s concerns, there was a lag between the time when staff did the review and the point where 2011‑1 was forwarded, which changed the time window to 24 months. The original text of this proposal had it set as 12 months. 11‑1 changed the needs window to 24 months, and this proposal has been updated to reflect that. But it didn’t make that change before staff did their assessment. So that’s why the concern was raised by staff.

Essentially the intent of the proposal is to address three things: It’s to avoid the one‑way street scenario in Inter‑RIR transfers. It attempts to prevent people from depleting ARIN’s free pool when they’re transferring, acting as a source of transfers, and it’s also to try and prevent the flipping of resources. And that’s it.

John Curran: Okay. Policy discussion. Microphones are open.

Dan Alexander: Perfect. Leave it at that. Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I do not support the proposal as written, even though I’m one of the shepherds. But I do support some of the concepts in it. However, I do not support the concept of the reciprocal basis. And my argument against it is that let’s get real. A majority of the legacy resources, which is what most people are interested in transferring, exist in the ARIN region. And if we allow them to be transferred out, it’s going to more or less be a one‑way street. Let’s get real. And if resources are transferred into LACNIC or the AFRINIC region, and none ever come back, I honestly feel that’s a good thing. And so I can’t support this reciprocal requirement.

Dan Alexander: We should probably draw the distinction there, because how the policy is implemented is different from the policy. If the scenarios play out where it’s all space going out of the ARIN region and just by the nature of the demand or supply none’s coming back, that’s not an issue of policy. That’s an issue of how things play out.

David Farmer: I tend to agree with you, but by making this requirement, you’re saying that resources can’t go to AFRINIC or LACNIC unless they’re willing to take the chance that some resources might come back.

Dan Alexander: That’s not my interpretation of this.

David Farmer: That’s what the reciprocal requirement will do.

Dan Alexander: My interpretation of reciprocal is that the policies need to be reciprocal. It doesn’t mean that the actual ‑‑ I don’t think anyone should be monitoring, well, there were two trades out, one transfer in. That’s not ‑‑

Bill Woodcock: Not reciprocal ‑‑

David Farmer: By requiring a reciprocal policy, it means in order for a transfer policy ‑‑ to have a valid transfer policy that meets your requirement, LACNIC has to allow both in‑and‑out transfers. Sorry to use the example, but it clarifies to use ‑‑ to pick a particular example.

John Curran: This was discussed in 2011‑1 as well. The addition of the word “reciprocal” would mean that a policy would need to allow transfers in both directions by the other RIR.

Dan Alexander: Right. It would allow them, but it doesn’t require one for one.

David Farmer: However, if the other RIR does not want to take the risk of resources exiting their region, they’re therefore not allowed to receive resources from us.

Steve Ryan: I’m going to give an instruction now. I don’t want a hypothetical that addresses a specific company or region unless it’s absolutely necessary and is justified by the adoption of a policy in that region. In other words, if a region adopted an interregion transfer policy and you want to address that, that’s perfectly okay. But watch the hypotheticals and you’re perfectly okay. This is to everybody here. It’s a reminder that we deal in policy, not in companies, and not in characterizations of a region.

David Farmer: Like I said, I apologize for it. But I was trying to clarify my meaning in that there are ‑‑ I think it’s perfectly reasonable for other regions to not want to risk resources exiting their region in order to achieve ‑‑ to receive resources. We have a lot of resources, and there are a lot of regions that don’t have resources. And I think it’s unethical of us to require them to risk resources exiting in order for them to receive them from us.

Dan Alexander: Marla.

Marla Azinger: I’m in favor of this policy. Just a couple of items regarding it. I’m okay with 24 months. I’d prefer to see 36. And I would like to see just very brief wording added that includes your upstream or ISP provider, because this clearly states that the gaming of the system, the flipping of stuff, kind of ‑‑ it reads like it’s only the ARIN level. But I’ve already had a case where someone wanted me to give them a /24 and they were going to sell their /16. And I told them no, you keep a /24; we’ll route it for you, and you can sell the rest. So this needs to include the fact that if this applies at ARIN it needs to specifically state that it also applies every level down. So there’s no flipping. So I have the absolute policy behind me to say no, this is how we do it.

If you just sold your/16, I’m sorry. I can’t give you address space for this period of time. You should have kept it. At least what they needed to use. Because the whole intent in transferring space isn’t to be making money. It’s to get the resources needed where they need to be used. So it just needs to include like the upstream providers and ISPs in it. So the other thing, the way this is being viewed is an RIR to IRR transfer is being done because it’s going from one entity to another different entity to be used within that other region, and there could be circumstances where it’s actually the same entity that wants to transfer their address set from this RIR to this other RIR for certain technical reasons.

John Curran: Address space that’s not assigned to an organization, an ISP or end user, that’s sitting in the RIR available pool. If there was a technical reason the RIRs would work how to ‑‑ figure out how to work that out, that’s not a policy matter. I don’t think you need to expand this to cover that case, if that’s what you’re worried about.

Marla Azinger: I’m not worried. I just want to be clear. If I were to tell you there is this entity that needs to use this address site in this RIR, but that RIR won’t recognize it unless it’s under their control, you will work to make that happen?

John Curran: If you come to the Open Policy Hour later on today, Leslie will actually talk about Inter‑RIR registrations.

Marla Azinger: Okay. Thank you.

Mike Joseph: Mike Joseph, Google. I support this policy. I think, generally speaking, it’s a sound rewrite of the transfer criteria. It adds back the necessary components. And, most particularly, it closes a very significant loophole regarding the flipping out of address space. I had the luxury of speaking to staff yesterday about this, and I’d like staff to comment here. On the current policy that was adopted or that will likely be adopted under 2011‑1, it would be possible for an entity who has a large amount of address space to sell that address space, then go request replacement address space in the same amount from ARIN. And provided they still have the underlying resources, they would be issued that address space from the free pool.

This would essentially lead to the bulk ‑‑ potential for a bulk removal of address space from ARIN’s pool and transfer it to other regions, and I’d like staff to confirm.

John Curran: As we discussed, because you asked me that directly, that is possible in the case where they got rid of the address space for one set of resources and they acquired space for another as a large organization. If they truly did it on the same resources, then they would be subject to being reported for Internet resource fraud. So it is possible to occur. But it’s also possible that it would be determined to be fraudulent because in the act of making those representations, they would be saying some things that were contrary on one of them.

Mike Joseph: Well, I’m referring to an organization that has existing space, sells it, and now still has resources that need to be numbered.

John Curran: Yes, quite possibly. The current text of 2011‑1, if adopted, would allow an organization to get rid of space and potentially apply for new space, and there’s nothing to prevent that from happening once.

Mike Joseph: Right.

John Curran: It couldn’t happen again.

Mike Joseph: Sure. But the wholesale turnover of large amounts of address space once is still potentially problematic.

John Curran: Acknowledged. I’m saying it’s not an open‑ended process. It’s a one‑step process allowed. Because the next time they apply, they would have a transfer application from the ‑‑ they would have a request within the immediate past, and we would see that.

Mike Joseph: Sure. So once per block.

John Curran: Right.

Mike Joseph: Right. So essentially, then, I think this policy closes a very significant loophole, and I strongly support it.

Kevin Blumberg: Kevin Blumberg, ARIN AC, The Wire, speaking on behalf of myself. I fully support this proposal. I would like to actually congratulate the authors for cleaning up what was a very difficult set of issues and making it easy for the ARIN community to understand. That’s my own personal view. In regards to the reciprocal nature, I think that it’s crucial. If there’s a concern for a particular region of space going out of that region, then they don’t need to have space come into that region potentially. I think that reciprocal is the fair and honest way, and if it is applied across the board to all of the regions, that is the way it should be done. It shouldn’t be selective. It should be fair.

In regards to the issue of an organization returning a /16 and then going to an upstream, as an example, and asking for a /24, I actually think that to me that is renumber and reuse. It’s actually a good thing. They’re getting rid of their bulky /16 and they’re getting back down and giving it to somebody who can use that 16 and getting back to a small allocation that is actually within their ‑‑ for their organization. There is a flip side to that, which is at the end of the day they don’t own ‑‑ they don’t have the same rights to that /24 because it is their upstream is /24 and it can be revoked at any time. They could change companies. They can take it with them.

Whereas that /16 is actually theirs to use within their rights. So there’s actually a negative to getting that /24, and I think that companies will realize that they are taking a risk by doing that and is fine.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN Advisory Council. I generally support the policy as written. I could take or leave the reciprocal requirement. As it exists, it’s an improvement over what we have. I don’t love it. I don’t love Section 8.3. I especially don’t love Section 8.3 after the last discussion. But I think this is better than what exists today, and therefore I support it as an incremental step towards doing the right thing.

Dan Alexander: Remote participant?

Bill Sandiford: Joe Maimon, CHL: On October 7, 2010, I stated that global policy that specifies that any transfer between any two RIRs needs to conform to the policies of both should be a simple enough solution. Apparently I could not have been more wrong. I like a lot this proposal, but with regards to Inter‑RIR transfers, I am just not quite certain whether compatible policies is quite the same as conforming to the policies of both simultaneously. Because if that is how ARIN views it, I’m in favor.

Dan Alexander: David.

David Farmer: David Farmer, University of Minnesota, ARIN AC. This is in regards to a comment Marla made, and I think it was misinterpreted or either I’m misinterpreting her comment. And I’ll just say that I have had members of the community at some events that I’ve been at ask about transferring v4 resources of theirs from the ARIN region to another region in their own name, because their internal company policies are that they only want to use resources registered in a region within that region. Now, since APNIC has run out, I will say they wanted to transfer resources from the ARIN region to the APNIC region, because they can’t get any in the APNIC region right now and they have excess resources that are registered to them in this region and therefore would like to transfer them, and their internal policies are such that they want them registered in the region they’re using them for lots of various other reasons.

And so I do think that there are other use cases than purely people selling resources. This can also be useful to multinational corporations who have operations all over the globe and want their resources registered in the region they’re using them. And so there doesn’t necessarily have to be a transfer of funds involved in a legitimate use of this policy or the other policy. So this isn’t ‑‑ isn’t specifically in support or against this policy, it’s just a general interregion transfers, there are other use cases than have been discussed. And there’s support for this in various other pieces as far as the general concept of interregion transfers. And, again, I don’t support the policy as written but support it in general.

John Curran: Joe Maimon had a remote comment, raised whether or not the staff used compatible in this policy, also in 2011‑1, as meaning conforming to the policies of both RIRs, we do not, and made that clear. That would require that literally the recipient qualified both by ARIN’s requirements and by another RIR’s recipient requirements, and that would be an application of two policies. We see compatible as a policy where we would ‑‑ if we had the source, we would apply the source. We expect the other RIR to have a policy that applies to the recipient. And we’ve said that both in 2011‑1 it is no different under this policy proposal. So compatible does not mean conforming to all aspects of both policies at the same time. That’s a clarification for Joe who asked it.

Dan Alexander: Jason, are you in the queue?

Jason Schiller: Yes, but I think Scott had something on this topic. No? Jason Schiller, Google, NRO NC. I support this for many of the reasons that Owen said about it, closing loopholes that currently exist in 2011‑1. I wanted to respond to something that David Farmer said, which was one of the initial points made at the mic which was this concern about reciprocity. There still is language in the policy proposal that says interregional transfers may take place only via RIRs who agree to the transfer. So it seems to me if there are legitimate reasons for a given RIR to not permit transfers out or in, that they can be blocked, even with a reciprocating transfer policy in that region.

The other thing I wanted to say is this community recommended that 2011‑1 be adopted by the Board. So we have to look at 2012‑1 as a replacement or an augment‑ment, augment‑ment, to 2011‑1. In the event that we don’t pass 2012‑1, we will have 2011‑1 which is essentially a very similar policy without some of these restrictions, these three restrictions that were added. And I urge people to keep that in mind. And that is primarily the reason why I support it, because I think, as additional restrictions to 2011‑1, this is important.

I remember there was a very long discussion about this with regard to 2011‑1 about the concern of people transferring out their space that they can still justify and then getting new replacement space from ARIN; that this can be washed, rinsed, repeat once through all of the space they hold, and that can lead to a large amount of space being transferred out of the free pool, essentially.

Now, this space isn’t actually being transferred out of the free pool. There’s space you’re currently holding is transferring out of the free pool, which makes space‑available need for you to get additional space from the free pool. But essentially depleting the free pool. And I’m not sure that that’s good for this community. And my understanding was that when we talked about 2011‑1, there was fairly good consensus that this was something that we should protect against.

Bill Sandiford: So Joe Maimon, CHL, thanks John for his response and states that he’s then against the proposal. He likes the changes to 8.3, would rather not have 8.4, and wonders why both are in the same draft.

Dan Alexander: They were primarily put in the same draft because they were intended to augment 2011‑1, and 2011‑1 covered ‑‑ changed the original Section 8.3 which applied to both interregion transfers and within ARIN. Scott?

Scott Leibrand: Scott Leibrand, Limelight and ARIN Advisory Council. I had to think about it, but I’m in favor of the policy proposal as written. Looking at it and looking at it side by side with 2008‑2, which was the first attempt at policy for transfers within our region, they’re very similar. Strikes me that 2008‑2 maybe was just too much to bite off at one time, but it was what we wanted. Maybe an idea ahead of its time. So I support it. I think most of the restrictions here are things that we have agreed are good restrictions and have mostly agreed on since 2008. I could take or leave reciprocal. If we have a consensus to strike that, I’d be happy to do so. I don’t think that’s going to be a big issue, but I think David’s got a point anyway. So that’s all say for now. I support it.

Dan Alexander: Mike Burns was the original author, and he gets a lot of credit for framing this out. He did a good job. Any other comments? I think that’s it.

[Applause]

John Curran: Thank you very much. Oh, wait. Go ahead.

Marc Lindsey: It won’t be too long. Two comments. Marc Lindsey, LBBB. Sorry. And there’s a condition here that says they must not be involved in any dispute. That’s both 8.3 and 8.4. I encourage you to think about that a little bit more, because any dispute can be any dispute. Doesn’t have to be legitimate, doesn’t have to be one that would ultimately challenge the source entity’s claim of registration; it could be a random dispute with some third party who believes that they have no legitimate basis to get those numbers, but they’ve asserted some dispute. So think about ‑‑ this might be a statute of limitation issue, but think about removing any dispute and having some element of good faith, solid foundation. We don’t like the word “material” in this audience, it’s too early, but I do encourage some thought process that you don’t want to have yourselves hamstrung by someone making an illegitimate claim from your numbers and transferring them if you need to. The second comment is about flipping ‑‑

John Curran: Marc, I have to comment on one thing. You didn’t start off by saying whether as written if you’re in favor or opposed to it.

Marc Lindsey: I’m opposed to.

John Curran: Opposed as the policy is written?

Marc Lindsey: Yes.

John Curran: If it were changed to consider, as you just suggested, not any dispute but a more clear definition, would you be in favor?

Marc Lindsey: Well, no. There’s some other things.

John Curran: Keep going. That’s what I want to know.

Marc Lindsey: There’s some other things here that I may not mention, but I might. So the other one was this notion that flipping is always bad. I mean, I think flipping isn’t always bad. There’s a circumstance where we’re mostly talking about the free pool, getting the free pool access, and then selling. But just talking about multiple transfers. There’s circumstances when companies may have had a business projection about numbers they want to use. They purchased them based on some forecast and they were wrong, they either went out of business or they were wrong. So setting a 12‑month limit on all subsequent transfers, if you’ve obtained numbers, I think, is the wrong way to deal with the flipping problem as a business proposition. So there’s legitimate flips that might be appropriate to consider.

Dan Alexander: One comment on that. It was we were trying to find a middle ground in a sense where you notice the restriction isn’t applied to the source. So in a lot of cases there are situations where someone may obtain a transfer or may obtain resources from the ARIN pool and, of course, those projections were wrong and they need further resources. We didn’t want to prohibit need for growth and apply to the blackout period to any kind of recipient. But that disposal of resources is where we kind of chose to apply that restriction.

Marc Lindsey: I understand. I think the point there was to eliminate the speculators, those requiring it. But my point is that not everybody who flips is a speculator. They may have just made a bad choice and they need to maybe potentially get rid of some portion of the numbers they obtained within the 12 months, has nothing to do with them creating a business model out of flipping numbers. So if the concern is to prevent speculators, then I would encourage in policy maybe that’s open hour to focus on a policy that restricts those who are engaged in successive transactions in a certain way as opposed to hamstringing yourselves on how you can subsequently transfer numbers if your business justifies that otherwise.

Dan Alexander: If you can think of a way to draw that distinction, I’m all ears.

Marc Lindsey: I’d be happy to work with you on that.

Dan Alexander: Owen. Hold on, Owen. Paul’s in the queue first.

Paul Vixie: To the last speaker’s question, the example of a company needing to do a flip for nonspeculative reasons ‑‑ for example, going out of business ‑‑ is uncompelling to me on the basis that going out of business and getting rid of all the assets of the now defunct business usually takes more than a year anyway. So as you progress toward helping us find a different distinction to avoid the bad kind of flipping that we’re trying to avoid here, I hope you can find examples that are compelling as to why 12 months is a particularly burdensome limit.

Dan Alexander: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. Correct me if I’m wrong, but I thought we crafted this so that if you got space and you didn’t need it, you were still able to unload it. You just couldn’t get more for another 12 months. Am I misunderstanding that now? Did we shift that around in a way that prevents that? Because I thought we had actually addressed this issue in the way we had crafted the policy.

Dan Alexander: Can we get the presentation back up?

Owen DeLong: We did muck it up.

Dan Alexander: That scenario is prohibited, I believe.

John Curran: As written it’s prohibited. Any further discussion?

Scott Leibrand: Scott Leibrand, Limelight Networks. The distinction we attempted to draw was to add the word “transfer comma” to the list of prohibited things, prohibited ways of acquiring addresses and then transferring ‑‑ and then transferring them again.

If I remember correctly, that was a somewhat controversial addition that occurred later in the process. To my earlier comments, I’d be fine with this policy proposal if the word “transfer” were struck from Section 8.4, third bullet point, and the equivalent in 8.3.

Dan Alexander: So this one that’s up on the screen right now, this bullet?

Scott Leibrand: Yes.

John Curran: Could you, for clarity for people in the room, you would say ‑‑

Scott Leibrand: The first bullet, strike the word “transfer” on the first line there and just make it read: Must not have received an allocation or assignment of IPv4 Number Resources in the last 12 months. That, again, gets us back to the question of are we trying to deter speculators and is there a better way to do it and all that. But I think regardless of whether that’s struck or not, this is a good policy proposal. If people have strong opinions that it should be struck if they’re going to support this, then they should speak up.

John Curran: In particular, if someone thinks they could support this with the striking of that, it would be a good time to come to the microphones. But the microphones remain open for all discussion.

Owen DeLong: Owen DeLong, ARIN AC. I would not support this policy without transferring. I argued vehemently for the insertion of that word. What I would support is moving these criteria to controlling the recipient rather than the source of transfer, which is what I thought we had originally done, and somehow that got moved around without me noticing. So I think if we prevent people from receiving additional resources after they’ve transferred them out, it does a much better job of preventing speculation than placing the controls on who can act as the source of a transfer. And I think that is a better way to solve the problem while still preventing speculation and flipping where the deletion of the word “transfer” merely opens it up to speculation, flipping again.

Mike Joseph: Mike Joseph, Google. I urge my colleagues, if you support the concept in general, to focus on the fact that we must pass this or something like this now if we want to prevent 2011‑1 from resulting in a large amount of our address space leaving the region. I think we can potentially tweak some minor changes. Hopefully the AC can address those after the meeting. But I think we need to support this policy and get it into Last Call so that we can actually have a policy on the books prior to the implementation of 2011‑1 so that we don’t have the situation with all of our address space potentially leaving through the back door that we created. So I support the policy as written.

Dan Alexander: So you’re more in favor of approving this and doing any kind of changes and cleanup in a future proposal.

Mike Joseph: If there’s substantial changes, we could do it in a future proposal. Or if there’s minor changes or a word, particularly, if the reciprocal word or some such is problematic, I think AC could address that based on consensus. But I think I like to see this policy, 2012‑1, make it to last call in a very similar form to this.

John Curran: There are some words ‑‑ there are some changes that are simple in terms of number of Unicode characters affected, dropping a word, for example. But in terms of impact, they’re very significant. So I guess I want to be very clear on what you’re recommending. You want to see this advance, and if the AC has to make changes to it, you would tell them to make ‑‑ when you say “minor changes,” I’m not sure what you’re advocating.

Mike Joseph: I would encourage the AC to use their judgment, as they’re elected to do, to implement the community consensus while trying to limit the number of changes to the policy after the meeting as they’ve typically done.

John Curran: Right. So to the extent that someone wants a significant change, like dropping the word “transfer” or making a different reciprocal process, they should speak now so the AC has that input on record. Otherwise, it will end up having to come back to a meeting.

Mike Joseph: I agree. They should speak now. Although, I think most people who’ve ‑‑ I think there’s been quite a few people who have spoken about that, and I hope the AC can judge consensus on that without having to come back to a meeting.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on behalf of myself. I am in support of this policy. I am in support of leaving the word “transfer” in here. I would love to see that 12 months down the road if this policy is adopted, that if there’s a concern, a one‑word policy proposal asking for the removal of the word “transfer” could be then done. Because I believe that sometimes you need to start a little tighter, have that policy implemented, see how it goes, and if real issues come out of it, loosen it up a little bit at that point. Thank you.

Dan Alexander: Jason.

Jason Schiller: Jason Schiller, Google. I’m concerned that the discussion that just occurred draws the point away from what my colleague is trying to bring to the forefront, and that is if people are unhappy with this policy and they want changes, fine. We should deal with those now, later, whatever. The important point here is you have to weigh what is your level of unhappiness of this policy without changes, or only minor changes, versus your level of happiness of simply passing 2011‑1 and not having an update to 2011‑1 for another policy cycle. And I think that was the crux of the point he was trying to make.

Marc Lindsey: This was an invitation, I believe. This is Marc Lindsey. I’m still opposed. I might switch to a slightly in favor if sort of one of the things that has not been discussed here, and it’s not new, but I do think this 24‑month need qualification is a bad idea. I mean, it’s something you’ve done; I know you recognize it. But for many who are in the contemplation of buying what might be a dying resource, planning on a 24‑month cycle is not ideal. Planning on a 48‑month cycle is better. So I would be more in favor of this policy if there were a longer time window to give businesses a chance to make their own choice, particularly in the transfer space, about how much money they want to invest in a resource that may be declining, let them make that choice in a four‑year window. Even a five‑year window would give them more opportunity to make that choice on their own, as opposed to being driven by policy.

Dan Alexander: The main reason the 24 months was applied was because the last policy cycle, 2011‑12, made that change. So this one was tackling so many things in one shot; we hesitated trying to pile on.

Marc Lindsey: I agree. I wouldn’t have raised it except for the invitation to say if there’s something that could change here that would make this supportable, say it now or hold your peace. That’s why I thought I’d say it.

Scott Leibrand: Scott Leibrand, ARIN AC. I would advocate you say that again when we discuss 2012‑4 in a little while, which is the question of what should ‑‑ how many months should the thresholds be. The current discussions maybe aren’t moving in the direction of the current ‑‑ Draft Policies maybe aren’t moving in the direction you want, but that is definitely something that I think is another policy issue separate from this.

And I think, to Jason’s point, we really need to consider whether this as written is an improvement over the existing text, and I still believe that it is. I’m still in support.

John Curran: We are running out of time, approaching lunch. So people who want to speak about this policy proposal should find a microphone quickly. Closing the microphones. Closing the remote participants. Last chance. Closed. Got one.

Bill Sandiford: Joe Maimon, CHL: 2011‑1 is under advisement. Does this mean that even with similar levels of opposition at this time to both 2011‑1 and 2012‑1, results in 2011‑2 being adopted and not 2012‑2? Because if I have to choose between them, I prefer 2012.

John Curran: 2011 is recommended for adoption by the AC. And the Board just had a consultation yesterday, and at some point I’ll get told to complete implementation. So that ‑‑

Bill Sandiford: I have another, too.

John Curran: So that’s a separate matter unless we decide to delay implementation. We don’t know whether this is going to converge on a revision or how long that will take. I guess we have to hear that from the AC to see whether or not 2011 should be held. So does that answer his question?

Bill Sandiford: I have one other one as well, too: Tim McGinnis, ISC and AFRINIC Policy Development Working Group, but speaking for myself only in my personal capacity. I agree with Owen and I would not be in favor of removing the transfer from this proposal.

John Curran: Okay. Any other comments remote? We’re going to close the remote mics. I see Jason wants to respond. Do you want to respond to something raised?

Jason Schiller: Yeah, there was some mention of possibly delaying implementation of 2011‑1 if 2012‑1 passes. I wanted the community to understand what the time frame would be for such a delay, because it seems to me the things that need to be implemented by ARIN staff are identical to 2011‑1. Is there some delta of additional work that would have to be accomplished by ARIN staff to move from 2011‑1 to 2012‑1?

John Curran: Not significantly. We’re actually at a point where we’re 60 to 90 days from completion. And so at that point when it’s ready we would need to ask the Board whether you want us to continue or not. Obviously by then there might be some insight on this policy proposal and that might weigh in there.

Jason Schiller: 60 to 90 days to implement 2011‑1.

John Curran: Implementation of 2011‑1 is already underway and will probably complete in 90 days.

Jason Schiller: And how quickly could 2012‑1 complete if consensus was judged, it was recommended to the board to adopt and the board adopted?

John Curran: The implementation steps are the same for them.

Jason Schiller: Thank you.

John Curran: So it’s really only a question of whether we roll out with what policy governing what requests we accept.

Jason Schiller: Thank you. That’s exactly what I was looking for.

John Curran: Thank you.

[Applause]

Tim Denton: All right. Now, in the matter of 2012‑1: Clarifying Requirements for IPv4 Transfers, have we got our vote takers ready? Pencils and paper in hand. Okay. Those in favor of the proposition as stated, would they please raise their hands. You can put them down. Thank you very much. Those against the proposition as written, would they please raise their hands. Hands down. Thank you very much. In the matter of 2012‑1: Clarifying Requirements for IPv4 Transfers, total number of people in the meeting room and remotely, 106. In favor of the proposition, 26; against, 6. This stands as advice to the Advisory Council. Thank you very much. Time for lunch.

[Applause]

John Curran: We’ll see you all back here at 1:30. Thank you all.

[Lunch recess from at 12:07 p.m. to 1:34 p.m.]

John Curran: If everyone would come in and be settled, we’ll get started. Okay. I’d like to welcome everyone back from lunch. This afternoon we have discussion of Draft Policy 2012‑2: IPv6 Subsequent Allocation Utilization; Draft Policy 2012‑4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool. We have the IANA Report. We have the NRO NC Report. We have the NRO Activities Report. We have a report from our fellow RIR, RIPE. We have the Policy Experience and Implementation Report from staff regarding lessons learned and running the policy. And we have our Open Policy Hour. The Open Policy Hour and Open Mic are at the same time. We’ll open Policy Hour for a short time and go to Open Mic to pick up on yesterday’s conversation.

Rules and reminders. The chair moderates discussions of Draft Policies so all can speak and all can be heard. Please state your name, affiliation each time you’re at the mic. If we’re talking about a policy, a Draft Policy, it would be nice to know whether you’re in favor of it or not at the beginning. It helps people understand your remarks. Please comply with the rules and courtesies outlined in the program. Okay. At the head table I have Stacy. I have Scott Bradner. I have ‑‑ it’s amazing ‑‑ David, Owen, and Paul Vixie. Now, David, how come I have David? It’s when I look at the faces; it doesn’t sync up somehow. So I’m going to start right in with ARIN Draft Policy 2012‑2: IPv6 Subsequent Allocations Utilization Requirement.

Draft Policy 2012-2: IPv6 Subsequent Allocations Utilization Requirement

John Curran: Okay. This originated as ARIN Proposal 159 in November 2012. The AC shepherds, Heather Schiller and Cathy Aronson.

Scott Bradner: 2011.

John Curran: Thank you. November 2011. The AC selected it as a Draft Policy in February of 2012. The current version is the 22nd of February version of that text. The text and assessment are both online at the ARIN website and in your Discussion Guide. Summary. Policy would allow an ISP to qualify for additional IPv6 space when they can show utilization of 75 percent of their total address space or 90 percent utilization of a single serving site or 75 percent of their IPv6 allocation is subneted and each subnet has at least one customer or infrastructure assignment. Status at other RIRs. No similar proposals or discussions. Staff assessment. Effectively allows an operator to qualify for IPv6 addresses at any time because it’s trivial to subnet 75 percent of an allocation and use at least a tiny portion of each.

Another option would be to simplify IPv6 additional allocation policy to allow an operator to qualify for more IPv6 addresses when they can show a need for them. The author’s original rationale stated that the expectation would be for ARIN to use its discretion to weed out unreasonable requests, but there’s no policy basis for doing so. Nothing in this text gives staff any basis for rejecting any subnet size. If ARIN is to review requests to determine if technically reasonable, then some criteria or guidance must be provided. Resource impact. Minimal. Legal assessment. Does not pose significant legal issues.

PPML discussion. Four posts by three people. One in favor; zero against. “I’m in favor of a pro forma approval of an ISP’s second IPv6 request as long as it is not outrageously sized, outrage in the bigger than /24 category. Time enough to make tight IPv6 allocation rules when we have the experience which goes with half of the packets on the Internet moving with IPv6.” Earlier discussion of the proposal. Fourteen posts by six people. “If there’s a reasonable way to get reasonableness standard incorporated, I would support it. But I also support it as is. I think it gives enough guidance to staff to make the right decision.” That concludes the staff introduction, and I will now invite Heather up to give the AC presentation.

Heather Schiller: Okay. So this is the current text as it fits into the NRPM, the subsequent allocation to LIR policy, and it’s just Section B that’s being modified. And in red is the part that’s being added. So the 75 percent or more of total address space and 90 percent of a serving site already exists today. We’re not changing that. We’re just adding a third mechanism by which an ISP can get an additional allocation. You can see a side‑by‑side comparison of the before text and after. The green stuff stays the same. The red stuff gets added. A little grammar happens.

So why are we doing this? Originally the author’s concern was for providers that received allocations and the allocations based on ‑‑ that they received an allocation based on a specific subneting plan and that the allocation they received turned out to not be large enough for all the subnets that they had planned out. So they had already started numbering and assigning objects and didn’t have enough room to continue growing. But they didn’t quite qualify under the existing subsequent allocation policy because they hadn’t deployed enough to have 75 percent of their address space or 90 percent of a particular site. So part of that problem gets solved by a policy that Owen proposed and passed in January. So in a way these two policies kind of passed each other when Owen’s proposal to modify the initial allocation criteria passed and was adopted and put into the NRPM in January.

This policy was already in the works. But I think that there’s still something of a problem to solve. So even though sites today can get a larger initial allocation than they could when the text was originally proposed, I think that at some point down the line we’re going to have the problem of providers having allocated, having subneted out all their address space and not having enough to create new subnets as needed. So that’s what this policy attempts to solve. Sometimes it occurs in MDN‑ish situations, Multiple Discrete Networks. So you might have regions or whatever mechanism that you’ve used to subnet, you fill out all of your ‑‑ you’ve subneted all of your address space and you don’t have enough left over to create new ones for whether it’s regional or hub or for a particular technology.

So part of it is the question of did you get your addressing plan right or you just haven’t filled it out enough. So I tried to list out the arguments for and against the policy. Allows for growth of subnets. Allows early adopters to attain the same amount of address space currently under ‑‑ that folks would get under initial allocations. I think that a lot of the comments against the policy were specific to the language used. No one seemed to object about the concept, but more about ‑‑ and even staff’s complaints were about the language and the possibility of it being to game to get additional address space. But no one provided good feedback about how the language could be modified.

Like I said, I think this might be ahead of time for most users. Most providers either are getting the size allocation they think they need, haven’t gotten far enough into deployment, or are able to come back to ARIN and get a larger initial allocation under current policy. And the other question to ask is what should the number of ‑‑ minimum number of assignments in a subnet, what should that number be in order to consider the subnet utilized? Questions? Owen DeLong.

Owen DeLong: So as the author of the original policy, I think this seeks to address an oversight in the policy that I authored. I think that the idea is a necessary one. I don’t support the language as written. Owen DeLong, ARIN AC. I think I forgot to do that. What I do support is the idea of adding the ability when you have allocated blocks to all of your serving sites and your serving site block site is justified under the policy ‑‑ block size is justified under the policy; that if you need additional serving sites, that should be a valid criteria added to 6.5.3B, I think it is, where you can get additional space for additional serving sites under the policy. And I would like to see us tweak the language to reference it that way and then get it moved forward. So that would be my recommendation.

John Curran: Do you understand what he said?

Heather Schiller: Uh‑huh.

John Curran: Okay. Microphones are open. M.J.?

Mike Joseph: Mike Joseph, Google. I oppose this policy as written for similar reasons that Owen stated. I think quite specifically that what is needed is simply a cleaner expansion of 6.5.3B to indicate that policy ‑‑ the address space assigned according to the formula for initial allocations when it has resulted in either 90 percent utilization of a single site or something like 90 percent of your overall allocation assigned to sites would be sufficient to close this one problem that does exist. We met with staff earlier today and they confirmed that it does exist; that you can’t come back for more space, if you assign all your space to your sites and then run out. So we definitely need to address this.

But this policy as written is incredibly dangerous. It would allow an entity to obtain essentially any amount of space of their choosing. You could get a /4 under this policy. So opposed as written, but we definitely need to address the underlying problem, and I think that may be able to be adjusted with the change to policy text.

Andrew Dul: Andrew Dul, Cascadeo. I support the concept of this policy. I don’t support it as written. I think the question about what 1* should be is probably best thought of as in percentages, like what we do with multiple discrete networks, where you have to allocate so many serving sites as a percentage and then so many subnets within a serving site need to be used. Maybe that number is 25 percent. I don’t know. But that’s the starting suggestion.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire. I support the concept of the proposal. I do not support the proposal text. But what I really wanted to bring up was the issue of the moving target of what allocation size is appropriate, has changed over the last two or three years a number of times, and in fact one of the biggest metrics is the five‑year, look out five years and see where you are in terms of your initial allocation. And with a number of luminaries in the industry, it’s been suggested that maybe five years is very shortsighted with IPv6 and it should be ten years.

And what I believe this is trying to address as an issue is the people, the early adopters who have gone out and gotten the wrong size, have deployed into their networks the wrong size, have started the process and realized that it is wholly inadequate for what it should be. So I believe that moving forward the discussion should be about how we can deal with the early adopters, A, and, B, are our numbers skewed to the old IPv4 world way of thinking things and do we have to radically look at number allocations to sites in a completely different way.

MDN is probably a very good example of where that sort of concept, which is very rarely used from my understanding in the IPv4 world, actually becomes more relevant. Because each IPv6 site, it becomes its own little island, and these islands can fill up in all sorts of different ways and how do we deal with that. So I’m not proposing anything specific, but saying that I think there’s major needs to look at this, especially over the next 12 months, when North American ISPs, who have lagged in IPv6, start to really deploy and realize that they were shortsighted in their allocation numbers.

Heather Schiller: Owen?

Owen DeLong: Kevin, I tried to write most of the considerations you’re expressing into the policy that’s currently on the books in the paragraph that basically says: If you got an allocation before this policy went into effect, you’re welcome to come back to ARIN and have your allocation expanded under the criteria in this policy if possible, and, if not, receive an entire new allocation without any requirement for return at the size specified by this policy, the existing policy on the books.

So I think in terms of the early adopters, that’s addressed. What I think this seeks to address is someone who gets a certain amount of space and then instead of outgrowing their allocation by filling up serving sites, they’re faced with a situation where their number of serving sites grows faster than their clients in any given serving site and they therefore need additional space to address those additional serving sites. And that was an oversight in the original policy.

Kevin Blumberg: So I can speak to a specific generic case, Owen, where this sort of fails. And this is my concern. And there are many like this. A customer that I know said: I believe a /28 will deal with my network and what I am doing today. Two years from now I will have filled it up 10, 15 percent, because it’s five years, and I’ve been asked to deploy to 500 new sites on something and I need another /28 or /24. And because I have hit 10 percent across and I did not foresee going into this business model, I’m stuck.

And so I think that, again, because we’re not talking about one‑ and two‑year projections and we’re talking about five and, like I said, potentially ten‑year projections, you could have deployed out to your existing network as it was today and two years from now your network looks very different but your utilization is not at the point where it would allow you to get more space. Does that sort of differentiate?

Heather Schiller: You’re both saying the same ‑‑ similar thing, that both cases exist. And I think it’s just a difference of whether you go back and get more space under initial allocation or you get a subsequent allocation. And the end result is that you get more space to do what you need.

Owen DeLong: The difference we’re saying is that Kevin is calling somebody who implements today an early adopter, and I’m calling them a late adopter.

Heather Schiller: Aaron Hughes.

Aaron Hughes: Aaron Hughes, 6connect. I’m the originator of this text. And Owen is correct that we were working on solving the same problem with two different sets of text, at least one of the problems, and so the early adopter issue is I believe covered by the updated initial allocation text. But also agree that subsequent allocation text does need some updates to make it easier for long‑term planning, and certainly I fully agree with Kevin that people will start to run into very serious long‑term plans, and as they implement and slowly grow, not because of customer growth, but because of slow adoption for dual stacking their customers, the number of actual customer assignments in a given site will be slow to grow. It is a real problem, and it will continue to be a real problem. And the intent is to make sure that v6 adoption stays easy. And subsequent allocations are certainly going to be an issue in the very near future.

Heather Schiller: Anyone else? I’m out of here.

John Curran: Thank you, Heather.

[Applause]

John Curran: Heather, did you want a poll of support for this policy? I just want to make sure you want one. Sometimes there’s so much in flux that you don’t want one. Okay. Chair?

Tim Denton: In the matter of ARIN‑2012‑2: IPv6 Subsequent Allocations Utilization of Requirement, those in favor of the proposition as drafted, please raise your hands. Come on now. You can do better than that.

Heather Schiller: I should say that I’m ‑‑ I should have said it would be perfectly fine with me if you phrased the question about are you in favor of the concept in general of modifying this ‑‑

Tim Denton: I’ll rephrase the question, then. Are you in general favor of the concept?

Can they put down their hands. Now, those generally ill disposed towards the concept, please raise your hands. Okay. Do you want a tougher test, then, Heather, or are you satisfied with this issue in principle? Okay. So there we are.

Owen DeLong: Mr. Chairman?

Tim Denton: Owen.

Owen DeLong: I would like to have the record reflect that there was generally low support for the text as written, because if we don’t have that on the record, then it makes it harder to refer back to it, versus the secondary question that was actually asked and got a much broader response.

John Curran: The poll wasn’t completed. Do you need to have that on the record?

Owen DeLong: I think it’s helpful to have it on the record whether or not there was support for the language as written rather than just whether or not there was support for the concept.

John Curran: Should we do that and ask?

Tim Denton: Now that we’ve got the issue in principle sorted out, now those in favor of the proposition as drafted? A vast wasteland. Okay. I think we have the answer. Those opposed to it as drafted? Okay. In the matter of 2012: IPv6 Subsequent Allocations, number of people in the meeting room and remote, 108. In principle, in favor, 29; against, zero. As drafted, in favor, one; against, 17. Thank you all very much.

[Applause]

John Curran: Moving right along we’re going to discuss another policy proposal. The next policy proposal in this block is ARIN‑2012‑4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool. I’m going to give the staff introduction and then we’ll have R.S. come up and give the AC presentation.

Draft Policy 2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool

John Curran: So policy originated as ARIN Proposition 162 in January 2012. The shepherds are Rob Seastrom and David Farmer. AC selected as a Draft Policy in March of this year. The current version is the 14 March 2012 version, and the text and assessment are online and in your Discussion Guide. Summary. Proposal would revert NRPM Section 4.2.4.4 “Subscriber Members After One Year” back to an earlier version in which an organization may request up to a 12‑month supply of IPv4 addresses. At the time ARIN free pool is the equivalent of a /8, an organization would only be able to request a three‑month supply. No similar proposals or discussions.

Staff assessment. ARIN only has a limited supply of large aggregates. Staff believes it may be operationally prudent and practicable to reserve a single contiguous /8 to serve as the trigger for this policy. Benefits include fixed, easily understood for the community; clear inventory, more transparent to the community; would allow operators to better plan for future allocation policy switches from 12 months to allocations back to three. Issuing a 12‑month supply of IPv4 addresses will likely significantly accelerate the depletion of ARIN’s existing IPv4 free pool. Historically, ARIN’s IPv4 consumption rate was roughly doubled when issuing 12‑month supplies versus three‑month supply.

Several very large requests could quickly deplete our free pool. In light of this, the community may want to consider bringing back a maximum allocation size. Implementation: Resource impact? Significant. It’s major impact. We need software to track this /8 equivalent trigger. We need to update the staff guidelines. This is a fairly frequently ‑‑ it’s a very frequently used request, so it’s something that takes a bit of work. Legal assessment. It’s a major event since it will dramatically change the date of IPv4 runout at ARIN. This is a profound policy, but not legal change.

PPML discussion. Twenty posts by eight people. Five in favor and two against. “I’m very much in favor of policy change that will speed ARIN runout to bring it more in line with APNIC and RIPE.” “Opposed. At face value, being able to request 12 months is a plus; however, it’s at risk of killing off the surplus we’ve built up too quickly.” “I am not in favor of keeping IPv4 alive any longer than necessary. I would favor possibly taking it from three months to six months but probably not much higher.” So that’s the staff introduction. And I’ll now turn it over to R.S.

Rob Seastrom: Thank you, John. I appreciate that. Okay. Someone help me here. We’re not on the title slide. Thank you. Alrighty. Okay. So a little bit more background. It seems like forever ago, but it’s actually only about a year and a quarter ago you were able to get a 12‑month supply of IPv4 addresses by showing justification, and now you can only get three months. We thought we had a really good thing going with the policy proposal that put the three‑month window event into effect. But no one could anticipate the way things played out in the end with some return space and the final five /8 distribution. And the net result of that was that we ended up with sort of a record amount of IPv4 space on hand when the policy was triggered.

So there’s a policy proposal to fix this, and that is to add the following to NRPM 4.2.4.4, “Subscriber Members After One Year.” After an organization has been a subscriber member of ARIN for one year, they may choose to request up to a 12‑month supply of IP addresses. When the ARIN free pool is down to the equivalent of one /8, excluding all special reservations, the length of supply that an organization may request will be reduced. An organization may choose to request up to a three‑month supply of IP addresses.

Any request that reduces the ARIN free pool below the /8 threshold above will trigger the reduction for that and all subsequent requests by all organizations. So the pros. The effect of the ‑‑ this is pros as in we should adopt this policy. The effect of the three‑month rule on ARIN’s runout rate has been enormous, and being way out of sync with other RIRs is arguably not a good situation to be in. They say that plagiarism is the sincerest form of flattery, but I believe that plagiarizing and then marking up is an even more sincere form of flattery. So I’d like to draw people’s attention to the four inflection points I’ve labeled on this slide here. One of them says you are here. That’s our trace, the purplish one on top. If you take a look to the left of that, that’s the inflection point where 2012‑8 was implemented. That’s the three‑month rule. And you can see it flattened out, so the derivative of that curve there is substantially flatter.

The third one over is the projected line based on some sort of curve fitting. It’s not linear. And Geoff will probably come up and tell me exactly what was done for that. But that’s the projected ARIN runout, which is clearly not the actual ARIN runout. And the last inflection point over to the left, it could be embarrassing and lead to people coming up to the microphone and talking about how unfair our policies are should our runout point actually be over there. One last pro. This policy is likely to restore IPv4 run rate to pre‑2009‑8 implementation levels. Huh? R.S., what are you saying? Is that supposed to be a pro? Yes. It’s also a con. This policy is likely to restore IPv4 run rate to current ARIN ‑‑ pre‑ARIN‑2009‑8 levels. Another con. We keep talking about how we need to knock it off with messing around with IPv4 policy because every time we change it, we screw up people’s projections and people’s plans and organizations can’t be expected to plan adequately in an environment of constant change.

Another con is that the current approach is phased. Leslie had a presentation yesterday about the step‑down method that we have in place right now. And this turns it into a big step function. RIPE has ‑‑ if you take a look at what other RIRs are doing, RIPE has an extended three‑month soft landing that they’ve had in place for quite a while. AFRINIC has a soft landing policy. 2012‑4, which is this policy, is not a hard landing proposal. It’s also a soft landing proposal. But it’s maybe a little bit less soft landing than we’ve been trying for so far. One more con.

The largest allocation we’ve had to date is a /9. And we kicked around ideas for various linguistic things that we could have in there, like the next to last allocation before, and we decided that anything that we could possibly put in there would just make it unclear and mess things up and it was ultimately arguing what color to paint the bikeshed while the house still needed to be done. So that’s a possible edge case, although I believe it’s unlikely. So let’s talk. Microphones. I see Geoff Huston approaching the microphone, no doubt with some sort of curve‑fitting algorithm for me.

Geoff Huston: You kind of invited me here. So, yeah, right. The theory was when I did that graph, when you changed allocation window to three months, folk would come back four times a year. So what I did was I did a curve fit based on the last four years, but I weight the most recent year five times more than the one before, the one before, so it’s slightly exponential. Recent experience matters more. And if that was the case ‑‑ that folk were coming back four times as often, but the consumption rate was still there ‑‑ ARIN would run out and get down to its last /8 ‑‑ that’s what I mean by runout ‑‑ in around 14 months from now, maybe 15.

But for some reason, and I have no idea, the consumption rate in your region of the world has halved. In 2010, around 45 million addresses went out the door and got distributed particularly in the US, but US and Canada. And in 2011 it was down at 21 million. If something had happened and that truly is a consumption rate, then there’s another five years almost of v4 address pool in North America. I find it hard to believe, because everyone has iPhones, everyone has devices. Are you squeezing your clients too hard? Are you exacerbating a problem? I don’t know. But certainly I’m not seeing what I thought I’d see, and that’s why the curve doesn’t fit the most recent data.

Rob Seastrom: Center rear mic.

Mike Joseph: Mike Joseph, Google. I oppose this policy. I probably am in the camp that we should stop messing with v4 policy, particularly stop messing with v4 policy that we just changed and just went into effect. Moreover, it’s worth pointing out that based on ARIN’s previous approximate run rate, and Geoff will probably correct me on my numbers here, but we were using a /8 something around the order of once every four months or so.

And if we were to adopt this and Geoff’s theory of overall ‑‑ well, if the decrease in utilization was based on the three‑month horizon, and that’s causing other follow‑on effects and we return to an earlier utilization rate, this policy would only really have effect for the rest of the year, after which point we would have exhausted the two and a half /8s left and then we would get back to the three‑month horizon. That means that we’d essentially be enacting a policy now that would move the finish line for people for a short period of time and then put it right back. I can’t think of anything that would lead to less predictability and stability in policy, so I oppose this.

Michael Sinatra: Michael Sinatra, ESnet. At the present time I support this policy, mainly because I think that perceptions matter, and the current state of the ARIN free pool is somewhat problematic with respect to the rest of the world, and I think it also distorts the actual transfer market. So I think those two issues are problems. I also think that, kind of to quote Geoff Huston, IP addresses should be used. IP addresses do no good if they’re sitting in a free pool. And if we keep hoarding them in this free pool, that’s just not going to work. On the other hand, I would be willing to withdraw my support for this proposal for two reasons.

One is if we start returning IP addresses to IANA, then that sort of solves that problem with that free pool because there’s going to be a bunch, even if we do it based on whether they originally came from a pre‑era and registration authority, we’re still going to give back almost a /8, if not more. So if we were to return ‑‑ and I realize we’re not discussing this aspect of it now, and whether I support it or not is irrelevant, but that would change my support for this policy, because it definitely changes the dynamic of the free pool. The other issue is that one possibility, the fact that Geoff is speaking to this notion that consumption of IPv4 addresses have ‑‑ has decreased significantly in the ARIN region, is very interesting.

And if it’s the result of increased adoption of IPv6, and if anyone has stories to tell about that, any evidence that a reasonable person could infer that this policy’s actually helping improve the uptake of IPv6, I think that’s very salient and very much supports the existing three‑month window and not messing with the three‑month window. And I would be happy to support that if that were the case. So I’m not sure it is, but it kind of sounds to me like it is the case.

John Curran: I need to ask a question to understand what you’ve just said, and it’s with respect to the return. If approximately one /8 were to be returned to IANA because of other decisions, that would take the free pool down 20 to 25 percent, depending on when it happened, which based on what Geoff just said of saying that our current three‑month frugal policy looks to be four or five years. You’re saying that you support the policy. But if the pool were to drop 20 or 25 percent, you would no longer split the policy, that would still be many years compared to other regions.

Michael Sinatra: That’s a good point. There are two reasons I would support it. Both of those conditions ‑‑ well, I don’t know, if one or more of those conditions, to be decided by me at some point later, were true, I may or may not decide to support the policy. So basically, though, I think that there’s some mitigating factors, and I think the two big ones are if we are going to proceed with the return of address space that is returned to us to IANA, that changes my view of what the free pool looks like and what the perceptions look like. Then if we were also to determine that we’re actually doing some good with IPv6 adoption, then, yes, we should absolutely keep the current three‑month policy.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. First of all, I support the policy as written, because that’s why I wrote it. Second of all, can we go back to the policy text, please, for a moment on the slide. So any request that reduces the ARIN free pool below the/8 threshold will trigger reduction for that and all subsequent requests. I think that takes your last con slide out of the mix and makes it fictitious, because the /9 request would be treated by the reduction. That’s the intent.

Rob Seastrom: Marla?

Marla Azinger: Marla Azinger, Frontier Communications. Geoff, did you add into that equation the transfers that have occurred in the ARIN region? Because those should be considered as granted requests. So all those address spaces, did you add that into the equation? Because it’s a lot.

Geoff Huston: I don’t believe so.

John Curran: Is this something that you folks can take offline and come back with a ‑‑

Geoff Huston: Yeah, that’s actually really quite a fine point. It’s the way ARIN publishes its daily stats files. And I just take the date in the stats files as being the date the thing goes out the door. So if there’s a transfer, if ARIN changed the date, then I count transfers as being allocations on the day of the transfer. But I don’t work for ARIN. I don’t understand how you direct your stats file. I can’t really answer it.

Marla Azinger: I ask because you keep referring back to it. So if we’re going to stop referring back to it, that would be good. The statement of not knowing what was going to happen. No, we didn’t know what IANA was going to do. But I will refrain from a lot of snarky statements which I’d really like to make right now because we have repeatedly messed with stuff that is policy, and all this sunset, soft landing stuff, in my opinion, is crap. I’m not saying the work people have done is crap, but I don’t agree with doing all of this.

If you take business models, which I understand we don’t write policy to be perfect for businesses, but if you take a business model and look at how they actually have to plan in time frames, we would have known a three‑month policy change is asinine and you can’t plan and organize off of that. So I do support this policy that is up here. But I would much prefer get rid of any soft landing‑type stuff and just use the address space.

Rob Seastrom: Thank you. Kevin.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire, speaking on behalf of myself. In principle I do support this proposal. And I actually had a question for staff. Leslie had mentioned some numbers in regards to the big allocations that were still available in the free pool. So my first ‑‑ part A of this question is: Is free pool considered depleted when somebody can’t get a block size?

John Curran: No.

Kevin Blumberg: No. Okay. So by going to 12 months, back to 12 months, we will see some very large big blocks get eaten up in the ‑‑ naturally. There will be lots of little blocks. That’s what’s left, is there’s some big blocks, but there’s mostly lots of little blocks. So my one question is: If we are in the one and a half to two /8 number, and a big provider is told, We’re sorry, we don’t have a /10 for you, the biggest block we have is a /14, can they turn around in a week and say I’d like another /14, I’d like another/14? Or is there a time window? They go to the back of the queue, but if the queue is being filled up fairly quickly, they can just keep coming back for that allocation size. Because it’s one allocation per request, right?

John Curran: Right. But recognize, I guess, if you’re asking the question when we get down to remnants and someone has a large need, okay, they ‑‑ as long as they continue to qualify ‑‑ as long as they continue to qualify, they can still receive blocks. Are you ‑‑ I’m trying to figure out how that ties into this policy proposal.

Kevin Blumberg: How this ties into policy is me trying to understand ‑‑ fundamentally, to me, this policy is about the burn rate and giving people ‑‑ you know, resetting that burn rate to where we thought it was going to be when runout did occur last year. But, as well, what I’m looking at is we have this point at the end any request that reduces the free pool will trigger the reduction, all requests will be three months. But the second part, the part that seems to be missing to me is that we can continue at a fast burn because you can come back as often as you want. And, i.e., we’ve put back in this protection, but the burn will still continue faster than we expected it to be.

John Curran: In theory that’s what should have happened when we went to three months. It did not. Okay? Despite the fact that we should see parties coming in and getting 90 days and showing up in 75 and saying, Here’s my updated application, I’m going to ‑‑ we’re not seeing that behavior.

David Farmer: I think this is to the point here as well. David Farmer, ARIN AC. The waiting ‑‑ if the block you’re looking for wasn’t available, you would trigger the waiting period clauses and all of that. And when the waiting period clause stuff gets triggered, there’s a three‑month ‑‑ you can’t come back for three months kind of thing involved in that. And so there’s a number of pieces that all play together. And so if you wanted a /10 and you could only get a /14 or you were qualified for a /10, could only get a /14, you’ll get that 14. You’ve got to live with that /14 for three months. You can’t come back until three months are up.

Kevin Blumberg: So there is other policy that ‑‑

David Farmer: There is other policy sort of relating ‑‑

John Curran: Existing policy that covers that.

David Farmer: Existing policy that relates ‑‑

Kevin Blumberg: Come back once every three months.

David Farmer: Yeah.

John Curran: And that your last block must be ‑‑ once we give you an assignment, it doesn’t matter, you have to use that block to 80 percent before we’re even going to talk to you about another assignment.

Kevin Blumberg: Thank you.

Rob Seastrom: We have a remote participant?

Stacy Hughes: We do. Hi. It’s Stacy speaking for McTim. R.S., McTim would like to know why a perceived need to avoid being seen as embarrassing should be a driver for Public Policy. And I have two more remote participants after that.

Tim Denton: So the answer is it always is.

Rob Seastrom: Yeah. As Chairman Denton says, it always is.

John Curran: Next participant.

Stacy Hughes: Next is Chris Grundemann, CableLabs, ARIN AC. “I have heard two strong sentiments from the ARIN community during and previous to my tenure as an AC member. One is that predictability as IPv4 rules exhaust must be a primary policy goal. Another is to stop mucking around with IPv4 policy. With those recurring themes in mind, I have a hard time justifying the request to undo the already executed change from a 12‑month window to the current three‑month window by moving back to the 12‑month window” ‑‑ there’s more ‑‑ “only once again to shift back to three months at some point in the next 12 to 18 months, perhaps much sooner with the 12‑month justification.”

Rob Seastrom: Thank you. Is there one more?

Stacy Hughes: Joe Maimon, CHL. “Opposed in concept as written. Soft landing has worked extremely well in altering a runout trajectory. This is a good thing, especially for our region. Flip flopping on this is not in anyone’s advantage except for those who wish to club everyone else. The correct course of action to resolve that situation is for us to share with them.” “With regards to the consumption rate drawdown, the most rational answer is that demand is far more elastic than many people, including Geoff, treat it as.

“In short, it is a good thing that ARIN finds itself able to service its communities’ needs longer than expected. And reversing that, little sense or benefit to the members of this community.” Further, he would really like you to have some clarity as to what the referenced distortions and problems in the transfer market actually could be gotten.

Rob Seastrom: Can you repeat that last question? Just that last sentence, Stacy. I didn’t understand that.

Stacy Hughes: Absolutely. Also Joe would really like it if some clarity as to what the referenced distortions and problems in the transfer markets ‑‑ market ‑‑ singular ‑‑ actually are ‑‑ could be gotten. Joe, that’s kind of a confusing sentence. Can you clarify that for me?

Rob Seastrom: We’ll come back to Joe. Do you want to address that, Owen, before we go back to Bill?

Owen DeLong: I can actually adjust the question I think Joe is asking. I think Joe is asking what are the perceived distortions that the existing policy interacting with the transfer market creates. And, in my opinion, the fact that we’ve now got a 24‑month transfer market and a three‑month justified need environment for ARIN free pool space creates such a strong incentive for anybody trying to operate a business plan to go not to the free pool but to the transfer market that it distorts the runout date and pushes people prematurely into the transfer market as strongly advantageous over allocations from the free pool. And I think that is not a good thing.

Rob Seastrom: Thank you. Bill Darte.

Bill Darte: Bill Darte, ARIN AC. I’m not speaking for or against the proposal, but just making a clarifying point, I believe. Mr. Sinatra asked whether this distortion was actually representative of a greater uptake of IPv6, and I think Leslie’s stats earlier yesterday didn’t bear that out. We’ve had a halving of demand but not a doubling of v6 allocations. So…

Rob Seastrom: Thank you. Jason.

Jason Schiller: Jason Schiller, Google, NRO NC. And this is in response to Kevin Blumberg’s points with regard to the three‑month holding period.

John Curran: Jason, can you speak up, please?

Jason Schiller: Sorry. Yes. This is in response to Kevin Blumberg’s point about the three‑month holding period. Oh. I am opposed to this policy. So the three‑month holding period is only implemented in the event that an organization asks for more space than ARIN can fulfill with a single aggregate. Theoretically, an organization could have demand or need for a /10. They could conservatively ask for a /16, and as long as they can immediately go to the end of the line and get back to the front of the line before they deplete the 16 they just got, they can wash, rinse, repeat; is that correct?

Rob Seastrom: I’m not sure.

John Curran: If their last allocation that they received is 80 percent, then they can come in and do another request. Thank you.

Rob Seastrom: Is that Michael? Or Scott’s ahead of you.

Scott Leibrand: Scott Leibrand, ARIN AC, Limelight Networks. I strongly oppose this policy proposal. I believe we have actually achieved a soft landing and we shouldn’t pitch the nose into the ground. The question of what happened, why we’re using less space than we were before, was a complicated one that gets to human nature and how much time people are spending on efficiency and other things. But I think maybe more relevant is something I’ve heard privately from some large networks that are actually implementing v6 who have speculated that if this were to pass, they may be less incented to continue with their v6 implementation, because they can go get 12 months’ worth of space and they don’t need to worry about v6 for 12 months at that point.

So I think we need to be very careful not to take the ARIN free pool and make a bunch of ISP free pools that have the effect of causing people to delay their v6 adoption or do other things that are less efficient than we might like with IPv4 addresses. I think it is in the community’s interests that we go ahead and use our IPv4 addresses as efficiently as practical and that we ‑‑ if we are left with the riches of the biggest free pool, that we go ahead and get those into the hands of the people who need those addresses, either via something direct, like the returning of the /8 for redistribution, or indirectly, by having the other addresses that are available, such as legacy space, go out via transfer to the regions that need them. So I don’t think this solves the underlying, quote, problem of having more space than the rest of the world. I think it just makes us more wasteful and less efficient and less likely to deploy v6 as strong as we can. So I strongly oppose this.

Rob Seastrom: Mike.

Mike Joseph: Mike Joseph, Google. I still oppose this policy. So I touched on the moving finish line earlier, but I do want to comment on some of the comments that have been made about the size of our free pool relative to the other RIRs. It’s worth noting with concrete numbers that if this policy passes, our free pool will probably be less than three and a half /8s by the time this were implemented. And that’s not that much bigger. In fact, it’s smaller than LACNIC and AFRINIC, and it’s only a little bit bigger than RIPE, which is in soft landing. So I’m not sure where ‑‑ the Board has made it fairly clear that Interop will probably be returned. I think that ‑‑ and we’ve heard that there’s a few more /16s eligible to be returned, and this policy is going to take three months to implement anyway according to staff assessment. So I don’t think we’re as well endowed with free pool space as we might think. I think we ought not focus on that so much. I think soft landing is working and we should allow it to continue to work. I oppose this policy.

Rob Seastrom: Thank you. Michael.

Michael Sinatra: Hi. Michael Sinatra, ESnet. I want to address in addition to Owen’s comment the distortion comment. Anytime you withhold supplies of resources from a market, you’re going to distort that market. It’s just a simple point. That may be good and that may be what we want, but you’re going to distort the market when you do that. So it’s a simple fact that if you are deliberately withholding resources from a market, that you’re going to cause distortion. It’s going to cause the price to go up higher than it would be if you weren’t otherwise doing that. And, again, we may decide that’s what we want. I’m committed on that aspect of it.

But I do think that there are other problems that we need to deal with such as the flight of address space out of ARIN, which is a big concern for people, and we’ve had to do a lot of policy tweaking in order to make sure that doesn’t happen or we don’t have flips or things like that, because we have such a big free pool. If we didn’t have such a big free pool and it wasn’t this obvious thing for people, we wouldn’t have to be doing all this stuff.

Okay, maybe that’s not a big deal. But I’m just saying those are where I see the distortions coming in. In terms of perceptions, whether it’s good or not, perceptions matter. And misperceptions, unfortunately, matter. What people think of us elsewhere in the world is important because it affects how easily we get policies we want coordinated with the other RIRs in other regions. So it’s important that we are showing the correct perception and that we’re doing the right thing. That’s where I see the perceptions mattering. I’m still sort of flip flopping on the policy right now, but still generally in favor of it.

Rob Seastrom: Thank you. Marla?

Marla Azinger: I’m still in support of this policy proposal. But Scott’s remark about a large ISP said that it would slow down v6 progression, I want to make it really clear that’s not Frontier. And when someone makes statements and isn’t willing to say who it is, I always question if it’s the turd in their pocket that gave them that comment or if someone really did. And I don’t want to question ‑‑ I’m not questioning Scott’s integrity, but I would prefer if people, if they can’t say who it was, then not make comments like that, because then it leaves me feeling like I have to come to the mic and say “it’s not Frontier at least.” So, anyway, thank you.

Rob Seastrom: Would you like to respond to that?

Scott Leibrand: Yeah. Marla, it ‑‑ I’m not at liberty to say who that was because they told me as a private speculative matter and it wasn’t “this is what we’re going to do.” So I was trying to couch my comments in terms of the incentives for companies to deploy their v6, not in terms of their actual plan. So, in that context, I think what we need to think about is whether companies that are meeting a current need that they have by ‑‑ or not a current need, but a projected need that they have, they’re meeting that by implementing v6, if by giving them more IPv4 space we might be delaying their need for that and reducing their incentive to do v6.

Rob Seastrom: Counselor?

Steve Ryan: We’re going to do antitrust 101. Antitrust 101 is we’re in a policy process; we do not refer to individual companies. And I’m just going to state it. There’s a reason I sit here all day, which is it’s so you can’t be accused ever of communicating business plans to one another in a way that might affect antitrust issues. So please avoid the use of particularized company names if you could in the way you refer to things. It’s a good way reminder, by the way. We don’t remind you at every meeting. But as an industry association, our right to collective action and to creating policy has limits, and that’s what we’re doing here when we exercise those limits. It’s why you have a board that looks at why the process is followed, why you have a larger AC that insulates this from individual company activity. Thanks.

Marla Azinger: Thanks, Steve. Okay. So if you can’t say the names, what is the most bothersome about it is that when you make comments that are fear‑based like that, because that’s what happens, you say “one large ISP told me this in confidence,” so then everybody wonders, Oohhh. There’s probably a bunch of people that really actually would take that as an incentive, and I strongly disagree with that.

Rob Seastrom: Thank you. Two minutes and we’re closing the microphones. Jason.

Jason Schiller: Jason Schiller, Google and NRO NC. I still oppose this policy. I’m surprised there hasn’t been a discussion of fairness around this policy. There was a huge discussion when we decided to roll down the window from a year to a quarter about fairness. And there was a lot of discussion about an organization might get in line and get a year’s supply of addresses and their competitor organization right behind them in line gets nothing and they’re out in a matter of weeks.

And there was this gap of a year of available IPv4, business as usual, for one organization versus their competitor that was out in a matter of weeks. Because of that, we decided when the ARIN pool kind of looked like it was about a year, more or less, we would stop giving people a year’s supply. We would give them a quarterly supply. And that meant if there were two competitors in line to get addresses and one got addresses and the other didn’t, the inequity would be a quarter, not a year. This would reverse that. Do people think differently about fairness now than they did then?

Rob Seastrom: Thank you. Owen, then Heather, then David.

Owen DeLong: So, first of all, I want to address Scott’s aviation analogy. I’m a pilot. We haven’t achieved soft landing. We’ve pulled up prematurely. And when you pull up prematurely, before you reach the runway, and you’re approaching stall speed, the only thing you can do is apply power and lower the nose; otherwise, you’re going to hit the ground very, very hard in an attitude that is very unpleasant. This policy seeks to do just that. It does not seek to undo the fairness of which Jason speaks. When we passed the previous policy, we fully expected that the day we got that last /8 the ARIN free pool would be relatively empty.

The last /8 would be the last /8 to go into the free pool and there wouldn’t be a whole lot more than that last /8 in the free pool at that time, and going back to a three‑month allocation window would make a lot of sense. Instead, there’s six or so /8s in the ARIN free pool at the time that we did this. And we’ve reduced the run rate much more than we expected to, and we’re going to float past the runway and land somewhere else. This seeks to move that target a little bit, go back to business as usual until we actually get closer to the point where we actually have to roll things back, allow people to use their business plans more efficiently and aggregate things more efficiently until we have to do this for fairness. It’s still about fairness. It still seeks to have those same protections and it still seeks to do a soft landing, it just resets the target point where we pull back to flare the airplane and achieve that soft landing to a place where we’re closer to the runway.

Rob Seastrom: Thank you. The microphones are now closed. Heather, then David, then Marla.

Heather Schiller: Heather Schiller, Verizon. When you cut that allocation window to a quarter, it shouldn’t be surprising that it looks like the address space is going to last you four times as long. So I think one of the questions to consider is what you want the end picture to look like, because changing the allocation window to 12 months could have the effect of pushing the plane faster toward the ground or ‑‑ where is Stacy? There you are. You had this quote once that was great about hitting the wall, and like let’s drive faster into the wall and get through it and get on with v6.

So if that’s your philosophy toward it, then maybe expanding to 12 months will help drive that. And I think the question about how you want to run out, how you want the last bits of address space to get distributed, it’s never going to be perfectly fair. It’s never going to be ‑‑ it’s not going to be like it was at the RIR level where it gets handed out all evenly. The last bits get handed out evenly. And I don’t necessarily think it should be that way. I think that the allocating address space based on need works. And I think that 12 months ‑‑ I think that 12 months is fine. It’s a good planning horizon.

I think what’s a bit more concerning to me, and I go back and forth sometimes, is the discrepancy between the amount of address space that you can get from ARIN and the amount of address space that you can get on the transfer market without the allocation windows being different, and that those who can pay for it can plan better. And I’m not sure that that’s fair in and of itself. And so having a longer allocation window lets smaller providers who can’t necessarily afford it be able to plan better.

Rob Seastrom: Are you in favor or against the proposal?

Heather Schiller: I think I’m in favor of it. But Chris Grundemann almost changed my mind.

Rob Seastrom: Thank you. David?

David Farmer: David Farmer, ARIN AC, University of Minnesota. I don’t buy ‑‑ let’s put it this way. I don’t think we’re all working under the assumption that quartering the allocation window was going to quarter the run rate. And it hasn’t quartered the run rate; it’s halved the run rate. But a lot of smart people, including Geoff and myself and a number of other people in the room, assumed that it would quadruple the amount of time, the number of times you come back, and that the run rate would more or less stay the same, maybe slightly pull up, but only slightly. And it’s pulled up quite a bit. I don’t think anybody can explain that one.

Am I for this or against it? This is a hard one. This is something that we all need to think about seriously, and I can ‑‑ I think right now I do not support the proposal.

But this is a tough one, and I would really like to see a lot of hands one way or the other. This is not one to sit back and let everybody else decide. Please, everybody raise their hand one way or another.

Rob Seastrom: Thank you, David. Marla?

Marla Azinger: The comparison in regards to a competitor getting more address space than the next, we are supposed to be using address space and handing it out when people are actually using the space. So whether or not what size an entity is should not even be part of the consideration, if they are using them and justifying them. That’s a need. It should be looked at need. And no matter what, at some point every time we go through these soft landing phases, someone is going to be the last person. And the next person is going to be that competitor. And what are they going to do? Probably cuss a little and move on.

The concern about reality and what is going to happen isn’t fair. It never is fair. So I think we need to stop being so preoccupied with what’s fair sometimes and look at the fact if things are justified or not, if they’re justified, then let them use the address space and no matter what there’s gonna be somebody that was just that next person that got screwed because the one before them got their request in first. So it’s going to happen no matter what. So wasting time on it and actually writing policy to try and prevent it is a waste of time.

Rob Seastrom: I’ll note that the mics are closed. Can you be very quick, Cathy?

Cathy Aronson: Cathy Aronson. I’ll try to be really quick anyway. The discussion wrapped around what if multiple ISPs apply within a short period of time of each other, like minutes, and they all had verified, justifiable, perfectly reasonable requests, and we were trying, I know, fairness, maybe we shouldn’t care about fairness, but we made this policy to make it more fair and we shortened the window to make it more fair, and, sure, we got more address space than we thought we were going to have. But I’m actually in favor of this policy staying as it is.

Rob Seastrom: Thank you. Mr. Chairman.

John Curran: Thank you very much.

[Applause]

Tim Denton: So in the matter of ARIN‑2012‑4: Return to 12 Month Supply and Reset Trigger to /8 in ‑‑ something or other ‑‑ in Free Pool, those in favor of the proposition as drafted, would you please raise your hands. Thank you. Those against the proposition as drafted, would you please raise your hands. Thank you. So in the matter of 2012‑4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool, in favor of the proposition were 17; against the proposition as drafted, 19. Total number of people voting, 108.

John Curran: Total in the room, 108. Thank you. This will be provided to the Advisory Council for their consideration. Okay. We’re going to move out of that policy block and now we’re going to get some reports updating us on what’s happening in the community. I’m going to ask Elise Gerich of the IANA to come up and give the IANA Report.

IANA Activities Report

Elise Gerich: Well, hello. I’m Elise Gerich. Thank you for inviting me. And I want to particularly thank you for throwing this big meeting to celebrate my second year on the job.

[Applause]

Elise Gerich: I didn’t know North America cared so much, but how lovely. So I’m actually not going to talk much about numbers. As you know, we gave you most of ours. So I don’t have much to say on the v4 space. Though maybe I will next time, depending on your policies. So what I do want to talk about are some of the activities that IANA’s been involved with for continuous improvement and improving things and the way we do them; some new services that ICANN has taken over, the IANA department runs them but they’re not part of the IANA functions; and some of the statistics we’ve been gathering.

So basically for the last two and a half years to three years we’ve been involved in a program called EFQM. It’s a European standard for quality management. And what you do is every year you have some projects that you work on to help improve the quality of the service and the services that you provide, and then you do a self‑assessment. And actually the self‑assessment’s gotten to be much more complex. At first we did it kind of lightweight and we didn’t really know what we were doing, but this last year the document’s like over 90 pages and it has a very strict format and you document areas of service, management, operations, and lots of other things, and then there’s a very strict judging criteria.

So we went through that this last January, and we were quite pleased with our results. We’ve had year‑over‑year improvement of our self‑assessments. And this EFQM can lead to an external assessment, but usually you have your entire organization under this quality management plan and not just one department. And right now IANA’s the only department that’s been following this at ICANN. So some of the things we’ve done is we’ve standardized our process documentation. Not that we didn’t have documentation, we did, I don’t want to make it sound like that, but we have standardized on a process flow charting in a way to describe the narrative.

We’ve done more than 50 percent of our processes. So they’re online. And as we add new people or people leave, we don’t lose institutional knowledge and we have this well documented and we can bring new people on to take on the roles to fulfill the services. Something else we did ‑‑ it’s tiny, but it’s important ‑‑ is that we used to have just one form for applying for addresses, and I guess if we received some more v4 addresses, this will become more important. But we now have two templates, a v6 template and a v4 template, so that you can specialize your request so that if you’re asking for v6, it comes in on the v6 template, and vice versa for v4.

One of the areas we have focused on as part of our continuous improvement is also security and continuity testing. So we did a continuity testing in 2010. And we have one scheduled coming up this summer again. And this is to test that our services have redundancy and we can recover quickly. Say if there were an earthquake in Marina del Rey. Knock on wood that that doesn’t happen, but it’s been known to happen in California. Anyway, these are just things that we plan on and we test to make sure that we can meet some normal service recovery requirements.

And customer survey. And I guess, from what I understand, ICANN and IANA have never done this before. So you all may ‑‑ can I see a show of hands of anyone who has received the customer survey that we sent out? Small number of you. Thank you. Hopefully you’ll return it. But we have sent out a customer survey to the leadership of the NRO and the ASO as well as the ccTLDs and the IETF leadership and anyone who has been an RFC editor, because those are the services under the IANA functions.

And we’re hoping to get a good response. It’s a short survey. It’s only five questions. So it doesn’t take a lot of time. And we’re hoping that we’ll be able to use this to pinpoint some of these activities that we continue to do to try and improve the services that we offer to the community.

So reliable operations. Primarily I’m going to talk about DNS and DNSSEC here. So, as you know, the root was signed about a year and a half ago. And we have key signing ceremonies every quarter. The seventh and eighth key signing ceremonies have taken place. These are fully online. You can see the transcripts and what happened, and there’s streaming video during the key signing ceremony. Obviously someone stands in front of the safe so you can’t see them open it.

But, other than that, you can see everything that goes on in the key signing ceremony. And there are many members of the community that volunteer their time to come and be witnesses so that ‑‑ there’s one who just raised his hand, thank you. So if you want to know, you can ask him what it’s all about. But these ceremonies used to take about eight hours, and I think we’ve gotten them down to about three, two, two and a half to three hours. But it’s interesting to watch. You should watch the streaming live video. At least a one‑time watch. I don’t think I’d do it more than once. Well, I mean, unless you really have insomnia or something.

So one of the things about DNSSEC and maintaining the security of the keys, et cetera, is having an audit, SysTrust audit. So we’ve now had our second SysTrust audit, and we passed with flying colors. So we had one the first year, and this is the second one. And we obviously will have these annually. But this is to ensure you that we’re doing the right things to maintain the security of DNSSEC.

New services. ICANN ‑‑ I guess ICANN has been asked on occasion to take on new services, and the IANA is the department that’s actually operating the new service, and this is the Time Zone Database. And some of you may have heard about this. I think it was last fall. There was a lot of excitement. There’s a very good group of volunteers that have been maintaining the Time Zone Database for over I think 25 years. They decided to retire, and the IETF decided to find someone, some organization to take their place. They came to the IANA department. We said we would do it if they can convince ICANN, and ICANN said of course.

So that was all in process, and then someone decided to take the volunteers to court, and that had to accelerate the process. So the volunteers that had been doing it for years and years and years stopped the service very briefly. Within I think 24 hours, the IETF had contacted us. We said we’ll do it and work out the details later, and the details have been all worked out. IANA on behalf of the IETF and ICANN is now running the Time Zone Database under the direction of the IETF, and this is a new service that we’ve taken on.

Some statistics. So this map represents where DNSSEC has been deployed. And TLDs. Only TLDs. Not second‑level TLDs, et cetera. So the green on the map represents TLDs that have signed their TLD as well as put a DS record in the root zone. And then there’s a few little orange specs ‑‑ they look kind of yellow, too ‑‑ out there, and those are folks who have signed their TLD but they have not yet decided to put a DS record in the root zone. So you can get ‑‑ it fell off. There used to be a URL down there so you can find the real data instead of just a graphic.

And IPv6 and IPv4’s been a big topic here. And so this is a small representation of ICANN’s yearly average of World Wide Web queries using v4 and v6. That little sliver is the v6 sliver. The rest is primarily IPv4. I should let you know that we are registered with ISOC for IPv6 World Day. We have IPv6 completely deployed on our servers and available, so it doesn’t have to be a sliver. But obviously most people still access us by ‑‑ or ICANN by v4. And you can hardly tell any difference here. But I think that the IANA service has a bigger piece of the pie. So we’re pretty evenly distributed.

And this is the IANA yearly average, and this chart was a bit bewildering to us, because it looked like we were having a lot more v6 queries at the beginning of the year. And we thought: What the heck happened? Why did it drop so drastically or why did v4? Did more people get more v4 addresses so therefore there’s more people we can query?

Turns out we’re not really sure. But what we think happened is we discovered there were a bunch of registrars out there with misbehaving tools and that they were coming and querying us over and over and over again. And, incrementally, as the tools were fixed, we had fewer queries and we had fewer v6 traffic. We’re not sure that’s the only reason, but it seems to be the most logical at this point in time.

And unless you have better eyeglasses than I, you can’t see any of those little blue URLs. I’ll have to figure out why I squished it so much. But basically if you go to the stats page on ICANN.org, we have a whole bunch of statistics now that you can look at, some of them on TLDs, some of them on IPv addresses, some of them that point to your websites about allocations and IN‑ADDR.ARPA stats. So these are things we’re putting online as a service to the community. And I want to thank you very much. And if you have any questions, I’m happy to take them, but I suspect you don’t.

John Curran: Any questions for Elise?

Thank you very much, Elise.

Elise Gerich: Thank you.

John Curran: Okay. It is now 3:00, virtually. And we’re actually right on time for our break. So we’re going to have a quick refreshment break out there. We’ll come back in. We’re a little behind in reports, so in order that we do not lose time, I ask people to take 20 minutes, be back here at promptly at 3:20. We will start at 3:20.

[Break taken from 2:58 p.m. to 3:20 p.m.]

John Curran: So, folks, we have 20 minutes to do three presentations, Louie, myself, and Axel, and then we’re going to be back on schedule at 3:40. So let’s start out with Louie, and he will come up and give the NRO NC Activities Report.

NRO NC Report

Louie Lee: First a little refresher, who we are and what we’ve done for you lately. The Number Resource Organization is a vehicle for RIR cooperation and representation. Among the several things we do, we fulfill the role and responsibilities and functions of the ASO within the ICANN framework. Within this ICANN framework, there are a number of supporting organizations and advisory committees, such as the GNSO, whose members operate the registries and registrars of the generic top‑level domains; the ccNSO, whose members operate country code domain name registries; and the GAC, who is the advisory committee made of government representatives to provide input to the ICANN process.

The ASO is one such supporting organization for the addressing community. The NRO Number Council’s sole function has been to serve as the ASO Address Council. This is where I switch from the NRO NC to the ASO AC. We as the address supporting organization and, specifically, the Address Council do our part by overseeing policy work for the IPs and ASNs; appoint directors their seats 9 and 10 to the ICANN Board; serve on the ICANN bodies, such as the Nom Com, review teams as required by the affirmation of commitments, which is the letter signed by the ICANN and US Department of Commerce for continuing operation of ICANN independent of the US government contract; and we also advise the ICANN on a number of resource matters such as IPv4 and v6 addresses, ASNs, and the recognition of new RIRs.

The ASO Address Council is a 15‑member body made up of three members from each of the five RIR regions. We are elected and appointed within the stakeholders of each region community, and the stars next to their names show who are the members who have been appointed. In the ARIN region, each of the three members serve a three‑year term. I’m now on my ninth year on the ASO AC and my fifth year as chair. My own term will be up at the end of this year. So what have we done for you lately? Several years ago the IP addressing community recognized a need for a global policy to provide IANA a mechanism to receive recovered IPv4 addresses and redistribute them to the RIRs for use by the global Internet community.

The third version of a policy proposal to address this issue, known as 2011‑9 in the ARIN region, does so by establishing a recovered IPv4 pool for all address blocks that are returned by any mechanism and then reallocating those addresses evenly across all the regions on a regular basis. It does not govern any mechanism by which an RIR would return recovered or unused space. The IP addressing community reached global consensus on this latest version of the global policy proposal earlier this year. We sent the text of the proposal to the ICANN Board about five weeks ago, which kicked off a 60‑day countdown during which the Board may either accept the policy proposal, reject it, request changes, or take no action. If the Board takes no action, then by previous agreement the policy proposal will automatically be ratified.

ICANN’s 21‑day public comment period closed on February 4th with no comments posted. We expect the ICANN Board ratification to happen with no issues within the next three weeks. I’m sorry, I’m a slide behind. Here we are. In the past couple of ICANN meetings, the ASO and the ASO AC held sessions with the ICANN Board, the GAC and other SOs and ACs for update and exchange of ideas. This is part of the effort to inform ICANN community of the stewardship and work that the RIR communities have been doing with a global perspective and not just a regional perspective.

We have been having meetings with the Security and Stability Advisory Committee to begin collaboration on work that covers both groups, and during the last ICANN meeting we introduced ourselves to the at‑large advisory committee and invited the regional at‑large organizations to our RIR meetings. So for a couple of years now we’ve been holding workshops at the ICANN public meetings to try to inform the ICANN community about activity in a numbering world by describing our recent regional and global policy activity and outreach efforts. Much thanks to Elise Gerich for providing the IANA updates during these workshops. We’re nearing the end of our process to appoint an individual for Seat 9 for the ICANN Board.

So Seat 9 of the ICANN Board is currently occupied by Ray Plzak. We have four candidates for the next three‑year term to begin middle of this year: Eric Brunner‑Williams, Martin Levy, William Manning, and Ray Plzak. Some of these candidates have been invited for face‑to‑face interviews this Thursday and Friday. We have extended the comment period through this Friday morning, so we continue to welcome your comments either publicly or privately for these candidates. You will find a link to post your public comments on our website, aso.icann.org. This concludes my report.

[Applause]

John Curran: Any questions for Louie? Thank you, Louie. Next up is the NRO Activities Report which I will give. With the remote. Thank you, Louie.

NRO Activities Report

John Curran: In addition to being ARIN’s president and CEO, I’m one of the five RIR executives that sit on the NRO, Number Resource Organization, Executive Committee. The roles of that committee rotate. This year I am chair, so I’m giving this as the chair of the Executive Council. I’m going to go very quick. People who have had the privilege of maybe being at an another RIR meeting recently have seen remarkably similar slides. So you don’t need to go through it again, but if you have questions, find me at any time.

The NRO is the vehicle for inter‑RIR cooperation. It’s a lightweight unincorporated association that we work together; we rotate the duties, as I said; we protect the unallocated number resource pool; we promote and protect the bottom‑up policy development process; we act as a focal point for the Internet community on input into the RIR system; and we fulfill the role within ICANN of the Address Supporting Organization. We have one executive committee with one appointed representative from each RIR plus RIR Board and staff observers, three offices that rotate. Decisions are by unanimous agreement. Secretariat rotates as well. The secretariat for the organization rotates with whoever holds the ICANN ‑‑ with whoever holds the NRO EC secretary role. And we have coordination groups that slice across the RIRs in areas like engineering, public affairs, communication, registration services.

The executive committee. I think we all know the executives of the RIRs: Adiel for AFRINIC; Paul Wilson, who is here, our APNIC secretary; myself for ARIN; Raul for LACNIC; and Axel for RIPE. Secretariat this year is hosted by APNIC. Okay. So within ICANN the NRO serves the function of being the ASO, the Address Supporting Organization. We were ‑‑ at the beginning of ICANN we were part of the original bylaws, and the role is to act as that coordinating body within ICANN for global policy, also to be responsible for choosing representatives to be on the body ‑‑ on the various ICANN bodies and advise ICANN Board on number resource policy.

Louie gave an at‑length report on everything that the ASO is doing, the people in it. The NRO actually finances that activity and we also put money into ICANN to help its operations, because ICANN doesn’t have enough money and taking it from the RIR system makes sense. No.

[Laughter]

John Curran: Back when ICANN was very, very small, our contribution was very significant compared to the total budget. Over time what has happened, of course, is ICANN’s gotten very large, and the DNS industry is very significant. We still contribute the same we have. We’re a small percentage of ICANN, and hopefully we represent a small percentage of the expenses compared to the total organization. That works out to about $800,000 a year, which is divided up among the RIRs according to a formula. The formula is based on the resources assigned in each region.

We have been actively participating in ICANN. We hold ASO workshops to keep people informed of all policy activities. We meet with the boards and the various constituencies and supporting organizations within ICANN to explain what’s happening in the regional registries and tell them how they can get involved. We ‑‑ also as part of ICANN we have a review that comes up every three years. It’s called the ASO Review. It’s third‑party review that’s performed and asks the question of how we’re doing as an ICANN coordinating body. In fact, the draft of that report is on the ICANN website. It was put out for public comments.

We’re busy drafting the reply to that now. And it’s mostly just better communication between us and ICANN. We got a review that was generally a positive thing and I think actually pointed out some places where we can do a little better, and the NRO is looking at those right now. We recommended ‑‑ as Louie said, we sent a global policy to the ICANN Board for their consideration. That’s kind of the big thing that we do within ICANN as the ASO is work on global policy, and it’s good to have one go to them every now and then. We hopefully should hear back one way or the other on the global policy for return and reissuance of address space.

The NRO is active as an outreach body in a number of functions. IGF is probably one of the larger ones, the Internet Governance Forum. We provide financial support through the NRO. We are also responsible for helping the organization of it. We actually have people who sit on the advisory group that helps set the program for the IGF and the structure of it. This is now ‑‑ Paul Rendek and Paul Wilson will be sitting as NRO members on that group.

There’s a big meeting coming up, the seventh IGF. It meets annually. It will be in November. It will be in Baku, Azerbaijan. I think I got it right. Close enough. We’re proposing a number of workshops. There may be other people proposing number resource workshops. Those will end up being combined into a set of workshops. It’s actually a very interesting process to watch.

But it’s how we get the outreach about the number system to a much, much larger audience. Internet Governance Forum has people interested in governance matters of the Internet from all over the world, and they’re not specific to domains or IP addresses.

Very interesting body for discussion. And, hopefully, if things come out of that that need to be done, they move back into the policy processes in the RIRs and ICANN.

We’re working with the United Nations, their CSTD working group, which is providing a review and oversight of the IGF. We’re working with the OECD. We’re working with the ‑‑ we’ve engaged with the ITU Secretary General to appoint people to the World Telecommunications Policy Forum. That’s a group that will help set the agenda and the process that’s going to be used at WCIT at the end of year in Dubai.

Geoff mentioned that in his presentation. We had a Board member mention it as well. There’s a significant ITU meeting to look at the international tariffs for communication, and this is the group that helps develop that agenda. And we’ve also reached out directly to the ITU and said we’re interested in working together on IPv6 outreach and capacity building. We this year established a Public Affairs Coordination Group. As opposed to the Communications Group, the PACG is responsible for things like figuring out what we say in a letter to ITU and similar things. It’s a good thing to have because we have a lot of relations with governments this year that we want to spend some time on.

We’re doing RPKI project planning and joint coordination among the RIRs and making sure that we’re ‑‑ as we run out of IPv4 space, making sure that the address registrations and any record upkeeps that need to happen happen in a timely manner.

So we’re doing a review of how blocks are registered and to make sure things like the ERX Project, is that really complete, are all the addresses reflecting the right registry.

That’s my whole report. I will take questions. We’re going to have a report from Axel right after me. But questions on the NRO? Axel, you’re getting up to give your presentation, right? If you’re asking me a question…Thank you. Thank you very much.

[Applause]

Axel Pawlik: You surely can talk fast.

John Curran: Yes.

RIR Update: RIPE NCC

Axel Pawlik: I’m Axel. I wanted to show you a photo of the water feature in front my office. I don’t have a nice one, though, so I went with a corporate slide there. Well, and you wouldn’t want to bathe in there anyway. Right. Up, down, left, right?

John Curran: Right.

Axel Pawlik: Alright. We did a RIPE meeting last week, and that’s probably the reason I’m sounding a little bit funny; I’m recovering from the post‑RIPE meeting cold. We did talk quite a bit about policy proposals, obviously, as we do. Some of them are maybe of some interest to you, others not that much. We’ve seen ‑‑ was it 2012‑1, the inter‑RIR IPv4 address transfer proposal, which we discussed on the Mailing List quite a bit as well. Heated discussion. There was the word “sales” in there and selling and stuff like that. People didn’t really like it that much. It was discussed, it was abandoned, and there’s new stuff coming up. Basically what you think is entirely reasonable to have, a transfer policy for transfers into RIR.

The relevant regional policies should be observed. So for stuff coming into the RIPE region we would like the receiving party to fall under the RIPE community policies on the other side if we transfer out of the RIPE service region. Again, that would bail out ‑‑ and the transfer policy, the inter‑RIR transfer policy should be a transfer policy, should be in place in both of the regions. Then we had a request to change the number of months that transfers are looked at in terms of demonstrated need. Currently we’re under the soft landing policy there would be three months. That sort of is not very sensical in the transfer policy. So that should be changed probably as well.

Those things are not yet in the formal Policy Development Process, but we’ll put them in there and we’ll discuss them further on. Some more local things. Yes, I’ll skip. A new thing that we heard about for the first time in the RIPE meeting was the IPv6 maintenance document. Basically saying v4 is fairly dead. We have lots of policies and lots of things dealing with that. Why don’t you write it all up in one document and be done with it? So all you ever wanted to know about IPv4 address dual chip in one document. It’s not a policy proposal yet; it might become one. We’ll see how we continue with this.

Also in Vienna, the RIPE meeting we did before this one, I discussed what you wanted to do with legacy holdings. We want, of course, them to be part of the registry, properly updated and all that. So we reached out to the legacy holders in our region, have done quite a bit of contact there, have received some contracts and some of the resources back. But there were some of the really old legacy holders from way, way back that said, well, you know, we should ‑‑ I don’t know whether we want to subject our legacy holdings under community policies. So we want to discuss that. So that’s going to be discussed soon. Also interesting. Similar to what APNIC has done and you are doing here, what ARIN is doing here, we are changing our business processes for the hot days before we reach the final /8. And it will show up here in a little bit.

Three phases. We’re currently in Phase 0. When we think we are one month from reaching the last /8, we enter Phase 1. That would be basically these measurements we’re taking, also just more eyes looking at resource requests and the like. Basically being very, very careful that we do the right thing, as you are doing the same thing here. Then, of course, you know that we do lots of information services, lots of data accessed in various ways. We think this is going to be a bit confusing or is confusing, as we’ve heard that also from our stakeholders that filled in the membership survey.

Basically what you want to do is straighten the whole thing out a little bit. And I call that the four arrows: enter RIPE Labs, RIPE Atlas, RIPE Stat, and LIR Portal. Basically starting with the LIR Portal on the bottom. This is the entryway for our members to manage their resources and to deal with the RIPE NCC. Then we have RIPE Stat. That’s basic specifics, history and realtime data on any numbering resources. Then we have RIPE Atlas. Basically it’s the renewed measurement platform that we’re doing at RIPE NCC state of the network, big picture. But also we just rolled out last week very, very carefully the ability for individuals to do their own measurements on that system.

And of course we have RIPE Labs now for quite some time for general stories, statistics, and whatever comes up. Now, people are already for many, many years running test traffic measurements on machines that are fairly creaky by now and outdated and not quite falling apart, but we expect that to soon ‑‑ to happen quite soon. So we don’t want to renew those anymore. We want to roll the TTM measurements basically in one or the other sense into RIPE Atlas. We are coordinating this very carefully with the current hosts and users of those measurements. I think that’ll go fairly straightforward.

Also this DNSMON is currently based on TTM machines. And of course those are about 60, 70 machines that we have there. We have on the order of one and a half thousand Atlas probes out, so that will be running even better on the Atlas platform. So certification. The last RIPE we heard our members say, oh, we want you to be very, very careful. Very formally at the general meeting they had a vote there saying yes, continue development, but please, please make sure that the operators ‑‑ that we, your members, are independent from whatever authorities are out there trying to take our autonomy away. So we listened to that.

We have continued development of the validator system. That basically aims to take all those considerations into account and to cater towards them. We have had a very long ‑‑ not a very long, but extensive presentation on this last week. There was not that much discussion. It felt a little bit like the concern was not that strong anymore. So maybe we’re doing something right. That would be great. We’re continuing it. Of course we are happy to share with the other RIRs, as we have done before, software. That is the graph. We have quite a number of certificates out there, reaching the thousands, nearly, which is really great. Of course more than 600, so this is a much stronger adoption of the system than we expected, really. So great.

Charging scheme task. Oh, yeah, we tried to get a new charging scheme for this year. That was also in Vienna. That didn’t go through because basically people said you want us to pay more; tell us a little bit earlier in the year so we will know. That means running on the charging scheme from last year, which is great because we make more money this way. Okay. Fair enough. We had a Charging Scheme Task Force from the community, from our members, basically giving ‑‑ writing up the report, deliberating among themselves and giving some input to our executive board, which now has to look at that data and decide further action. There’s a timeline for the charging scheme for next year, and probably there will be one for 2014, relatively soon as well.

So interesting things. What I’ve been hearing on occasion is: Where is Rendek? Paul Rendek, our ex comms manager, he’s still there. He was with us in Ljubljana last time. We had a fun photo session. The photograph of us very, very happy. Maybe the beers helped a little bit that we had before that. So second from the right is Paul. He now is our man in Dubai. He does intensified regional outreach, because he does that very well. Basically the idea is to liaison with the Middle Eastern community and also with the ‑‑ couple other independent states, Russia, the Ukraine, all those countries in that area.

He helps coordinating or setting up the Arab IGF. He has been put onto the multistakeholder, MSG, something, support group. It’s not the A. It’s an S, I think. But, anyway, the same idea. He has been successful in getting the local regulators from the Middle East, many of them, to consider and subscribe to an orientation event in Amsterdam in our offices that will happen in July, I think. That’s a great thing that you get to come. And basically Middle East is going fairly well.

The more Eastern countries are very opaque and very difficult to understand, so there’s a challenge. Of course you’re all welcome to come to Amsterdam later this year in September. It is ‑‑ it’s not the Kras. It’s a new hotel. Not a new hotel, but a different hotel from usually. Should be nice. If you have any questions, I’ll be around until tomorrow lunch. Thank you.

Scott Leibrand: I have a question on Slide 6, the v4 maintenance document. From reading your mailing list, that seems like something that was conceived of as a administrative cleanup, but then the people are saying, well, no this actually changes policy quite a bit. What’s the story there?

Axel Pawlik: The idea was to gather up all loose ends lying around and make the one authoritative document about IPv4. Now, there are some policies and just sticking them together might not work properly. We heard the concerns that this might actually be a touchy policy issue, so we’ll throw it open into the PDP. That’s fine with us. It was meant to be just good housekeeping, but if you play with policy text, then it turns nasty quickly. Thank you.

John Curran: Thank you, Axel.

[Applause]

John Curran: Okay. Almost back on schedule. Very close. Okay. The next report is the Policy Experience and Implementation Report to be given by Leslie. Leslie, come on up.

Policy Implementation Report

Leslie Nobile: Good afternoon, everyone. We’ll start with the Policy Implementation Report. So basically this ‑‑ the purpose is to present a quick overview of the recently implemented policies, the ones we’ve implemented since the last meeting, and then we’ll provide some relevant operational updates or stats on some of the existing policies, sort of some follow‑up on policies that have been in place for a bit that you may be interested in seeing some stats on. So the recently implemented policies. There have been four since the last ARIN meeting.

The first was remove single aggregate requirement From the Specified Transfer policy. And this basically allows the transfer of multiple prefixes during an 8.3 transfer, and obviously this one has been used and continues to be used. Combined M&A and Specified Transfers. This enables transfers to specified recipients during an M&A transfer. And I don’t believe that actually has been used at this point. It was recently implemented, probably a month and a half ago. So third one is clarify justified need for transfers. And this moves a policy requirement that was previously ‑‑ it referred to 8.3 transfers, but it was in Section 4.

Really didn’t make sense. So moved that reference back into the correct section of NRPM, 8.3. And then set transfer need to 24 months. And this allows a 24‑month supply of addresses to be transferred under 8.3 transfers. And that one, again, that has been used in recent past. So just some older policies. Not that old, but some older policies. A few stats on this. There’s been discussion of IPv6, so I thought I’d show this one. Better IPv6 Allocation for ISPs. This basically put in some very clear criteria and essentially made it easier for ISPs to get larger blocks of IPv6 addresses on the nibble boundary. And what we’re seeing is that we’re continuing to issue mostly/32s, even though the policy makes it easier to qualify for larger prefixes.

So that little table at the bottom will show you that since the policy was implemented in September of 2011, 93 percent of what we’re issuing is still /32s; 5 percent, /28s; and 2 percent, /24s. And we haven’t issued anything larger than that to date. So rework of IPv6 assignment criteria. So this is the IPv6 assignments to end users. This also puts some very clear specific criteria for assignments to end users based on the nibble boundary as well.

And what we’re seeing with this policy is that we’re now assigning a much wider variety of prefixes since we implemented in March of 2011. Lots of little numbers there. But basically there’s a comparison of before the policy and after. And before we were issuing ‑‑ 79 percent of what we issued was /48s, and now only 58 percent are. And 23 percent of what we issue are /44s, and 13 percent are /40s. So it’s just a whole wide range. People are qualifying for the larger assignments at this point under this policy.

This one we brought up on the mailing list last week, I think, IPv6 Subsequent Allocations for Transitional Technology. People were curious if it had been used since it was implemented in January of 2010. Yes, it has been. There’s been seven 6rd allocations made, three /24s, three /28s, and one /32. And I think that’s all I have for the policy implementation. Are there any questions before we move into the next part?

John Curran: Any questions on the policy implementation? This is where we give you feedback as to how the implementation is going. Okay. Keep going.

Policy Experience Report

Leslie Nobile: Okay. So the Policy Experience Report. So this is the staff’s chance to give feedback to the community on how policies are working: Are they working as intended, are there some problems with them, what’s going on with them. So we basically review our existing policies, and we’re looking for ambiguous text or inconsistencies, gaps, effectiveness: Is the policy doing what it is meant to do, is it working correctly.

And we identify areas where new or modified policy text might be needed, and we base this on our operational experience. Obviously this is what we do day in and day out. A nd on our customer feedback. If we see customers having the same glitches in policies, then maybe there is a problem. Then we’ll provide feedback to the community and make recommendations when appropriate. And we also will ask questions. There’s a combination of questions and suggestions in this report, actually.

So we reviewed three policies this time: Reassignments to Multihomed Downstream Customers, Section 4.2.3.6 of our NRPM; Reassignment Information, and that is Section 4.2.3.7.1 of NRPM; and then 4‑Byte ASNs, our favorite topic, which we’re just going to review again. I think this is the fourth time I’ve done it in a Policy Experience Report, but it seems to be needed so we’ll keep going. So Reassignments to Multihomed Downstream Customers. This is the relevant text. This is what we’re sort of focusing on. “This policy allows a downstream customer’s multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements.” So multihoming is the sole reason for issuing a /24 to a downstream customer.

So this is recent. Recently we just identified this as a potential loophole. It seems to be working very effectively all along since implementation years ago, but a recent loophole was identified where a customer can possibly game the system. They can ‑‑ by setting up two different Org IDs, legitimate ORGs, they get an ASN for each one and then they issue each one of their customers on either side, both one ORG or both ORGs, a /24 and they claim their two companies, the two companies they control, are the upstream providers for each customer. It’s pretty hard to dispute. They show us contracts and, there you go, they have ‑‑ their customers have two upstreams. So basically an ORG who wants to sell a /24 as part of a service plan can do so and still be in compliance with the policy even though their customer has no ASN, no router, and is not really multihomed.

So we have a suggestion on this one. We think that the language could be tightened up in that policy and rewritten and made to be much more concise and include the phrase “Downstream customer must have their own ASN and intend to originate a route announcement for the /24 from their own routing equipment to each of their BGP peers.” So it’s just suggested text, but something that we think would be effective in correcting that loophole. The second policy, Reassignment Information. So the relevant text is: “Each IPv4 assignment containing a /29 or more addresses shall be registered in the Whois directory via SWIP or a distributed service which meets the standards set forth in Section 3.2.”

So the new language now refers to SWIP or distributed server as reassignment methods. And it doesn’t make any mention of RWhois. The previous version of the policy said reassignments can be made by via SWIP or RWhois. Two very specific items. So what we recently found is that this is being misinterpreted. This whole concept of distributed server is being misinterpreted by some customers to mean that reassignments can be made via any type of distributed server, including an Internet routing registry, which we are not really set up for at this point.

So if data is in an IRR, then it’s basically hidden, undiscoverable, because no one knows where to look. We just don’t have the ability to collect that information right now.

Our ORG template ‑‑ template, sorry, sorry ‑‑ ARIN Online, our ORG service, asks for ‑‑ has a field for an RWhois server. If you’re going to use RWhois as opposed to SWIP, there’s a field in there. But that’s all. Just for the RWhois. So we won’t know where to look for an IRR. So the question for the community, we don’t have suggestions, but we really want to know what the real intention of the policy was. So was it the intention to allow alternate ways of displaying reassignment information in addition to SWIP and RWhois, and, if not, should the policy be amended to refer only to ARIN’s Whois, via SWIP or REST, or RWhois as a reassignment method.

The third policy is the one that we love. IANA Policy for Allocation of ASN Blocks to RIRs. The text that’s relevant here is: “After December 31, 2010, IANA and the RIRs make no distinction between 2‑byte and 4‑byte ASNs and will operate from an undifferentiated 32‑bit pool.” So the way that we implemented this prior to this policy, we were offering a choice of a 2‑byte or a 4‑byte. That was what you got when you came in. We said: Do you want this or do you want this? What we found is that most of the customers immediately turned around and exchanged their 4‑bytes for 2‑bytes. And the reason is upstream says their router won’t support a 4‑byte ASN.

So at one point in time, I think for the year or so we were doing this, we had issued a total of 85 4‑byte ASNs. And 50 of them were exchanged, and that’s 59 percent of them were exchanged, for a 2‑byte. And the total that are still registered are 35. And I think you heard Geoff mention that there’s only 19 of them being routed in the ARIN region at this point. So our current practice with this new policy is we issued from a single pool 2‑bytes by default, basing it on lowest to highest numbers.

So we have questions for the community: Is there anything that ARIN can do to help with the transition to 4‑byte ASNs?

And we had a couple of ideas that maybe we could sort of force the 4‑byte ASNs out there again. Should we revert to offering a choice of 2‑byte or 4‑byte. Should we issue 4‑byte ASNs by default. There are three other RIRs that are issuing them by default. Seems to be working. RIPE and LACNIC seem to be particularly successful with their 4‑byte ASNs being issued and routed and used. APNIC, I think there was a slow uptake on that and they were getting a lot returned initially, but I think it’s getting better in that region. So that’s a potential. And are there other ideas. And really the question is ‑‑ and I think John asked this on the List not so long ago ‑‑ what else can ARIN do to help with this? So that’s really our questions on this one. And that’s all I have.

John Curran: Are there questions? This one’s got to generate questions.

Scott Leibrand: Scott Leibrand, ARIN AC. I believe the intent of the distributed service reference is to refer back to 3.2, Distributed Information Server Use Requirements. It’s RWhois.

Leslie Nobile: Does it say that?

Scott Leibrand: It describes an operational service that I thought was an RWhois service. I haven’t read through this in the last two minutes.

Leslie Nobile: I don’t think it says that. We got a pretty vehement argument from a customer about that. So that’s why we’re bringing it to you.

John Curran: Scott, if you believe it’s an administrative change to change, you think the AC believes that, that ‑‑

Scott Leibrand: I don’t know yet. I’ll look into it.

John Curran: Okay.

Leslie Nobile: Thanks. I think Chris is at the back mic. Yeah?

Chris Morrow: So I have three questions really which are sort of all one question. How come all this data is not more available to the community, all this data about what assignments are made? Why is that not available? In some form other than an RSS feed, which I understand is available, and it’s quite nice, but ‑‑ and I guess I don’t look at whatever Geoff pulls his data from ‑‑ Okay. Does that include the ‑‑ what policy number was used to do the ‑‑

Geoff Huston: No.

Chris Morrow: No? Okay. How about that? And then the disposition about the data ‑‑ or the data about all requests that come in, whether they get denied or end up with an allocation, why is that not also available? I guess the reason I’m asking is it seems like a lot of times we end up in the policy discussion about, oh, let’s ask Leslie. What’s up with this? And then Leslie goes: Dadadadada, 75. We go: Great.

[Laughter]

Chris Morrow: But there’s no understanding of what does that mean, right? A number 75 in isolation is just like ‑‑

John Curran: So actually it’s a wonderful question. And there’s been discussions internally about instrumentation of the request processing process to record some statistics. It’s actually pretty simple to do, but it’s not necessarily inexpensive to do on an ongoing basis. And so I’m a little hesitant. People keep whispering in my ear: John, you’re at the end game here. The v4s go out, the v6s go out, and then no one calls you. You guys sit around like the Maytag repairman waiting for that new IPv6 request to come in. And if that’s the case, going in and doing extensive instrumentation to peruse the data, you sort of scratch your head and go, well, you’re doing it but it’s way too late to be useful.

So I definitely would recommend people start thinking about this and providing guidance.

I actually ‑‑ I get nervous when someone says things are going to get quiet, you don’t need this data. And I would support that sort of request for more instrumentation. But don’t underestimate the cost of recording it and then either getting it out in a form that other people can use or getting it in user presentative form. There is an ongoing overhead you’re allowed in the organization. So I think it’s a great idea. I just need everyone to think about where we are and tell the Board if you want it.

Chris Morrow: Is this one of those do a suggestion things? Is that what you’re saying?

John Curran: Or just talk amongst yourselves and find Board members and say you want it.

Chris Morrow: Okay. I want this.

Mike Joseph: Suggestion has been entered.

Leslie Nobile: Kevin, I think, is next. Yeah, Kevin.

Kevin Blumberg: Kevin Blumberg, ARIN AC, The Wire. I sup‑ ‑‑ no, sorry. A little bit of humor. 93 percent of statistics are made up. That’s the classic line. In this particular case, I agree that we should get some more useful data. But if we go back a couple of slides, you were talking about the number of 4‑byte ASs, and 59 percent actually looks really good, but then you get that extra little piece of information from Mr. Huston in the back and you find out that that number is closer to 25 percent who are actually utilizing it. So I do think that asking the community before you decide what the statistical metrics you’re going to use are or what the questions are, maybe ask the community what type of questions they are looking for so that we can get some data that is appropriate.

John Curran: And I want to be very clear. There’s asking us to instrument the request process, which would have us record every request, what it was coming in against, what its exit code was, and what NRPM line it hit when something happened.

We could do that and we’ve talked about it and it’s not a small job, versus I’d really like to know for the next three years more stats on ASNs. Like if you see on ARIN on the website, we have, for example, IPv4 and IPv6 end user and ISP requests and requests approved. And we generate those. It gives me something to ask Leslie for all the time, to generate more graphs. So we do that for IPv4, we do that for 8.3 transfers. If you want particular areas of more stats, that’s good to know. If you want us to boil the ocean and have a rigorous approach to collecting stats for the request processing, that’s a different thing and also good to know.

Kevin Blumberg: Understood.

Leslie Nobile: Can I clarify one thing, Kevin? 59 percent of those 4‑byte ASNs are exchanged. They’re not out there.

Kevin Blumberg: No, I understand. What I’m saying is that that number is actually much higher if you look at who’s actually using them. So it’s sort of ‑‑ it’s hard to gauge, but 59 percent exchanged, which means that 41 percent should be using them, but in fact it’s not 41 percent. It’s more like 25 percent are actually using them.

Leslie Nobile: Exactly right.

Kevin Blumberg: I had one other quick question. Leslie, we had talked last experience report about 4.2. ‑‑ oh, where did it go? ‑‑ end user multihoming and where if you had smaller than a /22 and you came back for a subsequent allocation, you had to return it until you reached a /22 in size. And your last report it was a grand total of one person had been brave enough to come back and renumber their entire network.

How has that changed in the last six to twelve months since the last report?

Leslie Nobile: Since the last report, a total of five people have come back.

Kevin Blumberg: Statistically the number that have used make it the same as the one?

Leslie Nobile: Pretty much, yes.

Kevin Blumberg: Okay. Thank you.

Leslie Nobile: I think Marla’s in the back.

Marla Azinger: So there’s I think two slides. There was one ‑‑ I remember that alternative wording that came up, and I stood up to the mic and I said why doesn’t that say RWhois, and I was told because it means the same thing. I sat down and felt kind of stupid. And then questioned it again, but didn’t come to the mic and asked somebody else, and they said, well, there’s other ways of doing that that are approved by ARIN other than RWhois. So I thought they knew something more than I did. So I just let it go.

So I don’t believe the intention was to have it mean other nonARIN‑approved ways of doing it. I think it was supposed to be RWhois and it kind of just ‑‑ I don’t know. I think people got confused for some reason. I know apparently I was one, and I should have asked more questions. So I would suggest we work on bringing that back to RWhois. The ASN /24 slide, do you know which one I’m talking about, the loophole?

Leslie Nobile: Oh. At the beginning. Yeah. That one?

Marla Azinger: Yes. So I see that and I battle it, but it would really help to have some clarification that you’re talking about up here to combat that, because, God, the increase of this has been immense. It ramped up a year ago, and it just keeps getting worse. Now it’s more like two a week. And I can do so much, and we have had to decide to do the battle of the money: Is it worth for us to say no, we’re absolutely not going to give you this space because we say it’s not valid for an excuse? But yet our policy permits this loophole.

So at some point I have to cut sling load and go, okay, it’s a money issue at this point, so to expedite escalation that it went all the way to the top, I have to hand it out. It would help to have something more clarifying and I could hand over down two cells, or whoever, and say you need to get a printout or a copy of their router received to prove they’re actually doing this, because otherwise I’m just kind of trying to do the best I can on my own without policy supporting me.

Leslie Nobile: Okay. Great. Thank you. David Farmer.

David Farmer: I think the next slide had a proposed ‑‑ yes. Marla, do you think this text is sufficient for solving the problem?

Marla Azinger: Yes. And it would help, too, if you added that ‑‑ something to the extent that router receipts would be requested. Because the amount of fudging that people are getting good at these days is pretty awesome, and they can very easily come up with an excuse for the /24. And one of the things we have seen already, which ARIN staff thankfully helped me out with, was I would get customers saying: Well, we’re going to do BGP, so I need a /24. And I’d say: Fine, go get your ASN and come back. Well, they’d say: Well, we can’t without a subnet.

So ARIN staff at least agreed with me, hey, assign a /29 and then have them come to us with that and provide us documentation. So at least that was one check and balance, but now that kind of is not enough, to be quite honest. So I think this would help. The only thing I question about it is whether or not the BGP peers part ‑‑ I think that probably needs to be defined a little bit more, because you could have someone doing an enterprise multi‑homing situation where their peer is actually their company, and so ‑‑ do you see what I mean?

John Curran: That’s a good thing for the AC to think about.

Leslie Nobile: I think Scott was next.

Scott Leibrand: Scott Leibrand, ARIN AC. There’s a phrase in that section that says that the ISP may demonstrate they’ve made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer as described above or by identifying the AS number of the customer. If we change “or” to “and,” that then forces them to get the ASN, like Marla was just talking about, which in turn means they have to follow all the processes for getting an ASN which means proving that you have actual upstreams, et cetera, et cetera. Would there be any objections, I’m bracketing this, but to changing “or” to “and” as well as doing this?

John Curran: So, remember, sometimes we’re getting people showing up saying they’re multihomed and what they’re actually saying is their ISP is virtually multihoming them effectively all within one ISP.

Scott Leibrand: Right. So I’m saying you’ve got to have a ASN, which means you’ve got to run BGP.

John Curran: I think it’s possibly one way to solve it. I think the AC should mull that over.

Scott Leibrand: We will do.

Leslie Nobile: And Aaron I think is next.

Aaron Hughes: Hi. Aaron Hughes, 6connect. I would say that this is probably too restrictive. And while I understand it’s trying to solve an abuse problem, this is another case where we simply haven’t enabled staff to deal with abuse. There are plenty of cases where a routing policy may be unique and you may need to multihome. They may not be a customer first, so it’s not a downstream customer necessarily, it’s just an organization and the type of BGP session ‑‑ well, first, they may not be BGP, but even BGP you may be a neighbor and not peer.

It’s challenging when text like this is brought to this kind of room to have to write so much specific data to solve abuse problems. And I don’t know how to solve it. But these kind of discussions are often challenging because we’re not given enough time to really think through all the cases that are important. This is an assumption I think that’s probably incorrect. Transit providers do on occasion statically route /24s for their downstreams without an ASN because a customer has no idea how to set up BGP.

John Curran: I want to be clear. Go back two slides.

One, two. That one. One forward. There we go. So if this room says this is fine, okay, set up two Org IDs, get an ASN for each, issue each customer a /24 and claim that they’re multihomed and it’s you and it’s you, okay, if the room says that’s fine, then we’re happy to turn the crank. I don’t know if it’s abuse, I guess is what is what I’m saying. Okay?

If you want ARIN to treat this as abuse, then you need to provide us policy that says we’ll ask whatever questions, or the next level down, to prevent it. But it’s only an issue because when we think about why someone talked about multihoming, we didn’t think about the fact that people would be using it in this case, and it sure looks like something that you folks didn’t want to have happen when you made the policy. But ultimately it’s up to the members as to whether this is abuse or just creative use. Community. Thank you, Scott. It’s very good that you’re here, Scott.

Aaron Hughes: That is a really interesting and challenging question, and I imagine that ARIN staff can sniff out some forms of abuse and other forms are much more challenging. This one is very challenging. There are cases where people need resources like this for unique routing policies that may not involve using things like BGP as a routing protocol.

John Curran: And our default would be to basically let these through, even though they look quite amusing, okay, because we don’t have a policy hook to say no. 98 percent of them are probably not the expected use that the community wants. But if you give us that hook, then we’ll close down 100 percent of them, including the 2 percent that is a really someone’s in a corner and they really need to do this. What I’m saying is that at the end of the day it’s not abuse until you define it that way. Until then we’ll let it go. And that may be fine to you guys.

Leslie Nobile: Kevin?

Kevin Blumberg: Kevin Blumberg. If you could bring up the next slide for a moment. I just did some calculations in my head in regards to anything that involves requiring BGP, and et cetera, and realistically it’s a $150 cost. There is no disincentive. It is still easy to do, still easy to abuse if that is the issue. So this unfortunately would not solve the abuse problem, because it would just cost 150 bucks more, and that’s a pittance in the grand scheme of things, if not even less than that.

I think what ARIN said is the ultimate issue, which is I think that for these types of situations more latitude to dealing with IPv4 issues that we have not historically seen for 20 years in terms of novel approaches to abusing the space, I think we need to give the staff, through policy, more of a latitude with possibly the ability to arbitrate internally where a person thinks that it is valid, ARIN staff initially says it’s not, okay, let’s take it to the next step. And that initial hurdle, while it’s a little painful, will probably end 90 percent of these requests because they know that it will fail at that second stage. If you think that’s too complicated, then ‑‑

John Curran: So I understand what you’re proposing. But the step you’re skipping is when we challenge these parties, they come back and say, well, you ‑‑ they don’t go away. They come back and say: We meet the policy. Okay? And remember that some of this can be done entirely virtual. Setting up a downstream customer and all the pieces is very quick to do. And these companies have an incentive to create a presence on the network very quickly. They might not use it for more than a few weeks, but it’s going to be there very quickly.

So the challenge you’ve got is that unless you want ARIN to climb a very expensive hill ‑‑ because they want to do 100 of these in a month; we can’t afford that process ‑‑ I can turn them all down, if you give me something clear, but trying to do internal arbitration probably would burn a lot of resources more than it’s worth. So I just want to try to set this up. This in some ways is a lot like the people who create shell companies. We can set up certain barriers for companies that don’t really exist, but we can only go so far. And beyond that point you have to not get in the way of everyone, but you have to approve everyone.

Kevin Blumberg: So, then, without getting complicated, unfortunately the policy as written or even the example as given would not be a barrier. It would need to be ‑‑ actually, it would need to move to an actual utilization of the space rather than a single IP. I think that would probably be the only way to nail it down.

John Curran: I want to come back. I want to be clear. That’s based on your statement that says the router is $150.

Kevin Blumberg: That is based on the statement that the router is basically close to zero, yes.

John Curran: A physical router ‑‑ and the reason we just put this out here is because, again, it is possible that some of these folks actually having to do something in the physical world is a huge hurdle.

Kevin Blumberg: Yes. But a physical router could be a virtual router that the customer has then sold or leased. It would be the same difference.

John Curran: So ultimately it’s the AC if they want to come up with something.

Leslie Nobile: Thank you. Owen?

Owen DeLong: Owen DeLong, ARIN AC. We’re talking about people abusing /24s by claiming they’re multihomed. Let’s stop rearranging the deck chairs.

John Curran: Anyone else want to discuss the Policy Experience Report?

Leslie Nobile: All right. Thank you.

John Curran: Thank you.

[Applause]

Open Policy Hour and Open Microphone

John Curran: So we’re in the final hour. This is the Open Policy Hour and Open Microphone. I’m going to handle the Open Policy Hour first. And this is where people approach the mics and they talk about policies, much like staff just did and said here’s some things you can consider, people approach the mics and they talk about policies they’d like to see or changes to policy.

The goal here is not to draft a policy in the middle of the room on the fly; the goal is to find other people who want to work with you on a common policy problem. So anyone who wants to go to the microphones and talk about a policy problem, now is the time. When we’re done with that, we’ll move into Open Mic, which is ‑‑ this time is going to be on the topic that was raised yesterday regarding return of address space. So for now it’s open policy hour. Policies, suggestions for policies. Yes, Mr. Hughes.

Aaron Hughes: Aaron Hughes, 6connect. So I just want to bring up the same issue I just did and open it up to the room for discussion. Is there any way that we could facilitate giving the ARIN staff a little more help in identifying abusers without having exact policy text to allow them to make decision not to give a organization a resource based on their interpretation that it is abuse.

John Curran: From the staff perspective I’ll say our problem isn’t that we can’t enforce the policy. When the policy is there, we can enforce it. It’s when the policy isn’t there and we’re acting on, well, patterns, for example, there are patterns that occur in abusers, we only have so many things we can do. And then without policy to anchor the next step, it comes down to a question of whether or not ARIN will say no in the absence of something we can’t reference policy for. And I ‑‑ in those cases, you’d think that you could resist and that would block most of them. These folks find a hole. And once they found it, they reproduce that request a thousand times. So I’m interested in views and opinions.

Aaron Hughes: So I understand that the only hammer given to the staff is the NRPM. Perhaps it would be useful, if patterns are identifiable, to document those kinds of patterns and bring them back to this kind of discussion so that we could use those to come up with appropriate text to block those patterns.

Even if it is playing a game of Whack‑A‑Mole, at least we would have that data to help assist us rather than what we do now, which is prevent good people from getting resources they need by blocking every possible hole we can think of first.

John Curran: We just brought one to you. We’ll bring more cases to you like that. I don’t know whether they’re abuse or they’re deck chairs. Your call. Mr. Schiller.

Jason Schiller: Jason Schiller, Google, NRO NC. On this topic, it seems to me that the reason why you’re assigning a /24 is because that’s the minimal routing unit, and there is a need to route that space independently. It can’t be part of one or both where the other is covering aggregate. I think the only way that you can deal with this is to write a policy that says /24s will only be issued when there is a need to route it as a discrete unit. You have to blindly issue them, and then you have to work with providers that have visibility to the routing table to see if they are actually being routed discretely or if there’s a need for them to be routed discretely.

John Curran: So we presently do two‑thirds of that. Wait, wait, wait, wait. We do two‑thirds because we presently issue some when they go through this. You’re advocating maybe a follow‑up path where we go back and we confirm that indeed it’s still multi‑homed even if it’s multi‑homed through ‑‑ is that what you’re suggesting, Jason? What are you suggesting?

Jason Schiller: Yes. That’s basically what I’m suggesting. The resource holder says here’s the reason why it needs to be routed discretely, and then somebody goes back three months, six months, a year later and says, A, is it being routed discretely, and, B, is their reason actually justifiable or does it look like it’s smoke and mirrors.

John Curran: I would love to hear that coming from the AC. ARIN will check up on six months hence. If that’s the type of thing that they want us to do, that can be done. Go ahead, Heather.

Heather Schiller: Then what do they do? That’s my question. It seems like I was going to get up and then I decided I’m not going to say anything because I’m going to get in trouble for saying it?

But what do you want to enforce? We have all of these rules, and it’s like we enforce the fraud, because everyone agrees that’s just outright bad. But everything else is kind of like wishy‑washy.

John Curran: This would be fraud; someone who turns around and says I got my /24 for this purpose, and we ask them six months later, they had better say circumstances changed, here have it back. Okay? Because if they say, well, actually I didn’t need multi‑homed, I’m actually just doing it for this reason instead, that would be fraud based on what they gave us at six months. And we would revoke. We do initiate revocation when someone turns around and makes one statement and then turns around and makes another statement. The problem you might have in some cases is that six months later, they’re gone. That’s a different problem.

Heather Schiller: Yeah. They already got what they needed out of it.

John Curran: The wisdom of the AC needs you to tell us what you want us to do. That’s you. Microphone open. Go ahead.

Kevin Blumberg: Kevin Blumberg, ARIN AC, The Wire. Speaking as neither. I asked Leslie that question earlier because I did have the thought of doing up a new policy proposal, and I wanted to engage a little bit of the room for this. In 4.3.6.2, this is additional assignments for small multi‑homers. There is a policy that basically says if you get a /24 through this policy, and you come back subsequently, you have to return that /24 so you can get a /23, all the way down to keep returning until you eventually get a /22, in which case you can keep it. It is the only policy that I know of in the NRPM that penalizes people who are given space for multi‑homing, or for anything for that matter in the same way, A.

And, B, what it does is require a company who is starting out to do the most egregious thing, which is set up a network, get it working, get all their critical infrastructure in place, and then pull the rug out from them when they grow. So I have one of two suggestions, and I wanted to gauge the room. The first suggestion is the easiest because nobody has gone back for subsequent ‑‑ from a meaningful statistical manner, is remove it completely. Remove that restriction out completely. That is the first option.

The second option which is maybe more palatable for the community, but I still prefer the first option. The second option is the first assignment that you’re given you do not have to return. When you get a subsequent allocation, if it is small, and a further subsequent application, yes, you will need to. But the first one you get to keep. That way your critical infrastructure does not have to be renumbered. Having worked with renumbering, having done renumbering three times myself, I do not wish that upon my worst enemy. So I wanted to gauge what the room thought. I realize it’s a bit of a deck chair, but at the same time it’s kind of cruel to new entrants.

John Curran: That’s an interesting policy, potential policies. People want to speak about those or work with him, stand up, grab a mic.

Kevin Blumberg: Or wait for it to come out on the PPML. Thank you.

John Curran: Okay. I am going to be ‑‑ because we have an open mic session, I am going to be at some point switching over to that. But for now we’re still in Open Policy Hour. Suggestions for policy.

Stacy Hughes: It’s Stacy speaking for Joe Maimon of CHL. He says: “Twice I’ve proposed policy, both abandoned, that would enable ARIN to service new entrants even when the ARIN free pool would normally have run out. Is there any actual support for this; and, if so, would somebody else please take a swing at it. V4, speaking.”

John Curran: Anyone interested in picking up the gauntlet and taking over for Joe? If you are, he’s asking for help. If you want to speak about that or contact him, feel free to do so. We are open for ‑‑ go ahead.

Owen DeLong: I’ll take a swing at what Joe’s proposing.

John Curran: Well, he’s asking for help.

Owen DeLong: So the swing I’m going to take doesn’t exactly help. But I will point out that we have existing policy which sets aside a /10 for transitional technologies and usage which would accommodate new entrants providing transitional v4 support to aid in their deployment of their v6 networks. Once the ARIN free pool has run out, I think that’s about the best we can do. I think preventing people who need v4 today from having v4 to use based on the need to set some aside for some speculative possible future need of somebody that doesn’t even exist yet is silly.

John Curran: Okay. People want to talk about suggestions for policy? Yes, Jason.

Jason Schiller: On that topic, the questions that I would ask the community is, one, is that enough to support a new entrant? Just enough IPv4 addresses to support a v6 deployment. And, two, do we think a /10 is not enough? Theoretically, we drew down the last /8 which was supposedly going to be set aside for special use. We’ve designated some of that. We could potentially grow the /10 to consume whatever was left of the balance of that 8. Would people be opposed to that or in support of that?

Or does Joe think that we actually need to do more than just provide enough addresses to support transition technologies for a new entrant to do v6 with some minimal v4 for things like DNS or CGN or whatever?

John Curran: People who want to speak on the matter of doing reserves, either reserves from the remainder of the special block, reserves for new entrants, people are entering a need, v4 addresses for transition, because they’re doing v6 as well. People who want to talk about new policies in these areas raise your hand, come to the mic. Speak remotely. We don’t need new policy. If there’s no need to fix any problems because there’s not any problems, that’s good. But to the extent that people are looking to work on policy and want to find someone to help them, now is the time to suggest new policy.

Kadian Davis: Good afternoon, everyone. I’m Kadian Davis from the University College of the Caribbean in Jamaica. I’m not sure if this is a policy, but I have a concern. With regard to the input from the Caribbean, there are several countries and several languages in the Caribbean. This was raised at lunch yesterday. We have languages such as Dutch, English language, Spanish and French. To ensure the multistakeholder community, it would be good if we could have a policy to facilitate the various languages so that you can have input from persons from Haiti, Anguilla, Cuba, et cetera, the countries in the Caribbean.

John Curran: Understood. So we will take that under advisement and figure out what’s involved in that. It’s true that we do sometimes work with other RIRs on global documents to get them translated. So when the NRO issues a document, it is often translated into many languages through each of the RIRs. But within the ARIN region, predominantly our policy process has been English. But we can look at what it takes to get translation to other languages, if that will help input from the Caribbean. I don’t know the expense involved, but I know some RIRs I can ask for guidance there. Thank you. Yes, Jason. Open Policy Hour, suggestions on policy.

Jason Schiller: A suggestion on that topic. One thing that may be beneficial is we have a screen up here that has the running transcript in English of what we’re talking about; that may be helpful to non‑native speakers who can look up and see the words. I know they do that in some of the other meetings, like ICANN, for example, and I think people find that helpful.

John Curran: Right. If we go this route, we would need to look at not only a transcript and translation, but we’d also have to look at the meeting materials themselves. And so we know what it takes. We haven’t done it, because historically most of the participants have been able to use English. But I’m certain we’ll do some research and talk to the Board about it. Okay. I’m going to move from Open Policy Hour, unless anyone has any other policies they want to talk about, possible future policies, problems with the current policies? All the policies are wonderful. That’s great. Okay. So we’re going to move out of the Open Policy Hour into Open Mic. There was a suggestion made that we reserve a significant amount of time at Open Mic ‑‑ in fact, to reserve the entire thing ‑‑ for the topic that we were having yesterday. I’d like to give five minutes for anything on open microphone and then we will save the rest for our discussion of the return of address space.

John Curran: So open microphone. Yes, center rear mic.

Sam Weiler: Sam Weiler, SPARTA. I’d like to go back to the discussion this morning about prioritization of engineering requirements. I have a request and a question. The request is borne of the observation that the descriptions there are pretty sparse. I would like to see those fleshed out, particularly since the survey went out this morning. I think time is of the essence in getting those fleshed out. The specific question is about one of them ‑‑ this is inspired by my colleague Sandy Murphy, who asked in the jabber room that hasn’t been relayed yet. One of the items is about alternatives to the RPKI, roughly, and I wasn’t quite sure what you meant. Wondered if you would clarify that for us.

John Curran: Alternatives to RPKI means the activities involved in looking at things not on the present plan of record, such as torrent distribution of RPKI keys, such as looking using technologies other than certificates, such as secure DNS to do the same resource certification. So if it’s not on the roadmap and it’s a different direction, not an extension of what we’re currently doing, it’s spending effort on alternatives to the current roadmap for RPKI. Got it?

Sam Weiler: So it sounds like a pretty broad area. Yes.

John Curran: It is a pretty broad area. And remember that at this level, because some of those are still being defined, you can’t even scope them out. The question is should we be spending resources being involved in those working groups and those discussions.

Sam Weiler: Thank you.

John Curran: We will work on better descriptions next time. I consider it pleasing that we have as much as we have because usually we’re telling you what we’re doing as we’re doing it. Now we’re asking you in advance, but we’ll try to give you as much as possible.

Sam Weiler: And I would encourage you to flesh them out now, so people have another three weeks to respond to your survey.

John Curran: Yep. Okay. Open microphone. Center rear mic.

Mike Joseph: Mike Joseph, Google. Today we observed that Policy 2012‑1 concerning the revised transfer requirements garnered a significant amount of community support. And we’ve also been told by John up there that 2011‑1 will be completed by implementation in 60 to 90 days. And what I would like to ask of my colleagues in the community, as well as the Advisory Council and the Board, is to consider asking the AC to expedite the policy adoption of 2012‑1, given the urgency imposed by the previous policy, and for the Board to hold off the implementation and final ratification of 11‑1 provided that traction has been found with 2012‑1, and also to have the AC make only a minimal amount of changes necessary to get the 2012‑1 through for adoption, given how much the community indicated to all of us that we needed to get this policy on the books before 2011‑1 took effect. So I’d like to open up this question to my colleagues in the community, if this is something they would support, asking the requests of the AC and the Board.

John Curran: Okay. And to be clear on one little point: So we often ‑‑ we have a circumstance where we have one policy that has been recommended for adoption and we have another one that’s in development. And so if the one in development catches up very fast, what you’re asking is sort of a very simple thing, because we can look and say: Oh, well, rather than rolling it out and then revising it, we can roll it out in one fell swoop. The real question is: If in 60 or 90 days the changes in 2012‑1 aren’t ready, are you recommending that the Board continue to hold the implementation of the ‑‑ what I want to know ‑‑ recommending that the AC does its job quickly, I heard that. And if not ready in 60 to 90 days, what would you recommend we do?

Mike Joseph: I would recommend that the Board observe if the AC is working as quickly as feasible. And if they are, and it looks like adoption would be imminent, that they hold off ratification.

John Curran: That’s what I was asking. Thank you.

Mike Joseph: I believe that essentially we’re asking both: We’re asking the AC to expedite adoption, and we’re asking the Board if the AC is doing their job, to hold off ratification.

John Curran: People want to come up and speak on this topic regarding Inter‑RIR transfer policy and the discussion of 2012‑1 which would change transfer policy. Microphones remain open for the discussion of the Inter‑RIR. So the guidance is encourage the AC to move expeditiously. Whips and chains, we can work on that. And then to have the Board in touch with the progress of that at the point in time when we’re ready to make a decision on opening Policy 2011‑1 because it’s implemented. Right? Is that what you asked?

John Curran: Yes.

Mike Joseph: Not implemented yet. If 2012‑1 is on track for adoption, have the AC defer ratification of 11‑1.

John Curran: Actually 11‑1 is out of the AC’s hands.

Mike Joseph: The Board.

John Curran: Got it. That’s what I wanted to hear.

Mike Joseph: If the AC has 12‑1 on track, the Board should defer 11‑1, being able to observe that 12‑1 will be imminent.

John Curran: People want to comment on that proposition? The microphones are open.

Okay. The Board’s heard you. I will also provide that so they can think about that. I will certainly remind the AC that they’re asked to move expeditiously, to the extent possible. David.

David Farmer: So there was also some discussion earlier today on 2012‑4: Should we go back to 12 months. You gave us all very clear direction. Note that’s very sarcastic. So I guess the question I have: Is there something ‑‑ is it not ready? Is there ‑‑ is it something that if it sat another policy cycle people might feel differently in another policy cycle? Is waiting ‑‑ are there circumstances that would make this usable in another policy cycle? Any comments on that would be helpful.

John Curran: Mr. Schiller.

Jason Schiller: Jason Schiller, Google, NRO NC. Certainly if we had widespread IPv6 deployment or IPv6 critical mass I would certainly support moving it back to one year.

John Curran: If you want to take a break so we can get critical deployment of v6, come back and reconsider it, we can do that. Center rear mic.

Martin Hannigan: Martin Hannigan. I think you should abandon it completely because six months from now is too late. And six months ago was probably too late as well.

John Curran: Okay. Mr. Hain.

Tony Hain: Tony Hain, Hain Global Consulting. In answer to your question, I believe ‑‑ at the risk of opening up the next discussion ‑‑ that if you gave back two /8s instead of one this would be a moot point.

[Laughter and applause]

John Curran: Okay. And I’m going to close open microphone to everything except yesterday’s address return discussion. So if you have anything else for open mic, remote, on the floor.

Kadian Davis: Kadian Davis, University College of the Caribbean. With regard to IPv6 deployment, transitioning from IPv4 to IPv6, not many persons, especially speaking from a Jamaican perspective, are aware of the necessity of transitioning from IPv4 to IPv6. Holders are in plan to create an awareness in the Caribbean for the necessity of that transition. In addition to that, with regard to outreach activities of ARIN, is it that the fellowship is the only way that you create an awareness? And TeamARIN?

John Curran: So let me actually discuss that, particularly when it comes to the Caribbean. We actually are very involved, but we’re engaging at the level of the ministerial. So, for example, we work with both CANTO and CTU. We’re involved in the discussions among the ministers of telecommunication in the region, trying to encourage them to look at the IPv4 run‑out and IPv6 deployment issue and to get the message out. I’ve been in more than half a dozen of the CTU Internet outreach activities that go, have gone to various economies in the Caribbean, and those are actually open to the public. They have a “Get involved in the Internet Session.”

We have always an IPv6 session. But the challenge that we ultimately face is that in many of those locations it may actually take a strong impetus to get the carriers in those regions to look at IPv6. It’s very difficult for businesses to say I’m going to go to v6. They don’t have 15 carriers of which four support IPv6 today. When you only have one or two carriers and neither of them are offering it, it’s very difficult. So we’re working at the ministerial level to try to get countries to say: We expect IPv6 service to be offered to our people.

But it’s an uphill battle. We’re going to continue. I actually will be, in May, meeting with the ministers of most of the Caribbean locations in our region to talk about that very message one more time, because they now realize that the IPv4 run‑out is real because it’s happening in other parts of the globe. So it’s hard for us to be on the ground. We’re trying to do what we can. The Fellowship Program to bring people in, I think, is helpful, and we expanded that last year to allow additional fellowship people. If it would be helpful to have more ‑‑ the funding is very modest ‑‑ that’s something we need to know.

In other words, if instead of one of you there, it’s two, we’ve allowed for that. If you think three would be helpful, that would be good to know. If there’s some other way you think we should be doing outreach, I’d love to hear. You can write me or find me afterwards. Owen.

Owen DeLong: Owen DeLong, ARIN AC. This July will be the fourth CANTO meeting that I’ve gone to, along with some members of the ARIN staff as part of that outreach effort.

And one question I would like to ask Ms. Davis is if it would be helpful if ARIN started engaging in some educational activities in the Caribbean, and if we could find ways to do that, would that possibly help encourage people to adopt v6 in the Caribbean?

Kadian Davis: Yes, definitely. Having ‑‑ for example, at my institution, it’s a private institution and we’re currently planning an Internet Day to have government officials, banks, ICT providers, telecommunication providers and create an awareness to say, okay, IPv6 is really necessary. Security, protocols, security extension, DNSSEC will be the topic. And if ARIN could come and speak at our Internet Day, it would be very lovely, because many people are just not aware. And, frankly, in my country, I don’t think the government places that much of importance with regard to any Internet governance issues. So if we can just create a body that can just push for IPv6 deployment, it would be very helpful.

John Curran: So let’s make something happen. In general, by the way, if you go to ARIN’s website or you go to TeamARIN, and you tell us you have an event happening, we generally will try to find someone to speak. It won’t always be me because that doesn’t scale, but I have the Advisory Council and the Board who often help. So that’s the normal path. But if you tell me when and the date, we’ll try to figure that out. We do have an outreach budget which provides for people to go. We send ‑‑ I go ask the AC routinely: Can I have someone for this conference or this meeting, can you go give a presentation on IPv6? So let me know when the event is and we’ll do it.

I also want to mention to the ARIN at large, if you are having an event or an activity and you need someone to come speak, www.arin.net or teamarin.net, fill out the form and let us know. We will find a way to get someone there. I think we might have done a video once when we had to, but we generally are able to find a way to put someone on the ground. Okay. Very good. All right. I want to save the remainder of the time now of open mic for the question of address return. So I’m closing open mic for all other topics. Remainder of the session until 5:00 is on the topic of ‑‑ or as long as we need, to talk about address return.

The context of this is ‑‑ and I’m going to try to walk through it ‑‑ ARIN’s historic practice regarding address blocks returned to it is that if they were address blocks of /8 or larger, we either returned them to the IANA or referred the party to the IANA for that purpose. Because the IANA maintains the registry at the /8 level for where the major blocks go. For smaller blocks, they went into ARIN’s pool, because the IANA was not really set up to handle smaller blocks, interesting logistics there. That’s happened over time. Many organizations have returned major address blocks.

With the discussion of what was happening at runout and how the small amount of address space that was being returned would be used, the RIR folks got together and there was a discussion around policies. The first policy was one that had a mandatory return. All address space that’s returned to an RIR goes to IANA and gets divided up and reissued. In the ARIN region, that didn’t pass. And there was discussion at length about the fact that the mandatory aspect of return wasn’t appropriate because in theory someone could end up having to return space to the IANA. It would be reissued. There’s nothing to assure that every RIR is going to issue that out according to need. An RIR could actually sell the block it got from IANA and create a foundation. Who knows.

So we objected, and it was changed in subsequent versions to allow the designation of space to be returned to the IANA. And this action went through two versions. And now the third version is what’s gone through all the RIRs and is now before the ICANN Board. That policy allows an RIR to designate that returned space to it, designate that same space to be returned to the IANA for reallocation, and provides a mechanism for the IANA to divvy up those blocks and make it available. In this time, ARIN’s accumulated a small pool of miscellaneous fragments, approximately, let’s say, 2.1 /16s. A relatively small amount of space. Relatively small compared to a /8, but relatively large compared to some of your allocations, perhaps.

Additionally, a very large, almost entire, but not entire, block was returned to us which was 254 /16s, nearly a /8. Meaning that ARIN’s total return pool is actually the equivalent of just a smidge over /8, made up of one large block and a lot of smaller ones. In this period of time, a policy was moved in the ARIN region that said address space that’s returned, recovered or revoked in the ARIN region should be put in the available pool. Until there’s a global policy, address space that’s returned, recovered, shall be put in the available pool. We have an interesting circumstance, because upon the ICANN adoption of the global policy, the third version that’s been sent by the ASO to ICANN, that policy that states return space will be made available suddenly is no longer operative.

And it leaves us without necessarily clear policy guidance regarding we have the option of returning space but when should we actually do it. When that policy is adopted, that global policy, I will ask the ICANN Board ‑‑ I’m not going to ask the ICANN Board anything ‑‑ I’m going to ask the ARIN Board for approval to return that effectively pool of address space that’s the equivalent of just over one /8 in its entirety, because it’s the pool that’s built up in this time, and that’s because it comports with our historic practice. A number of people got up and said let’s talk about that. So the question is: What should be done regarding return of address space and how would the community like it handled? The microphones are open.

Scott Leibrand: Scott Leibrand, Limelight, ARIN AC. I support the return of the approximately /8, as I said yesterday. I think a principle that could be used for deciding this is returns of global significance. So if you get back a /24, maybe it’s not worth returning. If you get back almost a /8, it probably is. I don’t know where you’d draw the line. Probably depends on the conditions, et cetera. But I think it is worthwhile for us to go ahead and return anything that’s of global significance for lots of reasons, some technical, most not.

John Curran: Got it. Rear microphone.

Bill Darte: Bill Darte, ARIN AC, but I speak for myself, and I agree with what Scott just said.

John Curran: Yes.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I also agree with what Scott said, and I would say that anything over a /16 is of global significance. Anything under /24 isn’t. Between /24 and /16, we can discuss that. But I would just put forward, we could take Solomon’s choice on that and split it in half and make it a /20. So anything /20 or above should be returned. Below should remain in ARIN and be used as small blocks. I’ve also had discussions with members of the community from other RIRs.

And there was concern about shuffling around /24s and lots of little crumbs and is that really effective for anybody. And that’s where this idea of picking something of global significance and returning that and using the stuff, the little itty bitty crumbs locally, it seems to make sense.

John Curran: Cathy.

Cathy Aronson: Cathy Aronson, ARIN AC. So far we’ve only had people from the AC speaking about this. I’m certainly in favor of returning the blocks like my colleagues, but it would be super cool if other people who aren’t on the AC might give guidance as to what they feel about this. That would be great.

John Curran: Excellent. Rear microphone, Marla.

Marla Azinger: I’m not on the AC.

Cathy Aronson: Anymore.

Marla Azinger: Been a couple of years now. So historically there’s this doing the right thing topic that keeps coming up. And I’m one of the original proposal writers. And Scott sacrificed himself to help me out with that at the beginning of this. This was several years ago. And other RIRs had zero interest in doing this. Because they still had address space and it really wasn’t that close. But the main impetus of it all was: No one in another RIR wanted to step forward until they had something to gain and not lose. And I actually kind of have a problem with that because I brought it to everybody earlier so people could ‑‑ everyone could be honest and participate fairly. But that wasn’t the preferred method.

So it’s just now that this comes about, that other RIRs are willing to participate and ‑‑ yeah, I know. So I have ‑‑ I don’t give too much credit to the doing the right thing anymore because of that. So when I sound like I don’t, that’s why. So I do still think that it probably is the right thing to return some address sets. However, we do need to set parameters, like Scott said. That was one of the things on my list. Except for I would take the opposite approach and hand out the smaller ones that are not contiguous since we have a policy in the ARIN region that says you won’t fulfill requests by putting together several different subnets.

So you’re going against your own policy, kind of like kicking it in the head basically by keeping all these separate little /24s and /23s and not getting rid of them and instead you’re getting rid of the larger subnets. So to me either we need to change our policy and not have that requirement that you can’t put together different subnets to fulfill someone’s request, or those are the ones we need to get rid of and hand back to IANA.

So the other thing, too, is we’re doing a lot all at once and it’s been said before that we write too many policies too frequently too fast. When it’s important, yes, it matters, but we are talking about doing, approving more leeway on the transfers. And it would be advisable to pass one or the other policy and watch how that plays out and what that does to our address set pool, before passing more than one pool affecting policy at the same time.

Additionally, we had the discussion earlier about changing the requirement of three months to 12 months so that people could actually plan for their businesses. I have a lot of issue with people in the community telling me they don’t agree to let our own organizations plan for their businesses and get address space that they can justify and then turn around and hand a bunch of address space over to IANA to go back to other registries to be handed out to other organizations. That to me is not shepherding and taking care of your own community. Thank you.

John Curran: Thank you. Center front.

Matthew Wilder: Matthew Wilder, Telus, speaking on behalf of the Internet community. I support the idea of returning the address space that we can feasibly and reasonably, and I think there’s some interesting points ‑‑ and Marla brought up the segmentation we already see in the available pool. So we don’t have those stats that are at the community’s hands, per se.

But I think it’s interesting to think about the idea of handing back the smaller bits. That may be a reasonable thing to do. As far as the idea David threw out, the idea of /20 and smaller staying? Was it /20 and larger staying ‑‑

David Farmer: Going.

Matthew Wilder: Going. So I think that may be dangerous for some of the bigger requirements that we see out there. But maybe a /10, for instance, and larger, or /12, who knows. But I definitely support the notion of giving back and supporting APNIC growth or whichever region’s growth needs it most. So I don’t think ‑‑ I think there’s still obviously discussion that we had, but very supportive of that.

John Curran: Thank you. Microphones remain open. Remote participants. Go ahead. Center front.

Hans Petter Holen: Hans Petter Holen from NRO NC, working for a Norwegian company Visma. I just wanted to make a comment to the comment Marla made. I can’t remember this process from outside this region the way she described it. I don’t think many other people in other regions sees it the way Marla described it either. Thank you.

John Curran: Yes, remote participant. Go ahead.

Stacy Hughes: It’s Stacy speaking for Chris Grundemann, who is speaking individually. And I am putting on my glasses. Chris thinks ARIN should maintain historical policy and return the /8s ‑‑ and return /8s.

John Curran: Wonderful. Good to know. Microphones remain open.

Center rear mic. Mr. Hannigan.

Martin Hannigan: Martin Hannigan, Akamai Technologies. I almost support Tony’s suggestion. I think it’s interesting, except that we don’t have a functional market or transfer process. And I think from a business perspective, most of us ‑‑ most of us that have more than a significant need are at a loss to have a vision as to what we’re supposed to do when exhaustion actually hits. And I think I would echo Marla’s comments with respect to playing this conservatively and perhaps not returning any addresses. I think this is more a complex issue than it’s being made out to be. I also think that we need much wider consultation in the American Registry for Internet Numbers community which might include a discussion on the Members List and perhaps some additional outreach in the business community.

I think that it would be equally obnoxious of us to assume that a very vocal, what appears today to be a minority, gets to decide how this is going to play out with respect to addresses that may or may not need to be returned to the IANA. It’s kind of like the 5 percent ruling for the 95 percent, or overruling the 95 percent. And I just don’t get the feeling that we have enough participation to actually make this kind of decision so hastily.

And I think there are more concerns such as we know that the DOD signed up to return some addresses. What’s the status of that? And perhaps we should be banking those addresses now and then when those become available, return those to the IANA.

But I think that we need some more ideas, and we need a much clearer picture as to what we’re all supposed to do when exhaustion hits, not only in this region, but probably all of them. And I’d also like to thank my friends in the other RIRs for their participation. It’s much appreciated.

John Curran: With respect to the inquiry regarding DOD, I’ll just say it is true that the Registration Services Agreement with the DOD, ‑‑ and we’ve stated this before ‑‑ provides for the US government to ‑‑ if it does not need address space, provides them the opportunity to return it to ARIN. Recognize that that has already happened in the past. Several /8 blocks were returned. And it’s not foreseen to be happening for some time.

But it is true that on a ten‑year plus time frame, if we’re all successful with v6, that v4 space, when made available, if it’s not needed within the US government, would likely be returned to ARIN. But I think that occurs with the success of v6 such that people remove v4 from devices. That might take a while. I just want to provide information regarding what the agreement is and what it says so that people understand that. Okay. Yes, we have a remote participant.

Stacy Hughes: I do. Scott Morizot from the IRS says, or feels: “If it’s returned space that would otherwise go into ARIN’s available pool with no forecasted need in the next six months, it would merely sit unused here. Return it all to IANA and let it sit there until it gets divided and allocated to all RIRs equally, including ARIN.” He would review it returning the Interop space a minimum.

John Curran: Yep. Okay. We have rear microphone.

Aaron Hughes: Aaron Hughes also not affiliated with any RIR. I support returning the 45 /8 to IANA. And also if you have a couple of legacy /16 chunks that you’re planning on returning, I would be in favor of asking Interop after this meeting ‑‑ of course it’s going on right now ‑‑ if they wouldn’t mind swapping out 45, 0 and 1 for two of the little chunks you’re planning on returning and wrap that 8 back into a single 8.

John Curran: Understood.

Marla, I see you, but I have other people who haven’t spoken yet. So Scott.

Scott Bradner: John, can you just give us some context of how much space ‑‑ just remind people how much space we have in our pool with the returned plus the other stuff in the pool in terms of what the actual numbers are and what the runout ‑‑ we heard a little bit earlier, but let’s talk again about what the runout is. So just to get some context.

John Curran: Sure. So each day we update it on the ARIN website. If you go to the ARIN website ‑‑ which is what I’m going to do, because I have to go to it just like you do to get the information ‑‑ at this present moment we have the equivalent of 4.87 ‑‑ 4.87 /8s. That includes, in the available pool, approximately one /8, which is space that has been returned to ARIN and per this region’s policy has been put in the available pool.

Scott Bradner: The discussion here is talking about returning up to a quarter of the space that we happen to have.

John Curran: One out of 4.8 looks to me to be ‑‑

Scott Bradner: A little less than a quarter.

John Curran: Looks to be less than a quarter, more than a fifth. But yes.

Scott Bradner: So just putting it in context, we’re not talking about giving away all the family jewels.

John Curran: Right. But also in context is that we do move closer to having a single /8.

Scott Bradner: And of course we get a fifth of it back anyway.

John Curran: Correct. The space that goes to IANA is divided up into ten easy pieces and comes back in fifths to all of us. So it’s a little interesting. You already adopted that policy, though. Yes, Aaron.

Aaron Hughes: My interpretation of that was that it’s offered to all five RIRs and they can choose not to take their chunk and it could be divided to people who have need. Is that not correct?

John Curran: I think what you said is correct. I’m not going to try to paraphrase the policy. I would need to look at it.

Aaron Hughes: I would also support not accepting the one‑fifth chunk in the ARIN region, since we clearly have no need, if that were going back out.

John Curran: Good point. Microphones remain open. Marla, go ahead.

Marla Azinger: The gentleman that stood up and said he doesn’t recall what I had mentioned about a meeting. I don’t believe he was in that meeting, so he shouldn’t recall it. It was a representative from each RIR. ARIN only had two representatives because it was two AC shepherds going to it together. So it was ‑‑ other than the door actually not being closed, it was kind of a closed meeting. So I have no doubt that a lot of people have no clue that happened. But that’s where my history came from. So that’s why I wanted to explain my opinion.

John Curran: Can I ask a question about that? I don’t know what year that was.

Marla Azinger: San Antonio.

John Curran: San Antonio. But that was actually already after the RIRs had ‑‑ remember, there’s been three versions of this. And not our last San Juan meeting but the prior San Juan meeting is when a recovery policy started being discussed among the RIRs.

Marla Azinger: It’s been up down, up down, yeah. Sorry.

John Curran: I just want to make sure ‑‑

Marla Azinger: That’s my history with it. That’s why I wanted to share it so people understood where I was coming from.

John Curran: Anything else?

Marla Azinger: Yeah, the word “may” that is in the policy. That was also up for discussion at one of the conferences. And using the word “may” instead of “required” or “will” was used because that led people to believe ‑‑ and it was said ‑‑ that we’re using “may” because then parameters will be set and we’ll discuss it. Doesn’t mean we’ll do it for sure. So I think a lot of people got confused and felt kind of hornswoggled ‑‑ is that a word? ‑‑ that they thought the word “may” really meant they would have more input later on down the road. And I wanted to clarify why people felt people were confused.

John Curran: Okay. I want to go to Dan because he hasn’t spoken yet. Dan.

Dan Alexander: Dan Alexander, Comcast and ARIN Advisory Council. But I’ll just speak for myself. I would echo Aaron’s comments that the space ‑‑ I hope ARIN will return this space and that it doesn’t get in line for its redistribution.

John Curran: Scott.

Scott Bradner: Train of thought derailed. Let’s try that again.

[Laughter]

Scott Bradner: Take two. Maybe three.

John Curran: Gentlemen with long white beards are allowed extra time.

Scott Bradner: Oh, yes. May. John did describe that part of the reason for the word “may” was we wanted the option at the time that it came up for a possibility to renewal to take into account other RIR policies, and if the other RIR policies were not needs‑based, we could say ‑‑ we could ‑‑ we could opt to not return, because we would be concerned about the needs‑based response. So that was one of the reasons. The other thing is that you are ‑‑ this is part of the reason to have this discussion today, is to get feedback. If you feel that this is not the right path for ARIN to take, the Board needs to know that, because Mr. Curran is going to ask the Board for concurrence in returning these addresses. And your input is very important to the Board, as when that does happen.

John Curran: Yes, center rear mic.

Kevin Blumberg: Kevin Blumberg, ARIN AC and The Wire. I had 24 hours to sleep on this, which was a brilliant idea. Thank you. Based on reviewing last, the last meeting, the discussions that we’ve had, as well as some other discussions, I believe it is entirely fair and appropriate to return the Interop space. I think it is a important gesture. I think that, based on other things that I’ve heard today, it will not negatively impact the runout of the region in a detrimental fashion. And to some degree I feel that it was kind of expected that we would do it. That expectation obviously between different people over time, we might have forgotten that. But I definitely felt there was a lot of people who felt it was appropriate and I still do today.

John Curran: Thank you. Microphones remain open. Yes. Go ahead, Scott.

Scott Bradner: One other note. While we are talking about the theory of returning, rather than simply the returning of this particular block that Mr. Curran is going to ask concurrence from the Board on, it is my opinion that in an arena of transfers, where monetization is a feature, we are unlikely to get any significant amount of returns from anybody but perhaps the government or perhaps some educational institutions. Mostly we are not going to get returns after about now. So we’re really talking about this instance. And it’s likely not to be a material concern in the future.

John Curran: Okay. Center front, Mr. Sandiford.

Bill Sandiford: Bill Sandiford, ARIN AC. It’s simply a question, actually. When Interop returned the /8 to ARIN, did they give any directions or any expectations of what they wanted ARIN to do with it, or was it left fully up to the discretion of ARIN?

John Curran: They actually ‑‑ I was at the Interop event where they told their conference ‑‑ they announced they were returning it for the good of the Internet community. Center rear.

Scott Bradner: John, you should also mention that you specifically discussed with them the fact that they could monetize it and they decided not to do so.

John Curran: Yes. Very long and at length. And Interop has been actually ‑‑ I’ve been involved with Interop, not the first year, but since the very beginning. Interop has been involved in the Internet since 1989 and has been around forever and knows the evolution of this, and recognized that the return of the address space would provide the Internet community globally more time.So it’s in keeping with what many other organizations like the DOD, like Stanford University, like BBN have done over the last decade.

Scott Bradner: And note that Interop has been a global organization holding conferences all over the world.

John Curran: Center rear mic.

Mike Joseph: Mike Joseph, Google. Just to respond to Scott’s earlier comment. That may be true for ‑‑ I would probably agree that there won’t be very many voluntary returns of space to ARIN, except for those organizations which John previously articulated.

But I suspect there may be some reclamation and revocation activity. And it sounds like we’re intending to return those as well. Or is the intention to retain those in the free pool? Yes, that’s a question for staff.

John Curran: So I will say I’m going to recommend ‑‑ if there’s a global policy, I’d recommend returning what’s in our inventory space for returned space which is the Interop block plus the remaining ‑‑ it’s about a total of one /8. But then we won’t have anything left in the pool.

If there’s policy or some guidance from the members to change our practice, then I’ll follow it. Until then, the reason I’m recommending return is it matches our existing practice. And now that there’s a global policy that this group adopted, you folks recommended that policy to allow for the return of address space ‑‑

Scott Bradner: John, I think he’s asking about future returns.

Mike Joseph: Future reclamation.

John Curran: That’s what I’m saying with respect ‑‑ once we’ve returned the current pool, given that you’ve adopted a global policy that allows for returns, and our practice has been to return, I’d be returning until you guys gave me a policy update.

Mike Joseph: Including for revocation and reclamation.

John Curran: Yes, returned address space ‑‑ revocation goes into holddown.

Cathy Aronson: Cathy Aronson. Point of clarification. I think what he’s asking, is if there’s a block that ARIN has assigned out of ARIN’s free pool and ARIN reclaims it, is ARIN going to return that to the IANA? I mean, the blocks that you have in your return pool, aren’t those blocks from before ARIN was ‑‑

John Curran: So I’m going to say I would have to look, and I would do what the global policy states with respect to ‑‑ if it covers the scope of returned and reclaimed address space, then if it covered reclaimed, I would put it in.By default I’m going to nominate all space to the Board that matches that global policy because you guys recommended it.

Mike Joseph: Just a clarification question. If I defraud ARIN and obtain a /20, ARIN notices I defraud them, say I defraud them tomorrow, then you notice a week later and you revoke it, you would then take that /20 and recommend to the Board to return it to the IANA.

John Curran: If it matches the phrasing of the global policy.

Scott Bradner: Why don’t you look at the policy?

John Curran: I’d be happy to do so.

Mike Joseph: I have no intention to defraud ARIN, for the record. Thank you.

[Laughter]

Scott Bradner: He hesitates to add. John is looking at the wording of the policy to ‑‑

Geoff Huston: I think I can help you, John, with a little bit of memory. It was all about the various and legacy blocks. The /8s that are given allocated whatever from IANA to the RIRs with /8s to those RIRs, space that gets returned in those blocks remains with that RIR. The issue about the return to IANA was actually about the blocks that existed before the RIR system came up. That’s my recollection.

Scott Bradner: That may be true, but the wording, I believe, of the policy does not in any way refer to the genesis of the block.

John Curran: Right. That is correct. So this states that ‑‑ by the way, folks, you adopted this as 2011‑9 policy statement ‑‑ well, you want to actually look at the –

John Curran: Returned to the IANA by any means. Any fragments that may be left over in the IANA and will also hold any space returned to the IANA in any means.

Scott Bradner: Be returned.

John Curran: Which is struck from the final policy.

Scott Bradner: That’s a different policy ‑‑ the policy that said that we don’t return anything until there’s a global policy.

John Curran: Right. The global policy when it went from version 2 to version 3, in order to avoid the question, it became simply a policy for IANA reallocation.

Scott Bradner: I’m not talking about the previous policy.

John Curran: That one says that the Board designates. The policy that’s going to be adopted by the IANA says “space returned to IANA by any means.” So I would follow our existing practice.

Scott Bradner: Very specifically I’m not asking about the policy for the IANA, I’m asking the thing which you were talking about that enables you to recommend to the Board to return addresses to the IANA, not what the IANA does with it. So I’m talking about a different policy, and we’re talking about the earlier policy.

David Farmer: Can I help? I think Scott is talking about the policy where we said returned address space will go into the available pool until such time as there’s a global policy.

John Curran: And that covers all address space. That recovers returned, reclaimed and revoked, specifically. Until there’s a global policy.

Scott Bradner: Do you have the exact wording?

John Curran: I’ll give you words. Mr. Sandiford, go ahead, continue. Front center.

Bill Sandiford: Just another quick question. I’ve heard several times someone say this is our historical practice. How many times or how many /8s have previously been returned to IANA as part of this historical practice?

John Curran: I would need to ask the IANA. I know Leo put a list of some of them up. I believe it’s excess of six /8s. Elise, do you know how many /8s have been returned to the IANA over history? I have a list in my head which I can recall, which I know six of them. I don’t know the remainder.

Elise Gerich: It predates me, I’m afraid.

John Curran: Bill, greater than six. I don’t know how much greater.

Bill Sandiford: I can find out. I’ll know tomorrow morning.

John Curran: Thank you. Next read Joe’s comment.

Stacy Hughes: Joe Maimon, CHL: I would support returning as much space as ARIN could to IANA short of the last /8, where the 12‑month window to be readopted. At least 4/5 of it would then be used more wisely.

John Curran: Scott, to answer your question on what the text is, it’s Section 4.19 of the NRPM: “Until a global policy which clearly defines a mechanism for the reallocation of IPv4 addresses returned to the IANA is adopted in all five regions.” So until a global policy which defines a mechanism for reallocation of addresses returned to IANA is adopted in all five regions and implemented at the IANA, all IPv4 addresses returned to, recovered or revoked by ARIN will be made available for allocation or assignment in the ARIN region as quickly as possible.

Scott Bradner: Okay. Based on that, as speaking for myself as a Board member, I would not support the return of addresses reclaimed or revoked.

John Curran: Right, because it says “returned.”

Scott Bradner: No, you read that all three were there. The fact this policy gives the Board the ability to ‑‑ the implicit ability to return, to take revoked addresses, the particular case that was talked about, and send them to the IANA, I as a Board member would not support that. I would support addresses which were explicitly returned saying here, ARIN, here’s some addresses, not the ones which ARIN has revoked because of fraud or has reclaimed for other reasons, I would not ‑‑ I would not include those in what I would send to the IANA as a Board member.

John Curran: Okay. Good to know. Front and center.

Axel Pawlik: Axel Pawlik, RIPE NCC. I have a resolution from my executive board that instructs me to return returned legacy address space to IANA, and I think you understand that my perception is that the RIPE community doesn’t have any authority ‑‑ doesn’t have any allocation authority or policy authority over legacy space. We have registration authority where we get back such legacy space, it should go back to IANA so they can redistribute that to the RIRs which then we have policy authority on. So returned legacy space we should return to IANA.

John Curran: Okay. Center rear.

Kevin Blumberg: I just want to clarify. Kevin Blumberg. We have the ability to return.

John Curran: Yes.

Kevin Blumberg: I understand that. And if somebody came along and said: I have this space, I specifically want it returned to the IANA, the policy says if it is specifically asked for, then that should happen. But who says that we normally need to return space to IANA in any other situation? This is what I don’t understand.

John Curran: There’s no policy guidance in the NRPM.

Kevin Blumberg: There’s no policy guidance either way, right.

John Curran: Correct.

Kevin Blumberg: Why is the default to return to IANA?

John Curran: Our practice had been to do that when people approached us with space. But you folks can make policy if you want to change, make that explicit, either way.

Kevin Blumberg: But a policy that removes space from our region unto itself doesn’t make sense. It makes sense ‑‑ I’m not saying we shouldn’t do something, I’m saying that a default policy, when there is no policy, should not be to remove IP addresses from within this region unless it’s specifically requested.

John Curran: Then you should make clear policy that says what you think should be done.

Kevin Blumberg: Yes.

John Curran: Microphones remain open. Mr. Hannigan.

Martin Hannigan: 4.19 seems pretty clear to me, John. And you have said this space is in the available pool. It says that once the space is returned, revoked or whatever and put into the pool, it’s there. It doesn’t say anything about the space coming out. I think it’s clear as day, to be honest with you. And regarding the historical practice, you know, things change. And I think that that 4.1.9 actually changes that.

John Curran: Good view. We’re going to close the mics unless someone has more views. I don’t see anyone. Get to the mics quickly. They are closing. Remote participants as well. Go ahead, rear mic.

Michael Sinatra: Michael Sinatra, speaking for myself. I support the idea of legacy space being returned to IANA it if has global impact. Thank you.

John Curran: Okay. Thank you. I’m closing the microphones. I’m closing the remotes. Okay. Thank you for participating in this. Excellent.

Closing Announcements And Adjournment

John Curran: Okay. We’re actually at the end of the policy part of our wonderful meeting. Tomorrow’s going to be our Member Meeting. Tonight you are actually open and free. Let’s see –

Scott Bradner: Remind people everybody’s invited ‑‑

John Curran: Don’t forget to drop a business card in the registration table. We’re having a drawing. Please thank our sponsor, Telus.

[Applause]

John Curran: Reminders. Tomorrow is the Member Meeting. It’s open to everyone. Open to everyone. That includes remote participants. Breakfast will be served at 8:00 a.m., meeting starts at 9:00. There’s an agenda in your meeting folder or go online. That’s it. Thank you, and I’ll see you all tomorrow for the Member Meeting.

[Meeting adjourned at 5:30 p.m.]

Network Sponsor

Social Sponsor