ARIN PPC at NANOG 64 Transcript - 01 June 2015

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.

Table of Contents

Opening and Announcements

Paul Andersen:  Let's get started. My name is Paul Andersen. I'm the Vice Chair of the ARIN Board. I'm filling in for John Curran, President and CEO, who sends his regrets. At the last minute he was unfortunately unable to travel. 

Welcome to the ARIN Public Policy Consultation. First question, we just thought we'd ask, put your hand up if this is your first time attending an ARIN PPC or PPM. Don't be shy. That's good to know we have some new faces. 

So ARIN, as you know, is the organization that assigns, for the North American region, Internet Number Resources, and we assign and allocate those resources based on a community-developed process. And that community-developed process is done through what we call our Policy Development Process. 

Hopefully all of you picked up a Discussion Guide that's available there in the back. And if you haven't already, maybe just grab one. Because that has all the policies that we're going to discuss today and also has this great flow chart on page 15, which, if you're new and aren't familiar with the policy process, just gives you a quick glance how we develop policies at ARIN. 

One of the important functions of the policy process is the Advisory Council. That's why we're here today. The Advisory Council is an elected-member body of 15 volunteers from the community who help move forward policies that have been proposed by the community. 

They effectively make sure this process is followed and work on the community's behalf to develop good, technical, and sound policies. And one of the reasons we're here today is to get operator feedback into our policies. 

Without further ado, there's about seven policies currently in the chute. We'll be discussing only four today. 

Again, they're all in the Discussion Guide. A few notes before we get started:  It's an open public discussion. Anybody who is in this room is entitled to speak, make comment. Please feel free. It's very important because your input is invaluable in developing these policies. 

We'd also like to note and welcome our remote participants listening out there. There are remote participants. That's why it's very important, if you are to speak, we ask you to approach a mic so you can be heard. There's also a live transcript. And there's a chat room. So for those that are remote, if you do want to ask a question, you can just do so in the chat room and it will be read out here by Kevin Blumberg sitting up here at the head table. 

Just a few rules and reminders when we do get into the policy discussions that I will, as the chair of the meeting, moderate all discussions, make sure everyone can be heard. 

It's very important you do speak your name and an affiliation so that you can be recognized, and please, we ask that you comply with our rules and courtesies which you can find in the Discussion Guide. 

Today up here with me is myself, I'm Paul Andersen. We have Dan Alexander, Advisory Council Chair; Kevin Blumberg, Advisory Council Vice Chair, and Leslie Nobile, who is with ARIN staff. And at the head table we have our jabber machine so all our remote participants are sitting right there in the middle of the table. 

We've got a few things we're going to discuss today. Leslie's first going to give us the status of the IPv4 free pool, a hot topic these days. 

And Dan will come give us a report on the current Advisory Council activities.  As I said, we're going to discuss four draft policies. And then another item which, by the way, just for those that usually do attend, we are going to have one special topic -- we'd like to take some time to discuss the future of these ARIN Public Policy Consultations. 

So if you do have some time, please stick around, we'd love to get your input. With that, I'd like to invite Leslie up to give the report. 

Status Of The IPv4 Free Pool

Leslie Nobile:  My name is Leslie Nobile. I have a very quick update on the status of IPv4 depletion at ARIN. As you know, we're getting very close. 

So I'm going to talk a little bit about changing dynamics. This is the stuff we're seeing with IPv4 depletion. Lots of different behaviors, lots of different things going on. 

One of the big things with depletion is that we did an IPv4 Countdown Plan, and we phased it in in four phases. And each phase had different processes and procedures. And we got a little tighter on the way we review requests, the closer we got to depletion. 

So in phase four, all of our IPv4 requests are being team reviewed, which means that they're being reviewed in the order they're received, and they're being reviewed by more than one set of eyes so that we always have an objective, sort of objective people looking at each request and making sure there's consensus on the way to move forward with each request. 

We think that's the fairest way to proceed, given the depletion, impending depletion. So that has actually slowed down our processing quite a bit. I think our SLA is a two-day response time, and I think we're on a four- to five-day response time right now.

One of the reasons we're so slow at this point is because we have started seeing a real increase in IPv4 request traffic. Particularly in the last few weeks we've got several hundred requests sort of in some state, some pending state right now. 

So things are a bit slower. Also, with v4 depletion we have a new customer profile. We have first-time people coming to ARIN, brand new customers who know nothing about ARIN, who typically have gone to an upstream IP for space, but we've seen a lot of upstream ISPs telling downstream customers go to ARIN. There's a policy where you can get your own /24; we want to keep a hold of our own space. We don't know what's going to happen in the future, so you go to ARIN, get your own. 

We're dealing with a lot of first-timers; doing a lot of education and hand-holding, and that's slowing things down a bit as well.

Additionally, we already have an increased workload. But we expect that to increase quite a bit more. And that's mostly due to the transfer market. We expect, when we deplete, which should be sometime in the near future, like the next month, maybe, we're going to have a lot more transfers going on, and a lot of the transfers are going to be market transfers of legacy space, space that's been sitting in the ARIN database since before ARIN's inception, space that we inherited from the InterNIC.

And a lot of that legacy - those legacy registrations are stale. The data is old. So we're going to be doing a lot of chain of custody verification and vetting on that kind of space. 

And additionally a lot of it, as I said, is stale. So some of it is going to be in some company name that was bought or sold five or 10 years ago. So a lot of people, it's going to be a two-step process. They're going to have to do an 8.2 merger and acquisition transfer first, and then they'll proceed to do that 8.3 market transfer. 

So that's going to definitely increase the workload. So our current IPv4 inventory. We've got two categories:  We've got what's available and what you see on the website. And then we have sort of "other" inventory. 

So the available inventory right now stands at .15 /8 equivalents. This is space that's not being routed -- that's being issued, ready to go. And so that's what we're issuing from right now. 

Then we have other inventory that you don't see. And there's sort of two categories. We have our quarantine space. And this is space that we get back due to returns, voluntary returns, which we do get, or revoked space, space that we revoked due to nonpayment of registration fees. 

So we hold that space for 60 days to clear filters. Then we check the routing and then we'll reissue the space. We'll actually reissue it, put it back in inventory and reissue it. 

Some of the space is actually still being routed. And we will take that space and put it back at the bottom of the pile in a 60-day hold. But at some point we're going to have to start issuing that space because we're almost down to nothing. And we're going to have to start issuing everything we have. I think people are going to sort of demand it. 

Additionally, we have the quarantine space, space that's automatically released at 60 days. We have what we call reserve space. And that's put on indefinite hold. It's typically reserved for policies. 

There's two policies right now that we're holding space for. One is a dedicated IPv4 block to facilitate IPv6 depletion. And we put aside a /10, per the policy, for IPv6 implementation. We issued a single /24 from that /10, quite a bit of space that's sitting there, and it will stay there unless the policy changes.

We also have a /16 set aside for the micro-allocation policy. And that's for critical Internet infrastructure. And there's 218 /24s remaining in that space. And again that space will stay there and it's specifically reserved for policy. 

There's actually a second /16 that's going to be reserved for the micro-allocation policy. I think we're putting that policy into effect in June. We're implementing it. We'll put aside a second /16. We'll pull it from somewhere in here, and put it in reserve for this policy.

Additionally, we've got eight /16 equivalents that we've put in this reserve indefinite hold space until we can do further research. And this was space that we reclaimed due to fraud or hijackings, and it needs quite a bit of chain of custody research. It takes a long time to find out whether these businesses are still -- or whether they've been dissolved or whether they went to bankruptcy or whether there's a successor company. A lot of research that has to be done. 

So we're still sort of working on these eight /8s doing the research. I actually have a project where I'm researching all of that. So some of these may move over into our available inventory as soon as we clear these up. 

So on our website, we list the block-size distribution of our remaining IPv4 inventory. So on our home page is the total amount of space in the inventory; and if you click on the link on the front, it will take you to this. And it shows how many prefixes we have left. 

