Table of Contents
- Opening and Announcements
- ARIN Update
- Update on Advisory Council Activities
- Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
- Recommended Draft Policy ARIN-2015-5: Out of region use
- Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers
- Recommended Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool
- ARIN Public Policy Consultations (PPCs)
- Closing Announcements and Adjournment
Opening and Announcements
John Curran: Good morning. Welcome to ARIN's Public Policy Consultation at NANOG 66. I welcome you all here to wherever we are – where are we? We're in San Diego, the wonderful, warm San Diego. Someplace at the end of a flight, here we are.
So Public Policy Consultation is a discussion of the ARIN Internet Number Resource policy. We facilitate it in person. We do it online. There's remote participation. We do this at the ARIN meetings and we do them also at select events such as NANOG.
The most important thing to remember is that this is actually a discussion that affects the policies. Meaning, we're going to shape the policies that end up in the NRPM which affect how ARIN operates, how we administer Number Resources.
So to that end we'll allow remote participation. There's a webcast going on right now. Live transcript. Meeting materials. The chat rooms are open. Even though you see a handful of people here, there's also remote participants. And we'll make sure we include them in the discussion.
So during the discussion, I'm going to have Aaron Hughes, during the recommended policies, he'll be moderating, making sure that everyone can have an opportunity at the mic. State your name and affiliation – we're all used to this at these conferences – name and affiliation each time you reach the mic. And comply with the rules and the courtesies in the Discussion Guide.
So at the head table, myself, I'm the President and CEO of ARIN. Aaron Hughes, the Board of Trustees at the end. Dan Alexander, our AC Chair, and Kevin Blumberg, our AC Vice chair. We'll go through an update of what's going on in ARIN in terms of transfers and assignments.
We'll have a report from the Advisory Council of everything on the docket. We'll have an update on Number Policy discussions. And then we'll actually do Public Policy Consultations, where we actually go through the possible policy changes that we'll be doing.
That's it. I want to welcome everyone. And we're going to get started right in. First presentation is going to be the ARIN Update. And I should be able to get it – come on up, Leslie. This is Leslie Nobile, Senior Director of Global Registry Knowledge. Leslie used to run the RSD. She's now working directly for me, working on projects focusing on the integrity of the registry. Go ahead.
Leslie Nobile: Okay. Good morning, everyone. So I'm going to give you a quick update on what we're seeing at ARIN, now that we have depleted our IPv4 resources. And I'm mostly going to focus on transfers and NRPM 4.10 which is the reserve /10 for IPv6 transition.
So what are we seeing in a post‑depletion, IPv4 post‑depletion world. Well, we're seeing that the need for IPv4 is still great. We get questions. We get requests continually.
But what we're hearing now, which is sort of new, is that people, more and more people, are seeking IPv4 space in the transfer market. They're basically saying it's inevitable; they have no choice but to do that. So they're asking lots of questions and going to the market.
And because of that, we're also now seeing an increase in our specified and inter‑RIR transfers. And I'll talk about those in a later slide. But those are basically the market‑based transfers.
We're seeing more attempted hijackings. Now that there's such a high dollar value on IPv4 resources, there's a lot of people that are trying to claim them in the ARIN database.
So they're mostly targeting the legacy space, the space that's been sitting there since the late '80s, early '90s, space that hasn't been updated, the records haven't been updated in years, the space may not be routed, the domain may have expired.
So they're going in and they're reregistering these domains, and they're also looking for companies that perhaps have dissolved and they're reregistering the exact same company name and then they're basically trying to claim that they are the original company.
So ARIN staff is really kind of on high alert for these kinds of things. They're very good at detecting it and sort of locking it down. But we're seeing a lot of that. So it keeps them very busy.
And one of the things that we keep telling people, it's very important to keep resource records, POC records, organization records up to date. Even if you have no use for ARIN's database, I mean you're sitting there, come in and validate your POC when you get an email from us, because we send them annually. So if you validate it, it updates your record and people won't be as likely to target it.
We're starting to get more requests for /24s from that /10 I just mentioned. It is the block that's been reserved for IPv6 deployment. I'll have a slide a little bit later in the presentation. And we're getting lots and lots of question, lots of confusion around transfers, waiting lists, preapprovals, Specified Transfer Listing Service. People are confusing these things and not quite sure of the rules.
So we're working on our website, trying to update the content to make it much clearer. And we're also bringing this to our ARIN on the Roads, which is our on‑the‑road training sessions that we do, and trying to give more details about how it all works.
So we'll talk about transfers of IPv4 addresses first. There's three ARIN transfer policies that are available. There's the classic mergers and acquisitions that has been around forever. It's a traditional transfer. It's based on a change in business structure and it does include company reorganizations. And this is always supported by legal documentation. It's that classic merger acquisition activity. We don't focus on that, but we're mostly going to talk about the next two.
Transfers to specified recipients. That is in our Number Resource Policy Manual as No. 8.3. And this is one of those IPv4 market transfers. And it's typically based on a financial transaction between a source and a recipient, two parties. And it is supported by justified need within the ARIN region. In other words, if you are a recipient of resources under this policy, you have to qualify under an ARIN policy.
There is also Inter‑RIR transfers to specified recipients and that's NRPM 8.4 and that is very similar to 8.3. But it is for transfers that are based outside the region, space that's moving from the ARIN region to another RIR or space that's moving from another RIR into the ARIN region. But again it is an IPv4 market transfer and it is based on financial transaction.
So transfers to specified recipients. Just a little brief blurb about what it actually is about and what the criteria are. It basically allows organizations that have unused IPv4 resources to transfer them to an organization that is in need of IPv4 resources. The policy says that the source has to be a current registrant and there can be no disputes over the resources. So ARIN staff has to do vetting and make sure that it is the current registrant that is doing the transfer.
And the policy says that the organization that's the source cannot have received addresses from ARIN for 12 months prior to the transfer, and that's sort of an anti‑flipping measure that was put in by the community years ago. They didn't want people coming in, getting space from ARIN and then immediately turning around and selling it a month later.
There's also a clause in this policy that says that the source can then not receive additional resources for 12 months after the approval of the transfer or until the exhaustion of ARIN's IPv4 address space. That is no longer applicable and we don't apply that. That's actually one of the policy discussions today.
The recipient, the recipient has to demonstrate need for a 24‑month supply under current ARIN policy. So this is a really rough graph. It goes back to January of 2015, and it shows that we were not doing a lot of specified transfers. Probably 7 or 8 were getting approved way back when, we had a little spike.
Then the yellow line in June was when we initiated the waiting list, which is when we no longer had a large enough prefix to satisfy an approved request. And then in September, you can see the red line, that's when we actually ran out of IPv4 resources and that's when the specified transfers spiked. And that's what we're seeing right now at the same high level, and we expect that to increase.
So Inter‑RIR transfers. The main premise of this is that the other RIR that we're doing business with must have reciprocal compatible needs‑based policies. That was another thing the community insisted on. We can only do this type of Inter‑RIR transfers with an RIR that still maintains their needs‑based policy. Currently that's APNIC and most recently the RIPE NCC. LACNIC is actually talking about the same type of Inter‑RIR policy, and AFRINIC is just starting to explore that. We anticipate eventually that probably those other two RIRs will be doing transfers with us.
LACNIC is actually talking about the same type of inter‑RIR policy, and AfriNIC is just starting to explore that. We anticipate eventually that probably those other two RIRs will be doing transfers with us.
So the policy says that transfers going from ARIN into another region, it says the source cannot have received v4 address space from ARIN for 12 months prior to the transfer. Very similar to 8.3 transfers. It has to be the current registrant and no disputes. Again, same vetting process is involved on the part of the staff.
And the recipient has to meet the destination RIR's policies. And, again, there is that 12‑month clause that the source cannot come in and get resources for 12 months after the approval of the transfer or until exhaustion of v4 address space at ARIN.
Transfers coming into ARIN, they have got to – the recipient has to demonstrate the need for 24‑month supply under current ARIN policy. So this is just sort of high-level criteria.
This graph is sort of all over the place. But the thing to note, obviously, is once we deplete it, in September, well, actually, it was pretty stable. Then in November it shot up. And I think a lot of that is because the RIPE NCC implemented their policy in August and they were sort of getting their stuff together, and we started seeing transfers from them in October and November timeframe, so it has been increasing, and again we expect that to increase pretty drastically.
Okay. So here are some statistics. This is actually up on our website at that link below. These are just the resources that have been transferred via these two policies. So 8.3 transfers to specified recipients, 452 prefixes have been transferred, ranging from /24s to /10. As a comparison, in July of 2015, there were only 170 prefixes transferred. So in five, six months there was quite a drastic increase in the total number of prefixes transferred. That included 23 ASNs.
For Inter‑RIR transfers 201 prefixes ranging from /24s to /13s. And again for comparison, in July, there was only 45 prefixes transferred, and that was to APNIC. So the way it's worked, 188 have gone from ARIN to the APNIC region. Ten have been from ARIN to the RIPE NCC region, and three have been from APNIC into the ARIN region. That's kind of a new thing. For a long time it was just from ARIN to the APNIC region.
So the reserved IPv4 block for IPv6 deployment. A /10 was reserved under policy in April of 2009 and that is the /10, 23 dot 128, and to date 12 /24s have been issued. For the first five, six years, no one used the policy at all. It never got touched. But in recent months people are starting to realize that it is there, it is available and it is fairly easy to use and qualify under.
It has to be used to facilitate IPv6 deployment, and the policy gives some examples. And it says it can be used for IPv4 addresses for key dual-stack DNS servers and NAT-PT or NAT464 translation. Those are examples. One of the things that the staff is looking for, when someone comes in to apply under this policy, is that you already have, the organization already has an IPv6 allocation or assignment. We actually require that. You have to have your IPv6 assignment in order to get a /24 to facilitate your deployment.
The policy says one per organization every six months. The /24 is the maximum size. And this really should be enough to last for several years. There's over 8,000 prefixes, /24s in the /10. And it seems like a good interim option if your IPv4 needs are small. That's what we're mostly seeing right now, the smaller ISPs that are using the policy.
So looking at ISP members with who have actually come in to get their IPv6 address space, when we started tracking this in 2010, only about 20 percent of ARIN's ISP members, which was somewhere in the 5,000 range, had gotten their IPv6 allocations. And most recently, at the end of Q4, about 48 percent have now come in to get their IPv4 allocations.
So we usually show this slide and then that's the end of it. But Dan had asked me a question saying: Well, there's lots of ISP members but are those the small guys, the big guys, who is actually getting the space? So we did a little bit more research and we came up with this data. So ARIN has three categories and we categorize our membership as extra, extra small to extra, extra large. And you can see that the extra, extra small guys are the ones that are not making great progress. About 22 percent of them have gotten their IPv6 allocations.
But as you go up, extra small goes up to 34 percent. Smalls up over 50 percent. Mediums, close to 70. Large is over 70 percent. Extra larges are about 78 percent. And our extra, extra large ISPs are about 85 percent. So what we're seeing is that the largest ISPs are the ones that are actually leading the way, getting their space and hopefully encouraging their downstream customers to do the same.
And that's all I have. Are there questions? Hi.
Geoff Huston: Geoff Huston, APNIC. ARIN reports transfers in a transfer log service. I'd like to actually note that I find, as a consumer of that service, I find this report somewhat unsatisfying.
The first instance is transfers are now important, very important for v4. And while ARIN diligently updates its daily stats files every day, it less than diligently updates the log file sometime after the end of each month in an indeterminate date.
Leslie Nobile: Right.
Geoff Huston: So the data is at best a week old, at worst about five or six weeks old. For anyone trying to understand what's happening, this is probably not good enough.
I would urge you to take that log seriously and see if you can push it out every day in the same way that you push out all the other stats reports about activity.
The content of that log is also somewhat unsatisfying, in that it does not list the original dates associated with the resource. It simply lists the date of the transfer, and it does not give you any indication of the parties who transferred, whereas in other areas, including the extended stats file, that information is obtainable. So that in order to recreate useful data, I find myself burrowing through the entirety of the ARIN archive to actually programmatically discover what you already know. And while it's fun for both of us to duplicate this work to come to the same piece of knowledge, you really could have made my life easier.
And I'm humbly begging you to do so. So I would like a slightly more detailed log and I'd certainly like it produced daily. Thank you.
John Curran: So there was – press and hold. Okay. There was a policy proposal that came out a while ago for a much more detailed transfer log file. And it got some discussion and ultimately it was dropped because it didn't have a lot of support.
But that also was a discussion that branched into two directions. One is does it really belong in the policy manual at all? And the other one is should a detailed transfer log include such things as pricing?
So I guess the question is: Is there a standard format for, much like we have a unified stats format that's almost unified, is there a standard transfer format that would be useful among the RIRs? Because it would be far better to have one log file format that we issue than three or four of us all doing it differently.
Geoff Huston: Thank you, John, for that question. I'll answer. There is no standard transfer format at this point in time, unfortunately. APNIC update their transfer report daily using a format similar to the stats file, including the dates of the original registration, the date of the transfer and the names of the entities, no pricing.
The RIPE NCC do a similar format produced daily but don't give the original registration date, just the date of the transfer, and again it's a case of recreating some data.
I would have thought it's not within – not impossible for the RIRs who are doing this to agree on one format. And I would encourage you and my organization, RIPE, to do so and produce the daily information.
I'm not sure as registry folk that the price is that relevant to us. That information is really someone else's business. But the nature of where the addresses are moving and who is moving and the dates at which they move and the age of these resources is important.
If I could just continue for one second. Part of the rationale for doing this was the realization that we had come to exhaustion with this huge pool of legacy resources that were inefficiently used.
And we honestly thought, or at least I did, that the transfer market would unleash some of those old resources and actually alleviate some of these pressures in this strange inter‑reg of moving to v6.
It would be good to understand from stats that that is indeed happening, that those old addresses are actually being mined for transfers and being reused. And that's a good thing.
But if your logs don't help us show this, then I think we all get a little bit frustrated. So I think we can do a better job.
John Curran: Do people want to respond to that? Mark, I see you?
Mark Kosters: This has been sort of a side conversation going on with the various RIRs on dealing with this. And actually within two weeks we should have a specification for transfers.
John Curran: Useful. Thank you.
David Farmer: David Farmer, University of Minnesota, ARIN AC.
Leslie, you mentioned on the four point – the 4.10 transfers that you are asking the resource or asking the applicant to have their v6. Is that an ARIN allocation or assignment or would a provider allocation meet the –
Leslie Nobile: Provider allocation would meet our requirement.
David Farmer: Thank you. That's all. I just wanted to clarify.
Leslie Nobile: Absolutely.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, quick question with the 4.10 transfers. Are reserved blocks, especially the 4.10, which is a contiguous block, transferrable after the fact? I.e., is it not prohibited in policy today; is that something we should be looking for in policy, if the whole point of this is to have one contiguous routed block?
Leslie Nobile: That's actually a really good question, and it probably is something to consider because there's no prohibition in the policy at this point.
Okay. That's all I have. Thank you.
John Curran: Thank you, Leslie.
John Curran: Very good. Next up, chair of the AC, Daniel Alexander, will give the AC Update.
Update on Advisory Council Activities
Dan Alexander: Good morning, everyone. Thanks for coming. One of the main reasons for this PPC is so we can gain feedback on some of the proposals that the Advisory Council is working on, because we're tasked with developing these proposals and forwarding the ones to the Board that we actually feel that the community wants to actually implement the change to how ARIN does their work.
So right now we're working on several draft policies, which are in an earlier state of the process where we're crafting the language, getting feedback, finding out the pros and cons of those.
When they get to a particular state where we feel that that language is stable and has a fair amount of consensus, the proposal is moved to a recommended state, where we feel, okay, this is pretty much ready to go. We want that final feedback from the community.
So you'll see that there's actually two being discussed today in a recommended state and two being discussed today that are still in a draft. Once those recommended proposals are to a point where we feel they're ready to go, then we forward them to the Board after last‑call period for people having an opportunity to have their final say, and then the Board reviews whether or not the process has been followed and that actually implements the change.
So today we have two drafts or two proposals in a recommended state, two that are a work in progress that are still in draft state. There's also three other proposals on our docket but will not actually be discussed here today, because they're still in an earlier stage where we're crafting the language, and they'll likely be discussed at the next ARIN meeting in April.
Some of the other work that we do, in addition to the proposals that are on our docket, is we often take feedback from the staff. And they provide that to us via the Policy Experience Report at the ARIN meetings.
And there's two topics, one of them we were just talking about here that we've been debating within the AC. That is the routability of micro-assignments through Section 4.10. There was actually a proposal done a while ago, 2014‑22, that was discussing the minimum allocations that are made from that pool, because there's questions about the routability, if somebody came and said I need a /26 from that allocation, how successful they would be? That proposal was actually abandoned, but we now also have a new topic to discuss, which we were just covering earlier.
That proposal was actually abandoned, but we now also have a new topic to discuss, which we were just covering earlier.
There's also a topic that we're dealing with that Leslie brought up in her report as well that the return language around 8.2 transfers, some view that as an issue because it tends to frighten some people away from actually coming and doing the transfers when in fact it really – it shouldn't be that kind of a problem. So we're discussing whether or not that language should be removed.
We'll also talk a little later today at the end of this session about these PPC formats because we're always interested in feedback in how we can improve these meetings and what data could be provided in these meetings that the NANOG community finds useful.
And we've also been working on different ways to collect community feedback via online polls or other mechanisms.
And then the final topic that the AC has really been working on is how to simplify the policy manual. We've spent years and years kind of applying Band‑Aids to different situations, trying to fix smaller problems. And as a result, the policy manual has become somewhat cumbersome - rather large. So now that we're in a depleted state and v4 is kind of done, how can we scale back that language so people can get their job done and it's done in a clear set of policies?
So with that we can jump right into the policy discussions. You want me to switch this?
John Curran: I can do it. Thank you, Dan.
Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
John Curran: Okay. Moving right ahead. Our first discussion up is Draft Policy 2015‑2, Modify 8.4 (Inter‑RIR Transfers to Specified Recipients).
Chris Tacit, come on up.
Chris Tacit: Thank you, John.
All right. Thanks. Sorry.
John Curran: Sorry, I left one button. Down here. Looks like a podium. I'll do that right there.
Chris Tacit: Thanks.
John Curran: Now it should –
Chris Tacit: All right. Now it should be good. All right. So the problem statement that led to this Draft Policy relates to parties getting numbering resources based on a 24‑month supply via the transfer market, and then having an unexpected change in business plans where they operate multi‑nationally across RIRs and being unable to transfer any of those resources out for 12 months as a result of ARIN's anti‑flip provisions.
So this is the text of the current bullet that we're focusing on, the fourth bullet of section 8.4 of the NRPM. And it includes language that relates to both transfers, allocations or assignments of IPv4 resources and creates that anti‑flip restriction.
So this proposal sought to remove the word "transfer" from that bullet, thereby enabling transfers of numbering resources to another RIR after somebody does receive resources via transfer, in case their business plans change and they need to reallocate some of their resources across other portions of their network that happen to be situated in other regions.
So that is the rationale, and it enables those numbering resources to not be locked into ARIN's Whois for the 12‑month period but to actually be transferred to the other RIR.
So I just want to stress that the underlying reason for this is that 8.3 transfers are approved for a 24‑month supply, and on occasion a business model may change after one receives resources under 8.3. And those changes may require the use of those resources elsewhere in the world.
But that this policy language that was proposed is not intended to affect assignments and allocations which would still be subject to the 12‑month restriction. So that was the original proposal. When discussion was sought on PPML, there were basically two views, if I could put it. One was this isn't ARIN's problem, we shouldn't bother with this. The other was ARIN members operating global networks prefer to deal with one RIR as much as possible and this policy should reduce incentives to game the system, which is possible under the current system. It's possible to circumvent this anyway by using alternate means.
So based, however, on the feedback that we got, which suggested that this may not be ‑‑ there may not be sufficient anti‑flipping protection ‑‑ we are now proposing a further amendment to the policy which hasn't been formally tendered yet. And that amendment would create the necessity for some sort of affiliation relationship based on ownership and control between the entity that's under ARIN's jurisdiction and the other entity that would be the recipient of the resources. The amendment really is largely based on US statutory provisions that are commonly used in corporate law to define affiliation relationships relating to ownership and control.
So therefore under this proposed language, the fourth bullet of 8.4 would be changed to read as you see on the screen. The red text would be the new text. And basically, it looks a bit lengthy, but basically it just says that there is an affiliation relationship between the two, a corporate affiliation relationship such as one that would be recognized under US law.
This restriction, of course, wouldn't affect M&A transfers. And because we didn't want to have the definition of control embedded in here, you need to have ‑‑ when you talk about ownership and control in legal terms, you have to define what control means.
We didn't want to clutter this bullet, so we're suggesting adding a definition of control to the definition section of the NRPM that would be used here and in fact probably this is the only place, I think, that it would be used.
So that is the upcoming proposal. And at this point I guess I'd really appreciate, subject to the Chair's guidance, to see what input the community may have on that proposed language before we decide whether to go ahead with it or not.
John Curran: So the floor is open. Come speak at the mics if you want to talk about this proposal.
Matt Petach: Matt Petach, Yahoo! I'm sorry, but your amended language makes my head hurt. I think it's language only a lawyer would love. I understand that there's a desire to try to firm it up as much as possible. But we've been looking for a while now to simplify the NRPM.
And as much as I sympathize with your desire here, I do not think this goes in the direction of simplifying the NRPM. I'm sorry.
Joe Provo: Joe Provo, Google. Wondering where the sweet spot is in the mic. I'd like the retention of the concept that we brought up in previous meetings, that we wanted to guard against anti‑flip.
To my colleague from Yahoo!'s point, perhaps moving it in the definition is the right place so the NRPM itself reads clean but the people that want to dig into the legalese can move into the legalese.
Chris Tacit: I'm sorry, I'm having trouble hearing you.
Joe Provo: To my colleague from Yahoo!'s point that moving the new text into the definitions may help preserve the visual cleanliness and be able to have somebody who wants to dig into, gosh, what does control really mean, be able to understand it. In general, support the direction.
Chris Tacit: Thanks. The definition of control is moved, is to be moved in the definition section. So I agree with that.
Joe Provo: So I think that my point is that perhaps the concern over the cruft in the NRPM is not going to be in the block so it actually is legible, but those who wish to dig into the meaning. I don't think we can get away from having this block of legalese, as you guys have explored.
Chris Tacit: So what I'm hearing is there's a tension between the complexity of the wording and the desire to ensure that we do the maximum amount of guarding against abuse of the flipping. So that seems to be the tension I'm hearing.
Any other feedback on this? Okay. Thank you very much.
John Curran: Thank you.
Recommended Draft Policy ARIN-2015-5: Out of region use
John Curran: Okay. Next up we have Recommended Draft Policy 2015‑5, Out of Region Use. And I'll do the – I'm going to do the introduction. I'm going to have the AC member come up and present, and then you moderate the discussion. Just trying to sequence here.
Okay. So here we go. So the history of this, 2015‑5 Out of Region Use, it originated as ARIN Policy Proposal 2019, 219 ‑‑ it does sound like there's a lot of policy proposals ‑‑ 219, which was submitted in May of last year.
The AC shepherds, the people who are chartered with working this policy to a good state, is Tina Morris and David Huberman. It was presented at ARIN 36 in this past October. It was discussed there.
And afterwards it was advanced to Recommended Draft Policy. The text is online and in your Discussion Guide. And basically it would allow an organization to receive Number Resources from ARIN for out‑of‑region use as long as the applicant is currently using at least the equivalent of a /22 of IPv4, a /44 of IPv6 or one ASN within the ARIN service region.
In addition the applicant must have a real and substantial connection with ARIN in the region, which the applicant shall be responsible for proving.
It would increase the complexity a little bit of our staff review, meaning there would be criteria that would have to be applied but at least they're clear criteria.
And that means increase in vetting work. It does require some coordination with counsel regarding the costs and implementation, because we would be in some cases dealing with entities that, where the one contacting us is outside of the region, potentially, because a business unit of a company is – even though it may have resources in this region, the office that's contacting us might be in another location. There's no legal risk. It's just the cost to deal with that.
The implementation issues: So additional review steps, we need to do the training steps to write that out, train staff. And then we may have a requirement for unicode character sets. Because some of the parties we'll be dealing with may not be able to express in simple ASCII. And so that would keep Mark and company busy for a few days and we don't know how much of that or where it would occur, but parts of this could lead us to having to do coding changes to make a more flexible registration system and accommodate unicode. Not that that's not good work to do, but it's still work.
And that aspect could take longer than the rest of the policy. So now I'm going to have the presentation by the AC, and I will have Tina come up and give that presentation. Sorry, I always have to blank out at least once. And let me just get your slides up. Oh, look at that.
Tina Morris: All right. So basically, as John just explained, you know, we've gone through several iterations of this policy because the current NRPM does not clearly allow or forbid out‑of‑region use. This is our most successful attempt at getting this policy through.
Basically, if you have ARIN‑registered resources you can use them outside the service region. They're valid for justification for additional Number Resources, provided the applicant has a real substantial connection to the ARIN region as stated in the policies. Somewhat lengthy but I believe it's quite clear at this point. It's easy to follow.
It's a long policy, though. At ARIN 36, we were able to kind of get through the noise and everybody's fear about out‑of‑region use policy and get to the actual language, and once we did that, we found there was a great deal of support.
We actually had a unanimous show of support to move this policy forward and the AC meeting we moved it to Recommended Draft Policy. Since that time there's been no discussion whatsoever on PPML. It's actually a little bit disturbing as the shepherd of the policy to know whether everybody's is supporting that move to Recommended Draft Policy or not. But there's been no discussion whatsoever.
So we're just looking for support. Is this a good thing? Should we move this forward? Does this solve a real problem for you? Or is there a problem that is still with this policy language?
John Curran: Now, Aaron is on the Board of Trustees and will moderate the discussion of the policy. So people who want to speak on this policy, please come forth to the microphones.
The microphones remain open. Don't all line up at once.
Matt Petach: Matt Petach, Yahoo! We're still talking about this? I thought it was done. What more talking do you need?
Tina Morris: It's just the formal process. We had to move it to recommended. Last call would be next after this meeting, if we get support. We just need support.
Matt Petach: Okay, do we all need to stand up and do jumping jacks in support? We did a unanimous show of hands. I thought that was enough. Here's support.
Tina Morris: It was at Draft Policy at that state. Then we had to move it to recommended. Now we're at recommended –
Matt Petach: Now we're at recommended so we can all support it again and say we still like it.
Tina Morris: Exactly.
Matt Petach: Then we still like it, yes.
Tina Morris: Okay, awesome.
Aaron Hughes: Thank you. Front microphone.
Bob Evans: Bob Evans, Fibernet Center. Yes, I support this, but I'm just wondering in this long list of demonstrating how much of this list is going to actually be required by staff in order to get something acknowledged, because my experience has been often this kind of text is somewhat used as an excuse, and there's just a huge list here. And I think the text needs to define that all of it is not required. Does it?
Aaron Hughes: Request for staff feedback?
Bob Evans: Pardon?
Aaron Hughes: Is this a request for staff feedback?
Bob Evans: No, it is a criticism of staff using the text.
Unidentified Speaker: [Indiscernible].
Bob Evans: Yeah, but will staff require all of the bullets or what percentage of the bullets? And this is not really clearly established here.
Tina Morris: The language is that these are elements the staff may use to consider and it will be left to the staff's discretion.
Bob Evans: That's what I don't like.
Tina Morris: Okay, thank you.
Aaron Hughes: So, just to be clear, are you in favor of the policy proposal or are you opposed to it as written?
Bob Evans: I'm opposed to it as it's written due to the fact that staff can't say, oh, you've got two of these demonstrated. Now I want three. You see? This is what's happened in the past to a lot of people. So I just want to kind of clarify that.
Tina Morris: Thank you.
Aaron Hughes: Thanks very much. Do you want to speak to that?
John Curran: So the language that prefaces that long list is simply being incorporated in the ARIN region shall not be sufficient on its own to prove that an entity is carrying on business in the ARIN region in a meaningful manner.
So if you send us just the incorporation paper, the staff says: We've already got guidance; that in and of itself doesn't cover it, please provide us something additional. Methods that entities – so this is what you would do – methods that entities may consider using including cumulatively to prove they're carrying on business, include – in a meaningful manner – include demonstrating X, demonstrating Y, demonstrating Z, demonstrating K, demonstrating L, demonstrating W.
Any other method, and the last one, any other method that the entity considers appropriate. The weight accorded to all the above factors shall be determined solely by ARIN. So to answer that, we're not going to say you need to provide us all of this.
You need to provide us what you consider credible information. And if we don't think that's enough we may ask you to supply another one of those documents. It is not a, "You must supply all of these."
In some cases, it's very apparent when someone comes to us that they're operating in the region. We have had cases in the last few years where we've had entities whose ability to show that they're operating in the region is tenuous at best. And so that's why it's hard for us to be more specific.
However, that's how we would implement the language as written to the extent that people want different language they should definitely propose it.
But as written, we would take what you give us and if we thought we needed more we would suggest that you go back to the list and give us one or more elements. But it is not a statement that says we require all of those as written.
Aaron Hughes: Thanks for the feedback. And just to validate, does that change your support for this policy proposal as written?
Bob Evans: I guess so. And if it becomes a problem in the future, I'll let you know. But the fact that – I'm an entity. I can file a DBA and have a business. I don't need to be incorporated. And I can actually see staff actually ask for that and create a process that's longer than it needs to be. So that's what I'm concerned about. As we move forward with all this legal language that my peer from Yahoo! there mentioned, I just hate to see stuff like that that's not definitive enough.
I think maybe if you said two of these, then the staff maybe can't be so liberal about their opinion, something like that. I'll go ahead and propose some language.
Aaron Hughes: Great. Thank you for the feedback.
Joe Provo: Joe Provo, Google, just quick support. Yes, yea, I agree with my colleague from Yahoo! Yes, let's keep going.
Aaron Hughes: Thank you.
Mike Joseph: Mike Joseph, Oracle. I strongly support this policy, and I also want to thank all the folks who have worked on it for the past two years to bring us to where we are. I know that some folks don't find this to be complete or perfect. Very few policies that come through here are. But in particular, I think it took a lot of hard work by all the folks who have done this and a lot of discussions of which, many of which I've been a part for the last couple of years to get this to where it is.
So this may not be a perfect policy. But I think we finally found a set of guidelines and language that is able to address the needs of various constituents in the community as well as ARIN staff.
So I strongly urge us to move forward with this policy now that we're at recommended draft state. And we can come revisit it later if we feel the need. But it's long overdue to get this on the books. So thank you and strongly in support of this policy.
Aaron Hughes: Thank you for your feedback.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. For those that are wondering why we're talking about this again, I'll refer you to the minutes of the September AC conference call from last year, and that should pretty well cover it.
I'm in support of the policy as written, as I was at the September call.
Aaron Hughes: Thank you.
Brandon Ross: Brandon Ross, Network Utility Force. I was going to make another comment and then I actually read it and figured out the comment I was going to make is not necessary, so I'll just stand here to say I very much support the policy.
Aaron Hughes: Thank you very much.
Chris Tacit: Chris Tacit, ARIN AC. I just wanted to make a remark. I think the intention of that list was actually to be a helpful guide for the kinds of evidence that people could actually provide rather than being any kind of restrictive or comprehensive requirement.
If you look at the language before, and especially the word "include," it is an inclusive list. It is to help people get some guidance rather than it just being a totally open-ended and you have to stab it in the dark – take a stab in the dark of whether ARIN will find the kinds of evidence you're supplying to be helpful. That was the intent of that language. There has to be, in my view, some discretion allowed to ARIN staff to assess this. These sorts of tests are based on the kinds of tests that courts use to assume jurisdiction over parties in legal proceedings. And it's the same kind of substantial connection test.
And, yes, somebody has to turn their mind to how that test is going to apply to the facts. ARIN staff will develop the expertise to do that as it goes through these over time. And I'm sure that it will do so responsibly, as it always does. Thank you.
Aaron Hughes: Thank you.
Chris Tacit: So, yes, I'm in support of the policy.
Chris Woodfield: Chris Woodfield, Twitter. First off, I am in support of the policy. I have a question about, is there any current documentation – I realize this will make this largely an academic question – but is there a current definition in the policy of out‑of‑region use other than what I assume is just assigning an ARIN IP to a network or a device element that's outside the region? Is there anything more specific than the current policy?
Tina Morris: No, just outside of ARIN. It does not get more specific about where that would apply.
Chris Woodfield: Thank you.
Aaron Hughes: Microphones are open. Any other feedback? Do we need to do a show of hands?
So we're going to do the show of hands for, first in support and then following that not in support of 2015‑5. So at this time please raise your hands if you are in support of forwarding 2015‑5. Keep them nice and high.
John Curran: Keep them in the air, please, nice and high.
Aaron Hughes: Are we good on numbers? Now, please raise your hand if you are not in support of forwarding this Recommended Draft Policy 2015‑5. Keep them nice and high.
Thank you very much.
John Curran: We have tabulation going on now.
Aaron Hughes: For 2015‑5, we have 50 people in the room, 21 in support, in favor, and 0 against. Are there any online?
John Curran: Four of those were online.
Aaron Hughes: Four of those online. This information will be forwarded to the AC. Thank you very much for your feedback on 2015‑5.
Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers
John Curran: Lovely. Okay. Moving right ahead. Next up we have the discussion of Draft Policy at ARIN 2015‑7, Simplified Requirements For Demonstrated Need For IPv4 Transfers.
Kevin Blumberg: Good morning, everybody. So I wanted to show you the problem statement for this policy. This is an overview. In your Discussion Guide is actually a much longer problem statement, but for those in the room that might not be familiar with this policy already, I wanted to sort of bring it down.
So currently ARIN transfer policy inherits demonstrated need. Demonstrated need is probably one of the most talked about aspects when it comes to getting space from ARIN. And anything related to a transfer today takes the demonstrated need requirements that are in Section 4 and applies them to Section 8.
The issue is that most of Section 4 was designed around a free pool. Many of the caveats were designed around a free pool. And then even as we got closer to the end of the free pool runout, they were further locked in more – as an example went from 12‑month needs justification to a three‑months need justification within inside of the free pool. There were other changes as well over time as we got closer to runout.
So this proposal seeks to simplify the needs‑assessment process for 8.3 transfers while still allowing organizations with corner case requirements to use specific policies in Section 4.
Okay. So just to start here. Staff has said that they will apply this Draft Policy – and this is a Draft Policy. So we're looking for your feedback on good things, bad things, do it just like this, et cetera.
And there's some staff and legal feedback already, we'll talk about in a minute. But the original intent from drafting was to put it in 8.1, a new section, and later on staff actually said, no, we'll just apply it to section 8.3 and 8.4, keep it similar, don't need to apply a new section to it.
So I wouldn't worry too much about the specific wording, but more the general concept, and if you do see an issue with this or you do like it or don't like it, that's what we're more interested from a feedback point of view.
So the change to needs‑based would be IPv4 transfer recipients must demonstrate and an officer must attest – again I'm paraphrasing this – that they will use at least 50 percent of their aggregate IPv4 addresses including the requested resources on an operational network within 24 months. Organizations that don't meet this criteria can use something from Section 4 if that is the case.
So staff and legal did come back to us and they said that this policy language would apply to 24 months needs assessment for 8.3 and 8.4 transfers and preapprovals as well.
In order to verify the demonstrated need of 50 percent, the policies of Section 4 would still apply. This wouldn't be an anchor in Section 8 on its own by itself, standalone. Demonstrated need is well talked about in Section 4. So the parameters around the demonstrated need would still be used from Section 4.
This would potentially allow organizations to get a greater amount of space than they could currently get under existing policy. Could be implemented as written. And again the change, they'd do it in Section 8.3 and 8.4 and not create a new section.
Legal assessment: We always love when lawyers give us their advice. We are silly if we don't heed them. No material legal issues exist. Wonderful to see.
The next point was sort of a note to readers. This policy if adopted would significantly lower the degree of utilization requirement and permit significantly larger transfers, which is also what staff said. This is in effect a bridge between maintaining a lighter needs‑based structure that permits substantially greater transfers dot, dot, dot, my emphasis – without removing needs basis completely which is something that the community has been uncomfortable with in the past.
So this is a stepping stone, a very large, in my mind, stepping stone, but still a stepping stone. And the last part was an issue that does not have to be resolved with this policy is whether an acquiring party taking appropriate advantage of such a policy change ought to have a corollary duty to fully disclose to ARIN whether they may have use of any other resources by agreement that effectively reduces their overall Number Resources.
So one of the issues that we're seeing and one of the issues we're seeing in the region is that there are corporations that may have leasing agreements that are not on the books with ARIN. They have no idea that you're also happen to be leasing space from over here or that you've got an intent for space over here and things like that.
So to me what counsel's comments – and by all means if I'm wrong let me know – is if we're going to make things that much easier, maybe we need – you should be disclosing it as well. But at the same time he's saying this doesn't necessarily need to be there today. This might be an issue at a later time and it's something to consider.
So what I'd love to hear from everybody in the room, or those that want to do it, do you support this as written? Do you support it with changes? Do you not support it? And any feedback on top of just more than just plus one, yes, I support it, would be really helpful to the shepherd. I'm not the shepherd for this, but this will be detailed to the shepherd.
John Curran: Just note that the counsel comment is simply people have to demonstrate when doing a transfer that it will result in a certain utilization percentage.
That demonstration and the percentage calculated is only meaningful if we know the total resources that they control.
And so to the extent that that's expected, we need to be very clear about that. If it's a percentage of whatever resources I happen to tell ARIN I feel like I control but not all the resources, then anyone can qualify just by not identifying resources that they might hold in other regions.
So it's just a note that, when we calculate a percentage, it's only as accurate as what people want to tell us. And if the intent is that they tell us all resources they control, then that should be made clear.
Dani Roisman: Dani Roisman with SoftLayer. I think it's good, generally. As you guys probably already know, I think all needs‑based assessment for transfers should be eliminated entirely. I think anything that gets us there is a good idea.
I think this is a decent stepping stone, if still the member community at large is not ready for the end game, which is eliminating all needs‑based, in my opinion.
I think we should at least go through and make it as easy as possible to complete the transfers that businesses need to complete.
Kevin Blumberg: Dani, quick question: From a text point of view, do you find that the text as written is simple for you as an organization or in general to use an implementation? Are there more simplifications minus removing needs completely, which is not what this policy is?
Are there any other changes that you could see or you like this text as written?
Dani Roisman: I thought I liked it as written until what John just said. And I want to get a clarification.
So this text doesn't specify resources in the ARIN region or resources globally. Is the intent to be resources in the ARIN region or resources globally?
John Curran: Wow, I have to push at the same time as I am flipping through the document. Yes. Thank you.
Okay. So if you look at the text, it's ambiguous. It doesn't say one way or the other. But it does say policy statement, "IPv4 transfer recipients must demonstrate (an officer of the requesting organization must attest) that they will use at least 50 percent of their aggregate IPv4 addresses, including the requested ones, on an operational network within 24 months." So we're going to be getting attestations from the people making the requests. They say, hey, here's what I'm going to transfer and it's going to be 50 percent ‑‑ within 50 percent utilized.
My only question is, absent any clarity, if someone says, "Here's the resources I have in the ARIN region that I control," or "here's the resources that I have globally," if there's guidance to the staff about which it is we're looking for, I'd like to see it in the policy. Absent that, we're going to take anything they say. That's all I was pointing out.
Absent that, we're going to take anything they say. That's all I was pointing out.
Dani Roisman: I don't have the NRPM in front of me, but I believe Section 4 only has to do with ARIN resources, going back and showing utilization of previously assigned ARIN resources, right?
John Curran: It's not clear either way. Particularly in a world where we're issuing resources for out‑of‑region use, it's not clear at all. So just the policy intent is unclear. I'd like to make sure that folks understand we will implement it generously.
And if you expected us to get attestations of all resources or just resources in the region, you should make that clear.
Kevin Blumberg: Two comments to that.
The first is the more resources that you're able to detail, the larger the request can be. So there's actually a benefit, the more you detail. That's the first thing.
The second thing is, I think we need to take this back and think about it as well, how does 2015‑5, which just had a lot of hands up, which is the out‑of‑region policy, apply and meld into this policy?
Does this policy – is this policy straightforward enough that it doesn't touch the out of region in any way? And that's maybe something that we need to take back and think about as well.
John Curran: There's one more. The other nature is sometimes people have control of address blocks that are not listed to them. Meaning it's, for example, provider‑assigned. They've done a provider‑assigned address block. They're coming, looking for more resources. And if they count the provider‑assigned block, they don't qualify. So obviously they shouldn't.
My question is should they be? What did you want us to do? Did you want us to count the provider‑assigned or not, because we need to guide them to what they're attesting to. That's my only point.
It is that we'll attempt to take any attestation that attests to any of the resources that we can validate and hits 50 percent, but it might not be what you people in the room think. And that's what counsel's comment is to.
Dani Roisman: So like I said, I had one opinion until I heard that. Now I realize the word "aggregate IPv4 addresses" which the Section 4 says "previously assigned resources," which makes it a little clearer that it would be, because we're talking about ARIN, so it would be ARIN‑assigned resources, at least that's how I would interpret it.
We probably need to tweak that to remove the aggregate IPv4 addresses to remove the ambiguity, I think.
Kevin Blumberg: Thank you.
John Curran: Let me ask the question: if that said the aggregate of previously assigned ARIN resources, would you support the policy?
Dani Roisman: Yes, I absolutely would.
John Curran: So you believe it's supportable with that change, but you would not otherwise?
Dani Roisman: Yes.
John Curran: Okay.
Matt Petach: Matt Petach, Yahoo. I will just note that Section 4 phrases it as ISPs must have efficiently utilized all allocations in aggregate to at least to 80 percent, 50 percent blah, blah, blah. It doesn't say ARIN or global.
And from the past dozen years of advising on paperwork, we like the flexibility of being able to interpret that as we saw fit for whether we listed just ARIN resources or global resources.
I think we might need to get more feedback from the community at large before we decide to lock that in, because that will impact many companies' behaviors in terms of address utilization in different regions.
I generally support this. I do see some definite challenges in the, shall I say, conflicts with Section 4. I think this actually highlights that we're probably going to need to go back and revisit Section 4's needs‑based guidelines in a big way after this.
But for this particular section on transfers, yes, I support it. And I actually like the ambiguity of not specifying whether it's global or ARIN or whoever else's blocks.
Kevin Blumberg: So one thing else to consider is if we do specify to the region, would this then apply to 8.4 transfers?
So this was meant to apply to both 8.3 and 8.4 transfers. We could have one piece of language that's specified in the ARIN region for an 8.3 and we could add in the other piece of text for 8.4, just to differentiate a little bit.
So just that's another piece of feedback that we'll take to the shepherd.
Geoff Huston: Geoff Huston, APNIC, neither for nor against. But certainly having a common problem.
With this discussion about ambiguity here, you previously mentioned the leasing word. And indeed that's one of these other areas of profound ambiguity.
Is our registry a registry that is tantamount to title, or tantamount to operational control? Because leasing exposes that difference where the, if you will, titled entity is someone other than the entity currently using those addresses.
In APNIC, we're struggling around this, because we don't quite understand how to reflect a leasing arrangement in the details of our policies and our registry.
And I suspect the creative ambiguity is flooding in here where someone who is leasing is I suppose in a rather strange position of how to declare that interest back into an ARIN registry. And it exposes that fundamental question.
So without saying for or against, I'd certainly be interested, and I am interested in watching how you folk in this region are kind of dealing with this leasing issue and how it is certainly possible today to gain control of an address, quite legitimately, without being reflected in the registry, and through various letters of authority get it out into the routing system. But the registry doesn't actually reflect that. So I'm certainly interested as an observer.
John Curran: That's an excellent point, Geoff. If you follow counsel's comments, he notes: While not necessary for resolving this policy at this time, it does raise the question specifically we would be interpreting this policy by default as a title question: Who was the assigned owner of the rights of record of an address block?
But it does raise the question of: Are we supposed to ask someone to attest not only for the rights that they directly hold, but also for those that they might control indirectly?
And that's not necessary to pass this policy. But the community should understand: If it doesn't, if it wants those included, most certainly the present text does not address that.
Derek Lazzaro: Derek Lazzaro, University of Southern California. First time here. Very interesting discussion.
One thing that isn't entirely clear to me, just as I look at the text of the policy statement, it says that "transfer recipients must demonstrate and an officer must attest."
And so the question I would have, just reading that sort of on the face of the language, is would the attestation of an officer be sufficient demonstration? In other words, is there some additional supporting documentation?
And like the other one that we saw with sort of the examples, what would that look like?
John Curran: So the way this works right now is we work with the requester to make sure we can approve the request. When we're completely done with that, we take the material and we say: Now with this cover letter have your officer attest to that.
But we work with the requester to make sure that they qualify and then the officer attestation is just certifying that what we received is accurate. So we process the request first and then we attest to have it in our records so that you folks know we're processing accurate requests.
Kevin Blumberg: John, to clarify, the officer attestation within the idea of using it in the community has been so that fairly boisterous predictions get brought down to reality through an officer attesting to those rather than just some marketing person.
John Curran: Well, yes. But furthermore, a representation by an officer or company is a different thing than a representation by anyone else in the company.
Matt Petach: Matt Petach, Yahoo! with kind of a dumb question for clarification. On the question of title versus leasing arrangements, does ARIN have a particular stance on the same block of addresses being used by multiple companies to justify additional transfer of resources if, for example, you have Leasing Entity A that has a block of addresses that are in, say, an access network pool. And it is being made use of by ISPs B, C, D and E, and it happens to be a very, very densely utilized pool, would ARIN have an issue if entities B, C, D and E all pointed to it and said, look, we've got this 95 percent utilized block that's under our control, we should get more space?
Or would they go back and say, okay, you can't all claim that same block as justification, only one guy really gets to use that?
John Curran: We have not had that occur. I would say we actually look at the address blocks that parties are listed as the address holder in the registry, and then we do look at provider assigned space to them as well.
And both of those are exclusive arrangements. We do not have a group sharing that we've used to justify resources in the past. You would need to write some very cool policy to make that happen.
Matt Petach: So this is unchartered territory. I like it. Thank you.
Kevin Blumberg: Based on time and the wonderful carpool discussion, we're going to need to close the mics on this policy. We'll have it up on the PPML as well and probably more at the April meeting as well.
Recommended Draft Policy ARIN-2015-11: Remove transfer language which only applied pre-exhaustion of IPv4 pool
John Curran: Okay. Moving right ahead. We're down to our second Recommended Draft Policy. It's Recommended Draft Policy 2015‑11. It's remove transfer policy language which is only applied pre‑exhaustion.
So I will do the introduction. 2015‑11, the history is ARIN Policy Proposal 225, which was submitted in September of last year.
The shepherds are Milton Mueller and Robert Seastrom. It was presented at the October meeting. It advanced to Recommended Draft Policy after the meeting in December.
The text is online and in our Discussion Guide. Calls for the removal of language in 8.3 and 8.4 that sets a condition on the amount of time that must pass before the source of an 8.3, 8.4 may request an additional IP address space as recipient.
Now, it's removing that language because the language is only operational up until runout. And folks who may have missed this, our free pool ran out in September of 2015.
Further policy text due to IPv4 depletion, ARIN staff no longer applies the 12‑month lockout to people who have previously been assigned a resource.
We do know that there's other language that we do apply having to do with organizations from being a source in a transfer if they've been a recipient of space, but that's different text and not affected. And that would remain in place.
The policy can be written – implemented as written. The legal assessment: No material legal issues.
It would have minimum resource impact, because effectively we're already operating under it. We would just need to reflect our guidelines, but it's nominal.
I'll now turn it over to the AC for their presentation. And coming up is Kevin Blumberg.
Kevin Blumberg: Good morning again. So I'm going to run through this one a little faster, if that's okay with everybody. We spent a little bit more time on the last policy.
I think the bulk of it is: This is policy that was time limited for when we ran, when we hit free pool exhaustion.
In Montreal, staff were asked – and, Leslie, you're here so I'd appreciate you just confirming this – that irrespective, if space came back and ARIN suddenly had a free pool again, limited free pool again, this policy would still not apply because it was a point‑in‑time policy.
Once the policy – once that clock hit, this policy portion was done. So one of the main reasons for this is any extraneous policy in the NRPM leads to confusion.
People don't know that this policy is ineffective. Staff know it's ineffective. Some of the people in this room might know it's ineffective. But when you're reading a policy and trying to figure out how you're going to deal with space, you don't know that.
So it's a massive confusion level for leaving this type of text in here, and that's why this is being done.
So for the discussion part, what I wanted to bring up was: When we move a policy from draft to recommended, the AC does a statement of conformance to say that a policy is technically sound, it's fair and impartial, et cetera. And this was the policy statement from us moving this from a draft to recommended state.
And what I'd like to ask is: Is there anybody here who does not believe we should move this forward; that there are still issues with this to move the inoperative text? Or do you support it?
If there's no discussion, if it's a yes or no and there's no real discussion, what I'd like to do is move it to just a show of hands just for expedience, but if you want to have discussion, by all means let us know. We'll wait a couple seconds, if anybody would like discussion on it versus just the show of hands to support or nonsupport. Perfect.
Aaron Hughes: All right. Okay.
John Curran: Our tabulation engine is being set up. There she is.
Aaron Hughes: We'll ask two questions: First is looking for show of support of ARIN 2015‑11, Remove transfer language which only applies preexhaustion IPv4 pool. And I'll ask anybody for who is not in favor.
So at this time please raise your hand if you're in favor of ARIN 2015‑11. Keep them nice and high.
Good on the count? Thank you very much. And please raise your hand if you are not in support of 2015‑11. Keep your hands up nice and high. Thank you very much.
Okay. For 2015‑11, we have 23 – what's the number in the room? 50 in the room; six in chat. 18 in favor in the room. Five in favor on the chat for a total of 23 and 0 against.
Thank you very much for your feedback. This will be passed to the AC.
John Curran: Very good. Okay. And now we're getting towards the end. We have the update by Dan on ARIN Public Policy Consultations.
ARIN Public Policy Consultations (PPCs)
Dan Alexander: All right. So first I just wanted to thank everyone for their feedback. The AC actually does find this very useful and being able to talk to you about the language in these proposals is very useful to us.
I really wanted to just also kind of give an update. These PPCs, they primarily are a tool for the AC to use in developing these proposals. But we also want to be able to have both a conversation with the community and also provide information that people may find useful.
So when we look at prior feedback, just wanted to provide a quick update: Some of the things that have changed since we started doing these, because they continue to evolve. Based on this feedback, one of the things we did was during the joint meetings in October we stopped having these sessions during a NANOG meeting, because a lot of people felt they were redundant.
So we started just having these on stand‑alone meetings. One of the other things that we've also started doing is we changed the way that the Advisory Council works with the program committee in coordinating these.
And then we were also trying to craft little different presentations like Leslie gave in the beginning of some of the data that we provide more like statistical information about transfers, things that are going on with the registry.
And with that, we're also always open or curious about your feedback on different things that you would like to see, information you would find helpful from the registry or from the Advisory Council.
And with that, I'd like to just open up the mics, and if anybody has any thoughts, please let us know.
John Curran: Microphones are open. Remote mics? Anyone have thoughts or comments on this topic?
Matt Petach: Matt Petach, Yahoo! I just want to give a thumbs up for the format. I like the cherry picking of hot topics, keeping the topics flowing quickly and not turning it into the three‑hour‑long snooze fest it had been in the past.
Awesome work. Thank you.
Dan Alexander: Thank you. All right. Thanks.
John Curran: 100 percent of those who spoke were in favor. Noted.
Closing Announcements and Adjournment
John Curran: Okay. I'd like to thank you all for coming; and as Dan said, this is a fairly important part of our policy process. The fact is that ARIN only meets twice a year, and sometimes the AC wants feedback in between and it's good to actually hear from the community.
You can only poke the Mailing List so often. Face to face people tend to generate more ideas. However, if you like that face‑to‑face involvement, two meetings coming up: ARIN 37 will take place in Jamaica, the 17th through the 20th of April. Just a few months away. That and also coming up at the end of the year, joint with NANOG, ARIN 38, in Dallas, Texas.
These will both be face‑to‑face meetings with full remote participation.
So if you have the time to travel and can do so, we look forward to seeing you there. If not, we'll see you as remote participants. Thank you for coming.
Oh, yes, if you know someone who should participate in one of these but needs financial support to do so, we have a Fellowship process.
So we have people who sometimes can't afford to come but with some support could and could help get information about ARIN out to their communities. That will open up very shortly. Pay attention to that on the Mailing List.
Thank you all for coming. This ends the PPC at NANOG.
(Applause.) (Meeting adjourned at 11:00)