So we're down to almost nothing. Especially in the larger blocks. We've got a single /11, single /15, single /16 and a /17. And other than that, everything is the smaller blocks. 

So it could be that that /11 will be broken up in order to issue qualified -- maybe a /12 request or a /13 request. We're not sure yet. But it's likely that will be broken into smaller blocks. 

What do I want to say about this? You'll note that we've got over 500 /24s. At this point, ARIN mostly issues /23s, /24s, some /22s, but we're issuing a lot of smaller blocks.

We still have quite a few, but once we get rid of those larger blocks, I think that the request traffic is going to increase, and we'll go through the smaller blocks rather quickly. 

Okay - so I mentioned our inventory changes daily. That's not an accurate picture of what we have. If you want to see all the space we have, go to our extended FTP stats. There's a link at the bottom of this page. 

And this really tells you exactly what ARIN has. It tells you what all the RIRs have, in fact. It's a joint project. We worked on it together. It was for accountability, transparency, and it basically shows which RIR is responsible for which resources, and it identifies -- it's a way for us to identify inconsistencies and overlaps, which, when we first did this project, there were a few inconsistencies and overlaps. Some RIRs were claiming space that another RIR had in their database. 

So we cleared all that up and it's a really good way of accounting, basically. So it is a daily snapshot of all ARIN-issued resources, everything we've issued that day and previously, all of our available resources, and then all of our reserved resources. 

And a couple of notes on this. On the previous slide I had other inventory, and it was broken into a couple of categories: quarantine and reserved. All of the other inventory from the previous slide shows up as reserved on the extended FTP stat. If you're actually looking at the extended FTP stats; quarantine and reserve is going to be in there. 

The other thing to note is that 8.3 transfers, those are the market transfers, specified transfers, they're going to show up as issued. If there's an 8.3 transfer completed on any one day, it's going to show up as issued as new space, basically it's going to a new company. However, 8.2 transfers, which are merger and acquisition transfers, we made a business decision to retain the original issue date on those, so they're not going to show up as issued. 

If you do an 8.2 transfer it won't show up as issued. I think that's all I have on that slide. 

So we get asked this question:  Once you hit zero, is that the end of it, will you ever be able to increase your space again? And the fact is we will. We're going to count down, we're going to get all the way to zero probably in the next month or two. 

And then we're going to have bits and pieces coming back. So our inventory is going to go up and go down. It's not going to go up a lot, but it will go up and down. And there's four ways that addresses come back into ARIN's free pool, and that is through voluntary returns, which, amazingly enough, we are still getting. 

When we do get returns we tell people, we send them email and we say:  You have an option; you don't have to return it. It's nice that you're doing this, but you have an option to transfer this space via this policy, if you're interested. And people still give it back. They want to be good citizens. So we do get voluntary returns.

We're continuing to revoke space for nonpayment. We have a very long process for nonpayment, for revocations. And I think it goes to 100 -- over 180 days, back and forth, we send lots of emails and certified mail, et cetera, et cetera, trying to find people to pay the bills. 

And eventually, after 180 days, we will revoke the space. So some of it does come back. Some of it does get paid for, eventually. We will continue to reclaim space due to fraud, violation of the Registration Services Agreement, or business dissolution. When we find a business is completely gone, there are times that we will take that space back. 

What we found is a lot of the legacy space that sat in the database for a long time and wasn't being routed was being hijacked. Lots and lots of spammers, they target that space, they take it, start rerouting it and start using it. And when we find stuff like that going on, we'll actually pull the space out of the database. That's some of the space that I told you that's in inventory that still needs some additional research.

Our fourth way is from IANA, IANA-issued space. And believe it or not, we're still getting space from IANA, per a global policy. It's called Post-Exhaustion IPv4 Allocation Mechanisms by IANA and basically it's a policy that allows IANA to issue to the RIRs any bits and pieces that they have left.

Previously they had only issued the RIRs /8s. This policy allows them to issue, in equal amounts, whatever space they have left twice a year to the other RIRs. So far we've each received three allocations. We got a /11 in March -- or May -- whatever of 2014. We had a /12 in September of 2014 and a /13 in March of 2015. 

And we're due for our next allocation in September. So it's March and September that we typically get these. IANA still does have some space. So we will get our next allocation. It's probably going to be a /14, but I'm not positive. 

The space that they have right now is space that the RIRs returned to them. So they had little bits and pieces, but we, mostly the three large RIRs, APNIC, RIPE, and ARIN, returned 1.21, 1.22 /8s in total to the IANA a couple of years ago. That's the space they're issuing to us currently. 

And just as a side note, ARIN has recovered 3.54 total /8s since 2005. And that's via reclamations, returns, and revocations. Space does come back, it's much slower now, but anticipate still getting space back. 

Paul Andersen:  Questions? If you would come to a mic.

Dan Alexander:  What about the waiting list?

Leslie Nobile:  I can talk about it. Real quickly, Dan asked me to mention the waiting list. So all of the other RIRs have what we call austerity policies, last /8s policies, where, when they got to their last /8, they would only issue a single /22 to organizations. 

ARIN has no such policy. We don't have a real /8 policy, a real last /8 policy. So we'll issue all the way down to zero. But what we do have is a policy called a waiting list, waiting list for unmet requests. 

So you noticed -- and I'm just going to go back if I can to a previous slide. For example, if a company comes in next week and qualifies for a /10, we don't have a /10, the waiting list will kick in. 

We basically say you can accept a smaller block, what's the smallest block size you will accept. If they are willing to accept a /11, we'll issue a /11. But if they say, no, we'd rather wait until a /10 comes in, they can go on a waiting list. We anticipate that starting anytime now, like maybe in the next week. 

So we're kind of preparing for it. We're ready. We've got all of our software in place and all procedures in place. That is going to happen very soon. So you'll have an option to take a smaller block or be put on a waiting list and hope space comes back. So just -- Kevin?

Kevin Blumberg:  Kevin Blumberg, The Wire, AC.  I just wanted to ask Leslie about the waiting list. In some of the other regions, they would give out aggregate blocks -- if you needed a /10, they would give you a bunch of -- an /11, a bunch of /14s, a 16, and sort of slap it all together and give you an aggregate. 

In the ARIN region, that doesn't apply. You get one block of the correct size, if that size doesn't exist; is that correct?

Leslie Nobile:  That is correct. Our policies require us to issue single prefixes. We cannot issue multiple prefixes to satisfy a request. So we can't combine a /10 and /11 or two /16s to make a /15. It's got to be a single prefix.

Update on Advisory Council Activities

Paul Andersen:  Next I'll invite Dan up to give the AC report, as I quickly switch over here. Is it C or C underscore? I'll go with the one updated today.

Dan Alexander:  Hopefully the right slides. Hello. As Paul mentioned earlier, the Advisory Council, we're a 15-member body that were elected by the community to act as the facilitator of managing policy proposals or suggested changes for the Board of Trustees of ARIN. 

There's 15 of us. And you can see in the picture, it was a little cold. This was January when we all met in DC. So we tried to take this picture quick. 

But here in the room today is actually Scott Leibrand, John Springer, Kevin, and myself. And Tina Morris. Save the best for last. 

Unidentified Speaker:  Good save.

Dan Alexander:  The purpose of the AC is to help facilitate that change. Because a lot of times, for the people who raise their hand at the beginning that are kind of new to all this, you sometimes see on the Mailing List these conversations, well, ARIN does this and ARIN does that. 

And in reality, ARIN actually just follows the rules that the community agrees upon. So somebody in the community or elsewhere will say, you know what, the way these resources are managed, we think we should do it this way. And that results possibly in a policy proposal. And then it becomes a task of the Advisory Council to make sure that that fits the guidelines of actually becoming an actual policy. 

So we need to make sure that it's fair and impartial, technically sound, and it's actually supported by the community. Then once we actually cultivate all of that into something that we think we can reach consensus, it's then forwarded on to the Board of Trustees to actually become a policy.  

And in the end, ARIN, as in the staff, all they're really doing is implementing all the policies that we come together and make. 

So right now we're currently, there are seven proposals submitted so far this year. 22 were actually submitted last year.  Today we've got four that we're going to talk about. And we have an additional three that we have not actually yet moved on to a draft status where we have clarified that these are something that we're going to actually work on. 

So in order to advance these four drafts, we're going to talk about them here today, and the whole reason we're here is actually to get this room's feedback and opinions, because as network operators, it's actually a very valuable perspective for the Advisory Council to hear, because we look at different things like the Mailing List. 

ARIN has their Public Policy meetings twice a year as well. But to actually be in this forum is extremely valuable for the Advisory Council to hear these different perspectives.

So there are three proposals that are brand new - they were just recently submitted. So they're in the initial review process. And they're not going to be talked about here, but just to touch on them briefly.

One of the proposals we worked on last year was actually abandoned because people couldn't come to a complete agreement as to how that should be managed. But when the Advisory Council abandoned it, we said it's still a valuable topic. So we wanted to continue working on it. So it's actually coming back in a new version, and it discusses how ARIN-allocated resources might be used outside of the region. 

There's also another proposal to consider the utilization of those resources outside of the region, and a third is how to simplify the needs requirements for v4 resources when they're transferred. 

So we're going to be reviewing these three proposals at our next meeting. And at the joint NANOG/ARIN meeting in October, if we accept these, they'll likely be discussed there. 

So one of the other areas where we actually get feedback from, in addition to the community, is ARIN provides a staff and experience report at the ARIN meeting. And it basically provides feedback to us based on all of the calls that they field from Registration Services, all the applications that are being made from different people. And they provide us some feedback as far as lessons learned and problems that they're seeing coming in from the community as potential changes that we could make to policy to help people out.

Four of the items they mentioned on the last Experience Report were POC validations, how 8.2 transfers are dealt with due to a company's reorganization and experience with /24s, which we recently changed the policy as far as how we lowered essentially the minimum assignment down to a /24 for both ISPs and end-users. So they're gaining experience as to how that's being implemented. 

And there is also an immediate need topic that we're looking at as well. Any of these topics, if someone in the room have an interest or would like to find out more, definitely reach out to any of us after this session or even if we have time during the open discussion at the end we can possibly even bring those back up and talk about it.

Some of the other work that the Advisory Council is looking at is one of the things that Paul mentioned at the beginning when we were talking about the agenda. We've had a couple of these sessions here at a NANOG meeting and got a lot of feedback and the AC has been talking with the Program Committee as well about how can we improve these sessions, because there's different opinions of how useful these are or can we change the format to facilitate better feedback, or is there information that the NANOG community would like to see from ARIN that would help them understand how these proposals or these ARIN policies impact your day-to-day work, how you manage resources. 

So that was one of the key things that we wanted to reserve some time at the end of this session to have kind of an open dialogue, and as the AC gain a little better input from everyone here in the room as to how we can improve this format. 

One of the other topics that we're looking at is one of the common ways, when we're all in a room meeting and we're talking about these proposals, you know we get a sense of the room, everybody raise your hand, how do you feel about this kind of a change.

And that's somewhat limiting because it's restricted to who is in the room and who may be on line at the time of remote participation. But it's not a very wide reflection of the wider community. The AC is looking at different ways that we could reach possibly a better or broader audience to gain feedback on some of the changes that we're making, whether that's online polling. 

A third piece is the Number Resource Policy Manual simplification. One thing we commonly hear is this thing is really complicated. We've got a policy for this, that and the other, and there's so much language that you have to hire a consultant to try and sort out and why can't we just make this easier where we come and ask for our resources or we ask for an update and staff will just take care of that. 

So we're looking at different ways that we could possibly simplify this policy manual, make it easier to understand, and also we're looking at the fact that, as Leslie pointed out, ARIN's free pool is just about done. 

So much of the policy manual, a lot of the policies written in there are based on people coming to ARIN and getting an allocation from the free pool. What happens in a post-depleted world when that's not so relevant, can a lot of the policies -- do they still maintain their relevance or should we just possibly have policy discussions to maybe do away with them?

So that's another thing that the Advisory Council is looking at. And that's the current state of some of the things that we're dealing with. 

Paul Andersen:  Any questions for Dan? Thank you, Dan. 

ARIN Draft Policy 2015-1:  Modification To Criteria For IPv6 Initial End-User Assignments

Paul Andersen:  We have some new bodies. We'll now go through the four policies, spend about 15 minutes each. A member of the Advisory Council is going to come up and give a quick overview of the policy. 

For those following along, the first one we're going to do you'll find on page 5 of your Discussion Guide. As I said before, you can get a concept of the PDP on page 15. And for those not familiar, on page 17 the NRPM that Dan was mentioning has what is the current policy. 

With that, we'd like to do ARIN Draft Policy 2015-1:  Modification to Criteria for IPV6 Initial End-User, and ask Scott Leibrand of the AC to come up and give a presentation, after which point we'll have some discussion. 

Scott Leibrand:  Greetings. Welcome. The problem statement here is fairly simple. We have a pretty good IPv6 policy that allows for a lot of people to get space for whatever they need it for. 

There is, however, one class of users for whom getting space directly from ARIN is not allowed currently, and for whom getting space from their upstream or doing a number of other things that would otherwise be options would introduce a need to renumber their network when they change things. And that would be cost prohibitive for them; and, therefore, it would be advantageous to everyone if we made it easier for those users to get space. 

Those users are -- those organizations are networks that have a minimum of 13 active sites. So the idea here is that these sites would have to be in a contiguous network. They would have to -- as I said -- have to have at least 13 sites. And that would get them a /40 under existing policy. So that would be the threshold for getting a block directly from ARIN as opposed to an upstream.

The idea behind that threshold is largely because there's a cost to all of us as network operators of carrying that table. We don't want anybody to just get it for any reason, but it would be useful for these networks to be able to get space if they're that large. What are we talking about, what kind of network is this?

An example would be an organization with 50 locations, 10 staff each on average, 20 devices, voice and data subnets. They're not multi-homed. And in IPv4-land, they're using 10 space and NAT. 

In IPv6-land, we don't really want them to use NAT 6.6. We don't really want them to have to multi-home, because they have one provider that's providing an IPVN. That's great. BGP multi-homing would be wasteful. 

And the other option under existing policy would be to have them just go ahead and get an IPv4 block, because if they got IPv4 block then they would qualify for a v6 block.

Well, if they can get by with the PA space that they've got, not get a new block from ARIN, and just go straight to v6 for their ARIN-issued space, that would be great. So we want to make that possible. 

So this is a fairly simple constrained use case. I can go into more details if you want, but since we have limited amount of time, I thought I'd breeze through that and see if anyone has any questions, comments, support. Do you think it's too loose? Too strict? Do you wonder what in the world I'm even talking about?

I want to get it straight open for questions. This was not very controversial the last time I presented it. So we'll see if anybody has any comments here. 

Paul Andersen:  So please approach a microphone, because we do have remote participants. If you're on the remote, feel free to ask a question and we'll read it in queue. 

If you're in this room, hearing the sound of my voice, you're entitled to participate. Sometimes it's useful, even if you can come up and say I think that's a good idea or a bad idea. Sir, name and affiliation.

Bill Goldstein:  Bill Goldstein, retired AT&T Product Manager and Internet services. My affiliation is myself at this point. 

Some of this information is interesting. I was dealing with these issues just before I retired. Maybe find a way to get some of this to some of the friends and the group I was dealing with so they might address this. 

The one thing that concerns me for ARIN is the addresses are now rightfully or wrongly considered property of certain organizations. Mergers, acquisitions, even in bankruptcies. And they're being traded. 

And my concern is that ARIN has adequate legal counsel. So if you're in a situation where you're saying, no, you can't do that or something, that there's a log and somebody has perhaps, say, a large corporate sponsor who thinks differently, that this organization which does an absolutely essential service but does not have the agendas that some others do is protected. 

Paul Andersen:  So as it relates to this policy?

Bill Goldstein:  Not only this policy, but a lot of what you've been going over in general as far as who owns IP addresses, who can transfer them, how they're transferred, et cetera.

Paul Andersen:  Right now the discussion is focused just on this policy. But we can have comments off line later if you want that. 

Bill Goldstein:  Again, it doesn't affect me directly. I've seen and heard enough stuff go on in my experience in this industry to worry that someone, some entities, because of their resources, may try to take advantage. 

Paul Andersen:  Understood. But at this time we're just talking about this policy. Thank you, sir. 

Any other comments or questions about this policy?

Kevin Blumberg:  There's a remote participant, Gary Buhrmaster, no affiliation. Am I correct that once the IPv6 space was assigned via this change, that having IPv6 would now justify being able to obtain IPv4 numbers out of the reserve transition block?

Scott Leibrand:  I heard the question. I think what he's me asking is does getting v6 under this policy then allow you to get v4 space under, I believe it's 4.10, the v6 transition space?

I think that would probably be a question for Leslie. But if she doesn't know the answer, I'll look at the text and see if I can figure it out on the fly. 

Paul Andersen:  Any other questions or comments? I might take a second here --

Leslie Nobile:  So 4.10 actually says that you can get a small IPv4 block in order to facilitate your transition to IPv6. So if you need it, in order to implement IPv6, you can get the IPv4 block, not the opposite way, which it seems like he's asking.

Paul Andersen:  If he wants to repond, he'll type. Any other comments people want to say as it relates to this policy, in favor or against?

Mike Joseph:  Mike Joseph, Google. I support this policy. We need to make sure we don't raise the bar too high for v6 adoption, and this seems like a sound way to get there. 

Paul Andersen:  Thank you, Mike. Other comments? It's very helpful to get "I support," "I don't support."

Kevin Blumberg:  Two things from Gary:  Thank you. That answers my question. So he was happy with that. And I actually have a question, Kevin Blumberg, The Wire. I run a much smaller provider. I have customers who -- 13 sites is a big deployment. 

In the IPv4 world, you could almost say that the number of sites could be significantly smaller. You could have one, two sites, as an end-user you needed 50 to 100 IPs in use to get going and get your first allocation. 

So right now you need 2,000 addresses within 12 months. This policy is trying to say or 13 sites. And I guess my question for the community, and what I would like to see, is something a little more realistic for what we would actually define as a small end-user case. 

I think people have a problem with one, two, or three, because that's smaller routes in the table. But if a company has five sites, why would they be excluded from getting IPv6 today?

This policy, I think, has a very good use case. But I think it could be expanded to allow a decent number more by lowering the 13. 

Scott Leibrand:  One follow-up question to that. What do you see as the level of renumbering burden for getting provider-assigned space in like the five site case? Because the problem statement of this particular proposal is that for organizations with 13 or more sites the renumbering burden is just too high and it justifies putting another route in the table to allow them space. 

Where do you think that crossover point is?

Kevin Blumberg:  I would say that the burden of renumbering, when you're a company with three people, is the same as the burden when you are a company of 15 people; i.e., if you have 13 sites and you have 13 employees, the burden is probably equivalent to a smaller company that has less employees and less ability to deal with it. 

The burden of renumbering is not my issue. The issue for me is that these are companies who are asking, pleading with the community to have globally unique IPs that are not tied to any one specific provider. And what we're now doing is we're specifying the size to exclude what I would consider to be small organizations. 

Scott Leibrand:  I'm trying to figure out if this is a modification to this policy that we're proposing or a new policy idea that would expand things further?

Kevin Blumberg:  I'm saying that the number 13 could be a smaller number and would allow the use case to expand to a larger group of --

Scott Leibrand:  I would love to hear -- this is the first feedback I've ever heard whether 13 is the right number. I would love to hear more feedback from the community whether that's --

Paul Andersen:  13, good number, bad number? Come on up. 

Jason Parsons:  Jason Parsons, Saffron Solutions, I think 13 is a bad number. [Laughter]. 

Paul Andersen:  Do you have a counterproposal?

Jason Parsons:  I think any number is going to be arbitrary. I agree with Kevin's observations that -- I'm a consultant. My client base is primarily smaller enterprises. 

The burden of renumbering for them is high. Their networks have a significant deal of complexity but would largely be under the 13 number. It feels a little arbitrary to me, although I recognize that any number is a little bit arbitrary.

Paul Andersen:  Next speaker.

Mike Joseph:  Mike Joseph, Google. Again. I'm not taking a position on a number. But I would say that I think as a community we need to be cautious about recognizing an unfunded transfer of costs. 

While small entities might have a larger burden of their budget spent with renumbering, remember that if we gave every entity of any size IPv6 space, then every other network on the planet now has to carry those prefixes and bear those costs. 

So I do think we need to remember that we can't really weigh this as the impact just on the entity affected. We have to strike a balance, because while it may be unfortunate for you to have to renumber, it's unfortunate for me to have to carry your prefixes because you won't. 

Paul Andersen:  Thank you. I'm going to close the microphones unless somebody wants to approach now. So we'll close the microphones. Microphones are closed, unless there's a remote participant squeezing in. 

Kevin?

Kevin Blumberg:  There is none.

Paul Andersen:  Thank you very much for the feedback on this. The AC appreciates it. 

(Applause.)

Draft Proposal 2015-2:  Proposal To Modify 8.4 (Inter-RIR Transfers To Specified Recipients)

Paul Andersen:  I'll slide to the next slide deck. I'm going to invite Tina Morris to come up and present Draft Proposal 2015-2, a proposal to modify 8.4 inter-RIR transfers to specified recipients. 

Tina Morris:  ARIN 2015-2, if you've followed PPML, you've probably seen a lot of chatter about that lately. This was a proposal David Huberman and I put together to simplify the 8.4 transfer policy and allow space -- basically, if you transfer it in, you can transfer it out. 

Currently when you go and request space, you request a /24 via the transfer market. So you've gone and you've justified internally that you need space. You've found a source and you've transferred it in. You can get a 24-month supply. 

Within that 24 months, the first 12 months, you cannot transfer it out of the ARIN region. We found that to be a problem sometimes because business changes in that first 12 months, and you may need to do something outside of the ARIN region. 

One example of that that has gotten a lot of attention is work in China, where you need to transfer space to that region. The current ARIN policy doesn't allow that to happen.

What we proposed was changing the bullet, just simply to remove the word "transfer". So the transfer policy still applies to allocations and assignments cannot be transferred to within 12 months, but if you've transferred a block in, you can also transfer a block out within that 12 months. 

The comments on PPML have gone many different directions. So I don't have examples of that yet. I will have them at the next meeting. Basically I just wanted to kind of circle back to the root of why we came to this point, was when you go internally to the transfer market, you have to justify a lot of things. You have to justify a very large dollar spend to your corporation. 

You have to justify to ARIN that you are going to grow and you're going to need these addresses, for the 24 months. It's not an easy task. It's not taken lightly.

But it also doesn't allow any flexibility. So if further down the road your company comes to you and says we want to launch an entity in China and you've just spent -- you've just done your justification, you've spent all your dollars, you don't have any more dollars in the bank or there aren't IP addresses to take and open that new entity, you are stuck, and you cannot -- you have to circumvent ARIN policy at this point to do it. And that's not the best way. 

So what we are proposing was that just to make this more of a formal policy. And it's gone on some tangents with global policy, and maybe that's the way to go, but I wanted to get feedback from this community before and just see where we go with it. 

Paul Andersen:  All right. Comments, questions, discussion on this proposal. 

Kevin Loch:  Kevin Loch with Carpathia. Unless I'm missing something here, why is it necessary, if you're moving your business to China, to transfer to -- I'm assuming -- to APNIC?

Tina Morris:  We keep using China as the example, because it's the harshest example. When you route in China, your space has to be assigned to APNIC. You can't keep it in the ARIN registry and still use it in China and route it in their databases. They simply just don't allow that. 

So with this policy, as it stands right now, you can't move that space for 12 months. And that limitation can be hard for some companies.

Kevin Loch:  In that case, assuming there's a good technical reason like that, obviously the role of the RIRs is to keep a database updated as correctly as possible. So I don't see a problem transferring it to another RIR that will keep it up to date.

Tina Morris:  Thank you. 

Paul Andersen:  Go ahead, sir.

Matt Petach:  Matt Petach, Yahoo!. I'm guessing you're really thinking v4 number resources in this case since you should be able to get v6 resources in China with no problems. 

One of the things as a community we've talked about over the past -- oh, I think it's coming up on almost a decade now -- is that as we thought about v4 runout: did we want a gradual landing, or did we really want people to move towards v6. 

And I think I'm going to channel my inner-Marty Hannigan here on the rearranging deck chairs on the sinking Titanic, in shuffling blocks around the world, I would say why don't people just start pushing more v6 and moving in that direction, rather than taking ever smaller chunks of v4 space and dicing them up around the planet. So I am not in favor.

Paul Andersen:  Not in favor. Far microphone.

Joe Provo:  Joe Provo, Google. In general, needs a little work. There's some concern that there's room for abuse. So some protection against flipping would be desirable. 

I can channel one of my colleagues, Mr. Schiller, who would propose a list of compatible registries that have equal anti-flipping language within their policies, so those would be the registries with which we could implement this policy.

Paul Andersen:  Do you think this is a good problem to be solved, just maybe this isn't quite the solution yet?

Joe Provo:  Correct.

Phil Rosenthal:  Phil Rosenthal, from ISPrime. I appreciate, yes, v6 is the future and things should move that way. Unfortunately, I just don't see that's going to happen in any short timeframe and we're going to have to deal with v4 as it is. 

If people have addresses that they're not efficiently using in one region and they can efficiently use them in another region, I think it's certainly better to encourage them to do that rather than to use up more addresses in another region and create even more of a shortage. So I am in favor. 

Paul Andersen:  Thank you. Anyone else want to come and give a short or long comment of their view on this, either the proposal, or even just whether, as I said earlier, the problem itself is something solved that maybe you have concerns over the language?

Bajwa Khurram:  Bajwa Khurram, from Wipro Data Center Services. So IPv6 -- IPv4 is out, all right. But there are organizations that are sitting on huge IPv4 space, reassigning or assigning if ARIN is doing anything to rein those IPs back or no, that pretty much stays?

Paul Andersen:  That's a little bit again out of this policy. This is just dealing with transfers. But maybe at the end of the policy block we can address that a little bit.

Other comments or questions that people want to make on this policy? Okay. We'll close the microphones. Kevin, just checking to see. Nothing. All right. Thank you very much. Thank you very much for the input on this policy. 

(Applause.)

Kevin Blumberg:  There's a comment.

Paul Andersen:  There is a little bit of delay in the webcast. Please feel free to read it in. 

Kevin Blumberg:  Kevin Otte. We're not seeing IPv6 happening in a short timeframe -- that is a self-fulfilling prophesy. The more crutches we keep using to keep v4 alive, defers IPv6 deployment. We can't postpone it forever.

Paul Andersen:  Thank you for that comment. 

2015-3 Remove The 30-Day Utilization Requirement In End-User IPv4 Policy

Paul Andersen:  Moving to our third proposal. Making great time here. 2015-3 -- Sorry I did not queue it up -- there. Today John Springer will be presenting it. It's to remove the 30-day utilization requirement in end-user IPv4 policy. 

John Springer:  Hi, everyone. Thank you for coming. So I'm presenting today, for David and Leif who couldn't be here, a proposal to remove the 30-day utilization requirement in end-user IPv4 policy. 

So the end-user policy is intended to provide end-users with a one-year supply of addresses. Qualification as subject to a number of terms, one of which is that the operator needs to use at least 25-percent of the addresses within the first 30 days. The author submits that this is an unrealistic expectation and proposes that we remove it. 

Textual, essentially there are -- that's the contents of section 4.3.3 right now. If you go to that in your manual, you'll notice it doesn't say 25-percent immediate utilization rate. And that figure is supplied in 4.2.1.6 on page 22 of the NRPM. But the reference is what is proposed to be removed in this case. And by removing that one clause, you end up with a remaining 50-percent utilization rate within one year. 

Justification:  It often takes longer than 30 days to stage equipment and start actually using addresses. I would say that's more common than not, actually. Growth not being regimented, the forecast is to use X addresses over the course of the year, not 25 percent within 30 days. 

And this policy text applies to additional address space requests incompatible with the requirements of other additional address space request justification which indicates that 80 percent of utilization of the existing space is sufficient. 

And the reason we're here is to solicit operator input on the matter. So let's have some. 

Paul Andersen:  I once again welcome you to come to the microphone. Don't all race at once. Identify yourself.

Matt Petach:  Matt Petach, Yahoo!. I'm lucky sometimes to get legal review and signatures for contracts in 30 days. I wholeheartedly agree let's get rid of 30 days. Thank you.

Paul Andersen:  Thank you. 

Mike Joseph:  Mike Joseph, Google. While I support the idea behind this policy, I do oppose it as written. I think simply striking the 25 percent requirement doesn't address some of the issues, particularly as they were brought up on PPML regarding making sure that we're not looking purely at a speculative request from an end site that may have no relationship prior with ARIN. 

I think some interesting ideas were mentioned on PPML. I think some of those may have merit. But the policy as written simply removing this requirement is not sound, in my mind. So I oppose the proposal. 

Paul Andersen:  Thank you. 

Kevin Blumberg:  Can I just ask you a question related to that?

Mike Joseph:  Sure.

Kevin Blumberg:  If you didn't want it removed, but the issue is that 30 days is difficult to sort of deal with, especially in a transfer environment, what would an operator community feel today would be a reasonable number? 180 days? 365 days?

Mike Joseph:  I don't pretend to speak for an operator community. But I would say first, in the case of a transfer there's no difference. I don't think anyone is suggesting that the 30-day clock starts from the day you file the request. We understand it starts from the day you receive the space. I think the mechanism by which you acquire the space is somewhat orthogonal to when you use it. I think the size of the space and the nature of your network would be more controlling factors there. 

But to answer your question, I don't have a particular number in mind. I think people suggested 90 days. People suggested other counts. I think we need to be careful, because again this is all speculative. It's all forward-looking. And we need to -- we could remove this and add other language. We could change this term. 

I'm not suggesting a particular remedy. I think simply removing this term and leaving the door open to anyone who comes in, and walks up and says I want a /22 and I'm going to use 50 percent of it in a year, and you should take my word for it, I think that's insufficient.

Paul Andersen:  Thank you.

Mike Joseph:  I think there are many possible remedies.

Paul Andersen:  Thanks, Mike. Any other comments, remote participants? I see someone coming to the mic.

Michael Roberts:  Michael Roberts, Switch.co. Not speaking for my company, et cetera, et cetera. I don't have a particular view on how it's actually written, but I think having a 25 percent immediate utilization rate and 50 percent utilization rate within a year is sort of nonsensical.

Paul Andersen:  Nonsensical?

Michael Roberts:  Seems silly to require use a quarter of your assignment within one month as long as you use a subsequent quarter within 11 months. Just doesn't make sense.

Paul Andersen:  Thank you. Did you have any suggestions on how that could be improved?

Michael Roberts:  No. 

Paul Andersen:  We're all good. Other comments before I close the microphones? We'll close the microphones now. Check for that remote participant and I'll speak slowly because there can be a bit of delay on the webcast. 

Thank you very much for that input. Just as a small note, by the way, if you do have an idea or improvement or suggestion on any of these policies, if you would either come up after we've closed, or you didn't want to come to the microphone, many of the AC members will be in the room at least for a few minutes. Please feel free, come up, grab one and catch their ear.

Draft Policy ARIN-2015-4: Modify 8.2 section to better reflect how ARIN handles reorganizations

Paul Andersen: We'll go into our final proposal of the day 2015- -- that's not right -- 4, sorry. And I will invite Kevin Blumberg to discuss how ARIN better handles re-orgs. Kevin.

Kevin Blumberg:  This is on. Good. Hello. Okay. So we had a proposal which came to the AC last month, Prop-218. And the minutes -- the nice thing is if you love reading, all of the minutes of the ARIN Advisory Council meetings are published. Usually I think five to ten days after the meetings, you get to see all of the discussion that goes on between all of the AC members to sort of understand why the AC is saying one thing or another or doing one thing or another and moving things forward or moving things backwards, et cetera.

So this was Prop-218. And one of the things that was discussed was initially is this really a policy change or is this something called an editorial change? An editorial change is where we are saying or we're asking the community to confirm that what we're changing is really just a typo or we missed something here or the numbering of something is wrong. 

We're just going to fix it. We ask the community. We do a consult, ARIN does a consultation process just to confirm that. If everything's good it's sort of short sidesteps and fast tracks through the whole process and goes to the Board to get ratified. 

It's a much simpler policy. And what happened was, in 8.2, let's just go over to it, ARIN staff indicated that the procedures should handle, clearly describe reorganizations. 

So the word "reorganization" isn't in the title of the section. So it's in the text of it but it's not in the title. And so there was some ambiguity in that regard. If all we had done is added that in, then maybe you could say it was editorial, because really it's a title, something you need to do. 

So this policy did a couple things, because why fix one thing when you can fix two. And what it did was it added the word "reorganizations" to the title. It moved the bullets around a little bit and it added the text for mergers and acquisition transfers the recipient entity to new bullet, No. 5, to clarify operational practice what ARIN has been doing for the years, requiring the evidence of transfer of documentation for reorganization. 

So I'm just going to bring it up here what we're talking about. Oops. Sorry. We add the word "reorganizations" and we just add in the explanation for mergers and acquisition transfers. 

Now, years ago there weren't that many reorgs that necessarily would have happened. Meaning your companies would have reorged and ARIN wouldn't have necessarily been involved. It got forgotten about. But now people are realizing they have to clean up their data. They did a reorganization 10 years ago and suddenly they realize they have all of this extra space. They want to move that space, transfer it in the 8.3 market. But it wasn't ever reorged into their proper location. So now they're going into ARIN to do reorganizations. 

So where it wasn't necessarily -- there wasn't necessarily a need for this cleanup years ago. Nobody ever thought of it. We're getting into a situation where people are wanting to clean up their data in WHOIS which is a really good thing, cleaning up data. 

So let's move on to the discussion part of it. Do you support updating and just clarifying these couple of points, and if not what changes could be made to this policy that would make you like doing this?

So first question is do you support this, I guess, is the main thing. 

Paul Andersen:  Please, sir, you were there faster than I was.

Donny Roisman:  Donny Roisman, SoftLayer. So I understand, what's the difference between a reorganization versus a merger and acquisition in the eyes of ARIN and this policy?

Paul Andersen:  Leslie. Let's give her a second to approach the working microphone.

Leslie Nobile:  So merger and acquisition is when there's been a sale or a merger of corporations. Reorganization, what we've seen typically is an organization that decides to move all of their network operations to their headquarters somewhere and they've got a bunch of subsidiaries and they want to consolidate and move everything to one place. 

So they're reorganizing. And we'll allow them to do that. But it doesn't fit under an M&A because there's no legal documentation, per se, it's just what they tell us they're doing. That's typically what we're seeing when they're consolidating into one location. 

Donny Roisman:  In the case of a reorganization, does the entity have multiple ORGs within ARIN and they're just trying to move them around across existing ORGs, what are they trying to do?

Leslie Nobile:  They're trying to -- yeah, so they'll have three or four subsidiary companies and they all have space from ARIN. But they want it all to be in one, in their headquarters, because that's where net ops is going to be. So they want to move the space from those four subsidiaries all into their parent company. Something like that.

Donny Roisman:  I definitely support changing -- adding that to the title makes a lot of sense. But I haven't considered the rest of the bullet change to comment on that part.

Paul Andersen:  Thank you. Far microphone.

Kevin Loch:  Kevin Loch with Carpathia. Carpathia has acquired a number of companies over the years and we're in the process of now being acquired by another company. 

So I've had some experience doing these, the merger and acquisition part of this. And I know there's some that we didn't do the merger and acquisition on because they weren't necessary. The entity still exists so there's not a requirement necessarily to do it. 

Believe me, we'll avoid that if we can -- because it's obviously an onerous process in the merger and acquisition. So anything that would make it easier to keep the ARIN database updated. With a consolidate org ID sounds like this would be mostly involved with is a good thing. And I strongly support that.

Paul Andersen:  Thank you, sir. 

Phil Rosenthal:  ISPrime. I would echo the same comment. If we want data to be accurate, reducing the friction to having accurate data seems a good idea. 

And there are quite a number of organizations that if you look at the history of mergers and acquisitions over the last five or 10 years, if you look up who owns their AS numbers, their IP space, plenty of it is still in the name of the old organizations. And I think we all understand why it's like that. So anything to reduce friction is a good thing.

Paul Andersen:  Thank you. 

Mike Joseph:  Mike Joseph, Google. I support this policy. I think, to be honest, this seems like something of a no op because seems like this is more or less ARIN's behavior today. It seems to clean up the language. I know the policy came from a former ARIN RSD, so I can only assume he thinks it's necessary for some reason. 

It seems completely sensible to me. So I support the policy as written.

Paul Andersen:  Thank you. Last call for comments. Remote participation, I believe.

Dan Alexander:  Remote participant, Gary Buhrmaster, no affiliation, speaking for myself. I think that this is an example of how the NRPM overspecifies ARIN operational practice. While I understand the huge effort to simplify the policy manual is a work in progress, it is long overdue and I would prefer to see operational practices removed where possible.

Paul Andersen:  Thank you for that. Last call over closed microphones. Sir, go ahead. So we're going to close the microphones after this one. So if you want to approach, approach now or -- microphones are closed with you, sir.

Bill Goldstein:  Bill Goldstein. My affiliation is myself, speaking for myself. Let me ask a question. When these addresses are provided, is there anything specific in the agreements with ARIN stating that organization, particularly commercial organizations, acquiring these cannot capitalize them or put them in the books as a depreciable asset?

Paul Andersen:  I would be happy to try and get you an answer. That's sounding very specific legal, and I would not feel comfortable, but I can get you an answer very shortly on that. 

There is an agreement that every organization that approaches ARIN today to get the Registration Services Agreement. I don't want to put you on the spot. 

Leslie Nobile:  I'm almost positive that the Registration Services Agreement says that IP addresses are not to be considered property. I can look that up and let you know. But fairly sure it's in the agreement.

Paul Andersen:  That's a very specific question, and I'm not a lawyer nor do I try to --

Bill Goldstein:  I was trying to get away from general questions. And again not really addressing the specific issue. 

I see it -- not talking about my prior association or employer AT&T, I've never seen AT&T do this, but I have seen so much dubious trading of IP address space where I read about it or have heard about it from customers and the question comes to mind is it legitimate to do this, are you really, you know, are you ascribing property rights to something that is not your property.

Paul Andersen:  Perhaps what I can say is ARIN does maintain a significant legal reserve and ARIN has actively defended the rights of the community to establish and enforce registry policy, and to date ARIN has never been ordered or subject to a judgment to do anything other than follow the policies for all resources in the registry. So that's been our position up until now. And it's a significant, you can see it on our budget for anybody to see. 

Bill Goldstein:  That's excellent. I agree with it. Perhaps at an appropriate time it would be worthwhile to review those agreements that it never has to be addressed or touched.

Paul Andersen:  Thank you for that input. 

Mike Joseph:  Comment to that. Follow-up specifically to Leslie's response. While the RSA does specify I believe the ARIN's concern about its, how it considers addresses, I do not believe that the RSA prescribes or proscribes any particular accounting treatment of addresses to entities. Is that consistent with ARIN's expectations?

Paul Andersen:  I'm going to be happy to get you an answer to that. Because you're asking a specific question.

Mike Joseph:  Considering that Leslie answered a question, the question that wasn't posed, I want to make sure that no one from staff believes that the RSA or entities which sign the RSA are agreeing to any particular accounting treatment.

Paul Andersen:  Let's put a pin on that. We'll go to the next item and I'll try, if possible, to get a response back, because I would hate to rush since that's what's on everyone's mind. 

I believe we've closed the mics, but I'll give one last moment for anyone to interject on this one. Seeing none, thank you, Kevin, for input. 

The only other comment I wanted to make that came out of a question during reclamation and unused address space -- the community has put in place the transfer policy; it seems to be working. And a lot of times people speak a little bit about, there's all that address space. But just as a reminder, at least at an RIR level, in 2009, there was 11.5 /8s allocated between all the RIRs, over 15 in 2010, and over 12 in 2011. So the rate at which globally we've been going through address space is quite significant. 

So large reclamation is probably not going to assist you -- IPv6, IPv6, IPv6 people. 

So with that, I think we will end our policy discussions. Thank you very much all for your input. 

Future Of ARIN Public Policy Consultations (PPCS)

Paul Andersen:  What we'd like to move into is this last item that I alluded to earlier which is the future of ARIN Public Policy Consultations, which is what we're in right now. So we started this a few years ago as ARIN, both the Board and the Advisory Council and the staff, kind of looked at the future of policy, what does policy look like post-runout, what's the appropriate number of meetings to have, as we said earlier we have two ARIN meetings a year:  The Public Policy Meeting, one in April, which is stand-alone and one in October, which is back-to-back with NANOG. 

And we introduced this concept of Public Policy Consultations in a hope to get better feedback than we had previously been getting from the operator community. But we thought that this would be a great opportunity to just have discussion. The Advisory Council has always found these very useful sessions, but I thought -- we thought that it would be great to have a discussion here on them. And I'm going to turn it over to Dan for a second maybe to give his view as AC chair on what the AC finds as useful and what's some interesting questions they'd like to know on how we might structure these in the future.

Dan Alexander:  I guess it's in a way a two-way street where, as much as we find your input valuable from the different perspectives, implications of the changes, it's also very helpful if we know what you would find helpful as far as how a lot of this information is presented. Because with different audiences, you know, talking to government people versus network operators, versus number administrators, everybody looks at these topics a little differently and everyone interprets them a little differently. 

So we're very interested in not only the information that you can provide us, but how can we change the format of this session or these presentations to either make them more relevant or provide better data to this audience.

Paul Andersen:  Microphones open remotely and in the room. And we need your input on how we get input. 

Mike Joseph:  Mike Joseph, Google. I oppose the existence of the PPCs. Let me clarify. 

[Laughter]. 

So now that I've just warmed myself up to the room, let me clarify this. There are five policymaking meetings a year now. Five. 

Absurdly, two of them happen in the same week. That's too many. That's too many for entities who are actively involved in policymaking for people who are involved in policymaking. And I'll point out that in this PPC, we don't have anywhere near the representation from the ARIN AC or the Board. We don't even have John Curran present.

Paul Andersen:  He apologizes again.

Mike Joseph:  That's perfectly legitimate, but the point is that we need to decide as a community that we either have -- we have two a year, we have three a year, whatever the number is, not five. But whatever the number is, those are the policymaking forums. And embedding a halfway PPM inside an ARIN agenda that is abysmally attended isn't the way to do it in my opinion. 

It means that if you're active in policy you end up traveling to every NANOG and every ARIN, and it means that if you -- we can see policies come through PPCs and make it to recommended draft without ever having been presented at a PPM. 

Now, I know that's not our practice, normally. But it's not precluded. So I think that having operator outreach is reasonable. I think that having somebody stand up and present to NANOG what current policy efforts are happening in ARIN. I think having ARIN AC members listen to feedback is reasonable. But I think treating this thing as a policymaking meeting, one which can advance an approved policy, is problematic. 

Paul Andersen:  Dan, did you want to ask any follow-up?

Dan Alexander:  No. It's very clear what he said. 

Paul Andersen:  Thank you. So now the ball is rolling. Others that want to come -- please, sir. 

Matt Petach:  Matt Petach. This time I'm going to speak for myself. Following up to Mike Joseph's comments, electrifying as they were, I am a little curious from the ARIN perspective, is there a requirement that the April meeting be standalone?

Would one thing that could be considered be to do two joint meetings a year with NANOG and just say, okay, seems to work well in October. You have considerably higher participation when you smoosh things together there, could we maybe do like two meetings jointly and we only travel like twice and cut down that five meetings to like two major meetings and do it that way?

Paul Andersen:  So that's a great question. So, yes, the October has always been back-to-back. The April has been generally standalone to give a little bit of flexibility and ARIN has tried several times to sometimes line up with other meetings or organizations such as CaribNOG or the Canadian ISP organizations because our region being Canada, United States and large amount of the Caribbean, and other properties in our region, we just want to make sure that we have the ability to traditionally have the ability to visit those regions, if NANOG was not able to get that.

But there's no requirement, and that's a great suggestion that we could look at in the future. That's just been the traditional. Leslie, did you have something? We have to jump here because we have -- let's get cozy here.

Leslie Nobile:  I just want to point out somebody just said we don't have John Curran present. Just want you to know John Curran is alive and well and watching everything we say. 

Paul Andersen:  Not only that, he's --

Mike Joseph:  Hi, John.

John Curran:  Not only that, he has a message for you all later. But we'll get to that later. Any other comments on this format or --

Dan Alexander:  I was going to reply -- add to that. One of the things that we have to consider as well is part of the Policy Development Process is for us to bring something through a recommended state and actually recommend it to the Board. 

We do have to present it at a public meeting. So if we went to a format where there was a considerable gap between those meetings, say like a joint January NANOG and the fall because there is no NANOG meeting in April, there would be a considerable gap where if we had a problem arise that we really needed to move through the process a little quicker, we would either have to leverage our emergency procedures, which gets the Board involved. 

So I'm not saying that it's a bad idea or it's impossible, it's just things that we have to take into consideration. 

Paul Andersen:  Thank you. Let's go rear microphone.

Tony Tauber:  Tony Tauber, speaking as NANOG Program Committee Chair. I've discussed this with Dan, and Kevin I know we had a chat a couple of -- several weeks ago anyway. You know, kind of about this going forward and sort of how, somehow this discussion happened. 

But to lay it out how the Program Committee does its thing, we put out a submission, put out a call and take submissions and we go through and assess their relevance to our audience. 

And there was a -- basically we're revisiting everything, which is part of why this discussion is going on. So I want people to know, I think the critique of having two things in the same week, two PPCs in the same week --

Paul Andersen:  PPC and a PPM.

Tony Tauber:  Similar discussions, same content, similar format -- you know -- I don't think that's going to happen again, because people were frustrated by it. But in general revisiting everything. 

So it's not -- lest people think of it as a carve-out or a permanent fixture of the way things are. To have PPC embedded in NANOG is going to follow our program development methodology, just so people here know because a lot of interested parties, they should realize that. And just when Dan was talking about something has to be presented in public, I mean it just occurred to me, well, obviously you've got a remote participation framework, or that's understood to be a way to do it. 

So can there be a constitution of a public meeting that isn't physical? Just a thought.

Paul Andersen:  Great comment. Just as my own thought -- thank you very much. The Program Committee has been very supportive of what has been an experiment and now starting to, has been quite a fixture for a bit. So we appreciate that quite a bit. 

Dan Alexander:  Just to respond to that, and I'll see if I can appropriately capture John Curran here. 

We're always looking at possible revisions to the Policy Development Process. And we've had conversations in the past a number of times about can procedures move forward without actually coming to a PPM meeting. 

So all of these are definitely viable possibilities or conversations to be had, and the Policy Development Process is always looked at, I believe, by the Board. And I think John keeps a running tally of points as they come up. 

Paul Andersen:  I detailed it later, for instance, the historical reason why it's been the joint. Just because it's been done that way, it doesn't mean it has to be done in the future. That's why we're having the discussion. We'll continue to have it at our PPMs. Such as that, we're looking to the community feels is the most effective way to do this. 

Kevin Blumberg:  One thing to add to this, and this is, I guess, part of the community over the years that we've noticed as Advisory Council is that things get done in person. 

We have a couple of interesting ways of describing it. But until you get up to a mic, nothing gets said. We don't have -- we have an active Mailing List but nowhere active like you're used to with the NANOG Mailing List where you have hundreds of messages suddenly flurrying in because someone said one wrong word. So the nice thing about the PPCs it allows us to move discussion forward because people are actually in a room discussing. 

If we leave it to a virtual space, unfortunately I find that doesn't happen. I think there's lots of use for virtual spaces. But I think the benefit for me as an AC member of having these meetings is that, you know, we don't have to now wait until October to make the changes that a number of people have brought up in this room that will benefit these policies. 

It's not necessarily let's dump the policy, it's not necessarily let's move forward, it's let's work on it and this meeting allows us to do that.

Paul Andersen:  Front microphone, unless you had further comments. 

Joe Provo:  Joe Provo working for Google, speaking for myself. Whatever we do let's not repeat Baltimore because that PPM felt like a marathon session.

Paul Andersen:  Thank you. We're going to close the microphones now. So if you wish to add on this item, please I'd approach a microphone with high speed. Any remote participants, by the way? None. 

Remote participant, then go to the remote microphone.

Kevin Blumberg:  Kevin Otte.  Virtual spaces can be made to work but the tools will need to be improved. Real-time is necessary, video possibly.  Some people just can't make the travel happen.

Paul Andersen:  Thank you, sir.

Matt Pounsett:  Matt Pounsett, speaking for myself. I think in terms of keeping the operator community informed about what the policy community is thinking about and working on and for getting information to the AC if the AC finds it useful, I think for those two things, the January and June PPC is great. I think the October PPC is a little bit silly.

However, I agree with Mike. I don't think using these meetings as a place to actually move things forward in the process is a good idea. This is a poor replacement of a full PPM. It's very -- does certain things very well, but as a substitute for PPM I don't think it's good. And so --

Paul Andersen:  Thank you. And our last two comments.

John Springer:  John Springer, Inland Telephone, ARIN Advisory Council. Not speaking for Inland Telephone or ARIN AC but speaking as a single member of the ARIN AC. 

These PPCs are very useful for me because I get to speak to a category of people that do not show up to the PPM. But not only that, on the occasions I get to speak in the presence of these people so they hear me speak, and I occasionally hear them speak. 

The idea that -- I mean travel is travel. And it's hard to some extent on all of us. But the idea that it would be desirable for the AC to not receive input from those people who only attend NANOGs is not one that I would be comfortable with. 

Also with regard to the October PPC, that would be the one that I would be the most likely to consider throwing off the back of the sled.

Paul Andersen:  Okay. Thank you. Supposed to be the last comment, but Mike looks like he's sneaking in. It's all right, Mike. It's okay. We've got a bit of extra time.

Matt Petach:  Matt Petach, speaking for myself and not completely understanding the subtle distinction between PPC and PPM. I'm going to ask a dumb question. 

Paul Andersen:  No dumb question but I might give you a dumb answer.

Matt Petach:  Excellent. Rather than wedging this between NANOG, would you be open to consider rather than the three-day massive meeting in October doing like one-day follow on at the end of each of the three NANOGs to do kind of shorter PPMs that are actually like meetings.

Paul Andersen:  So you're suggesting don't do this kind of bit within the program but have the same --

Same hotel, same place.

See if NANOG would be cooperative because it is obviously their meeting to doing three --

Matt Petach: Those passionate about policy, we could stay the extra day. We've already flown. One more hotel night. 

We get the more immersive full-day microphone experience, which you know we just all live for. This way you actually don't have to worry about feeling like it's getting cut down to even fewer opportunities. This way you have three - three whole opportunities during the year to get that community feedback in an in depth sort of just, oh, we really dig in mode.

Paul Andersen:  I have to say, sir, the way that's spoken is the reason we have in-person meetings because how could you capture that in email. That's a wonderful suggestion. 

Anyone would like to approach the mic, we'll do one last call. Mike, go ahead, please approach while Mike is speaking.

Mike Joseph:  Mike Joseph, Google. I'd like to respond to John Springer's comment. I'll point out that we don't send the AC to PPCs, if we really want to get operator feedback to the AC, we should send them. We should fund AC and Board travel and we should make it with all the bells and whistles we do, if that's what we want to do. 

It's that we get some people here. We have substitute presenters, because the shepherds aren't here. We have a room that's a quarter of the size if we're lucky of the PPM. And particularly people on stage that are a quarter of the number of people that we would normally have. 

So if we're going to do something, let's do it right. 

Paul Andersen:  I would address there's some support -- we don't support the entire AC and Board. But we do support --

Mike Joseph:  If we think it's important, we should.

Paul Andersen:  Well taken. Some of the AC and Board do come here on support. But I get your point. You would like all if it's --

Mike Joseph:  If it's going to be real, let's make it real.

Paul Andersen:  Dan, I don't know if you wanted to have any closing comments.

Dan Alexander:  Just that this has all been very helpful because in all the conversations I've probably ever been in with this topic, nobody has ever -- I've never heard anybody say this is a done deal or we've got this right. 

So I think each time we've had these, it's been a work in progress. Whether that work in progress results in us doing away with these, or whether it results in us refining them in other fashion remains to be seen. But all of the information that's been provided here has been very helpful. So thank you very much. 

Paul Andersen:  Thank you, not on just this session, but input on all sessions. 

Closing Announcements and Adjournment

Paul Andersen: To go back quickly, before we wrap up, John called me on the weekend to say he had something come up, he couldn't travel. I said no problem, I'm sure nothing will come up that will require you. 

But he was able to remotely participate. So I would just like to respond to the earlier question and John Curran has asked me to say: 

The RSA and LRSA do not specify accounting treatment for number resources. The RSA and LRSA do require the address holder to agree that the number resources are not property, that they will not assert property rights against the resources, and that they will comply with the registries policies. 

My apologies for delaying that. I'll leave it at that, if that's all right. Thank you. As I am pretty sure that was the difference, given the fact that it seemed to be fairly specific. I thought it was good to get to that for John quickly since he's at a terminal to verify. 

So just as a reminder, as you probably guessed we'll have a PPM in October back-to-back with NANOG. So in Montreal, as you know. So please do try and attend. 

If you'd like to become involved and you're not already, please consider joining the ARIN and PPML Mailing List, and I believe, unfortunately, I think the Fellowship Program has closed for -- we do offer a fellowship to attend ARIN PPMs, when it is back-to-back with a NANOG, we do pick up the NANOG costs. So if you're interested in doing that, please visit our website. But with that, one last comment from Kevin. 

Kevin Blumberg:  Just the comment you touched on earlier that a number of us will remain behind. So if there are people that want to discuss certain aspects of this proposal or any other topic, for that matter, just let us know.

Paul Andersen:  Okay. With that, thank you very much all for your involvement in this PPC and thank you and have a great day. 

[Adjourned 4:38 PM PST]