Table of Contents
- Public Policy Meeting, Day 1 - Opening Announcements
- Policy Implementation and Experience Report
- Advisory Council On-Docket Proposals Report
- IETF Report
- Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
- Recommended Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers
- Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy
- Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months
- NRO Number Council Report
- ARIN Board, Advisory Council, and NRO NC Election Procedures | Candidate Speeches
- Recommended Draft Policy ARIN-2016-4: Transfers for new entrants
- Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
- Open Microphone
- Public Policy Meeting, Day 1 - Closing Announcements and Adjournment
Public Policy Meeting, Day 1 - Opening Announcements
John Curran: Good morning. If everyone would come in and be seated, we'll get started in a moment.
Good morning and welcome. I'm John Curran, President and CEO of ARIN. I'd like to welcome you all to the ARIN 38 meeting taking place in Dallas, Texas.
We are going to have an exciting day today where we talk about a number of things, including just a handful of policy proposals. And I'd like to say we have everyone here from the organization, our Board of Trustees is here.
I note that Paul Andersen is our Chair. The Chair of ARIN switched at midpoint of this year as Vint will be stepping down at the end of his term at the end of the year. So I'd like to introduce Paul Andersen, Chair; Vint, who will be here later this morning; myself; Timothy Denton. Tim, are you out there somewhere? Aaron Hughes, Bill Sandiford and Bill Woodcock, who I thought I saw.
So the Board of Trustees is here. We have our Advisory Council. Would members of the Advisory Council please rise. There's more of you, come on. 15 of them.
Okay. And that's led by Dan Alexander who is the Chair. We have the NRO Number Council. Louie Lee is here. I've seen him. He's usually under Louie's hat.
Okay. Jason Schiller is not here. He's under the weather. But he's on the mend. We'll see him some other time. And Kevin Blumberg is here.
Kevin is our latest NRO Number Council member, because we ended up — sort of one of our Number Council members, Ron da Silva, ascended to the ICANN Board, left an opening which Kevin Blumberg was willing to serve. And it was actually John, then we hired John and then Kevin took it.
We have our colleagues from the other RIRs. If you're from one of the RIRs and staff, stand up.
Come on, stand up. We know you're here. From AfriNIC, RIPE, LACNIC and APNIC. We have a number of members to help us coordinate our policy. It's becoming more important with things like transfers. So happy to have them here.
ARIN management team is here. I'm one of them. The person who does all the work, Nate Davis, Nate is over here. Cathy Handley handles our government affairs. Richard Jimmerson is our CIO. We don't have Richard this time. Michael Abejuela, our associate general counsel. And Erin Alligood, who handles HR and admin. Susan Hamlin, the one who makes this meeting happen, her and her team. Mark Kosters, engineering. Leslie Nobile, who handles projects for me, the senior director of global registry knowledge. John Sweeting, who I just mentioned earlier — John is now running the RSD department. John, where are you? Stand up. Applause for John.
We tapped someone from the industry and brought him in to help with the RSD desk. Hopefully he has a little affinity for what you're going through because he's been through it on the other side. And Val Winkelman, who is incredibly important because makes sure we have money. Thank you, Val.
So I'd like to talk about our ARIN Fellows. We have an extensive Fellowship Program. If the Fellows will please stand up. Come on, Fellows, stand up, we know you're here. ARIN Fellows here for the first time. They've been brought in in order to help learn about this organization and communicate its mission and tasks to other people.
All of the Fellows have mentors. Mentors, stand up, join your Fellows. The mentors of all the Fellows are the ones that help them understand the meeting and introduce them to our secret handshakes and all those other good things.
I'd like to thank all the Fellows and all the Mentors.
We have a number of people who are attending this time who were Fellows in the past meetings who decided it was worth coming. It helps us continue to keep ARIN alive and dynamic.
Okay. Fellowship Program. We have a Fellowship Program, and the Fellowship recipients include, from Canada, Josh Crawford. Josh, where are you? Okay. Kathleen Monk from Canada. Kathleen. Orin Roberts from Canada. And Shaun Rossi.
These folks have received benefit to be able to come to offset their expenses. All of them, of course, as I said have mentors. The ones from the USA — Jason Bothe, Bradley Fidler, Julie Percival and Dustin Phillips. And from the — from the US, Alfredo. Alfredo, are you here? From the Caribbean, Gary Campbell. And Ashell Forde.
All of the fellows are important to us. This organization takes a toll on people. And while people do put a lot of time and effort into it, after a while, people are, yeah, I see you got that; I'm going to do something else. We need to have a continual set of people coming in to make sure we always have people who are with the industry who know what is needed in ARIN policy. So very happy to have our Fellowship here.
Newcomers, we have 60 newcomers at this meeting, 60 people.
Yesterday they had an orientation where they met some of the elected representatives and ARIN staff. They learned about ARIN.
And we have a prize drawing. And this is big bowl of all the surveys. And I will ask someone at random. Owen, I'll ask Owen to come up. Owen, are you hiding here somewhere?
I guess he escaped. I'll ask someone else. If I can have Mr. Huberman.
Cathy already up here. You made the bowl bigger. There's all the surveys. You've got to, like, flip through them.
Okay. Lovely. The winner of the newcomer orientation survey is Julie Percival. Hey, Julie. Imagine that.
Purely coincidence. You'll get a ThinkGeek gift certificate.
We have a second prize for this one. This is wonderful. Someone yesterday at the newcomer orientation left an AmazonBasics charger, a little power brick, at the orientation. Now I'd like to give it back to its actual owner. But if we don't know who that is, I'm happy to auction it off next.
So, if you want it at the break, and it's yours, come on up and — Leif, it's yours. It's even still fully charged, how is that? Lovely.
I'd like to welcome the remote participants. This is very important. Not everyone can make it to a meeting. A lot of people have other things to do, conflicts, or have a real daytime job and they're trying to intersperse this with other things.
We provide full remote participation, including the webcast, a live transcript, all the meeting materials are downloadable, and you can participate in the chat room.
I'd like to give a round of applause to our remote participants.
They are here with us in spirit.
Okay. So, I'd now like to note, in case of an emergency, just reminding people, emergency exit, closest exit you can find. In that case, it's — let's see. In this case — yes, back there. Over there and over there on the side are our emergency exits.
Paul Andersen: Please note the closest exit might be behind you.
John Curran: Right. In this case they're over there. Wireless SSIDs, if you've been here a while you already know this, but we have the NANOG ARIN network and NANOG ARIN Legacy network. One is secured with 802.1x and one is open. If you use the secure one, the password is NANOG NANOG.
Attendance. We have 128 attendees from the United States, 11 from Canada, four from the Caribbean, 29 from outside the ARIN region and 26 remote participants.
Okay. I'd like to thank our sponsors. Network sponsor, connectivity, very important stuff, AT&T, and webcast sponsor Google.
Okay. You have a ticket for a T‑shirt. Come get your ticket and turn it in at the afternoon break and you can turn it in, get your T‑shirt. Many people value their ARIN T‑shirts and have collections of them. You know, come forth and get your T‑shirt.
When we do discussions, we're respectful of each other. We're going to have the chair moderate the discussions of draft policies, making sure everyone has a chance to speak and be heard. State your name and affiliation as you approach the microphone each time. Please comply with the rules and courtesies in the program.
You all have a Discussion Guide. It looks like this. It has a copy of rules and courtesies, okay. Please be respectful of one another. We're trying to actually have a dialogue here, so it's important to let everyone speak and try to understand the other person's point because eventually, by sharing information, we get to a better outcome.
Okay. Today's agenda, we're going to start out with a few reports. We have the Policy and Implementation and Experience Report where staff tell you what's going on and how some past policies have done well or issues that may — could be improved.
We'll have the AC Chair, Dan, give the AC On‑Docket Proposals Report. We'll have the IAB/IETF Activities Report. Always good to keep track of the protocols because these registries get affected. We'll have a discussion of ARIN election procedures. And in the afternoon we'll have the NRO Board and AC candidate speeches, and we'll have an open mic at the end of the day.
We also do have a policy track today. On the policy track, we've got some policies. We have 2015‑2, 2015‑7, 2016‑1, 2016‑2. We have a number of policies we're going to talk about. So it's going to be a very busy day. The goal is to get good understanding of each one, try to improve it, make sure it's the best policy draft it can be.
Oh, yeah, we also have 2016‑4 and 2016‑5. So six policies on today's agenda. Very busy day.
Okay. We have a social tonight at the Perot Museum of Nature and Science. Buses leave here at 6:45, 7:00 and 7:15. Gather ten minutes in advance so we can get you on the bus. Shuttles come back at 8:30 and run all they way till 11:00. Wear your badge or social badge if you have a social badge.
At the head table we have myself. We have our Chair, Paul Andersen. I have Daniel Alexander, who is Chair of the AC. I have — this always happens — Tina. I have Tina who is Vice Chair of the AC. It's amazing how you know someone. I have Scott, who is going to be our Jabber scribe. Look at it. I got through.
There's something about that mental connection when you look at a face.
Okay. So let's get started. The first thing on the report is John Sweeting, who will come up and do the Policy Implementation and Experience Report.
Policy Implementation and Experience Report
John Sweeting: All right. Good morning, everyone. As you probably know by now, I'm John Sweeting, the new Director of Registration Services at ARIN. I'm used to being up here giving some AC reports and other things, but I am now ARIN staff.
So I will be giving the Policy Experience Report on policies that I probably had a little bit to do with when they became policy.
So we'll jump right into this. So the purpose of the Policy Experience Report is to review existing policies, to look through and find out if there's language in there that could be made more clear for our customers to be able to go through the processes and understand the policies.
It's really amazing to me being on that other side now of how much ambiguity and differences there are in the way words are written and how people interpret them.
And it really helps to get the feedback from the community so we can look at that. And sometimes it's very obvious once it's pointed out. But when we don't really — aren't looking for it — it's really hard to find. So lots of input is good.
We also look at it to identify new areas, the analysts put things together. They talk and they say, hey, there's been a lot of this going on lately, maybe we need to have a policy that addresses it, that helps us do the job better and more efficient, more effective.
And, of course, we want to provide that feedback back to you guys here at the meetings. Today I'm going to talk about two policies that were reviewed. NRPM 5 is the AS Number Policy, and NRPM 4.2 is — NRPM of course is the Number Resource Policy Manual, which I should know.
And paragraph 5, and also within the NRPM, paragraph 126.96.36.199, which is reassignments to multi‑homed downstream customers.
Getting right into the AS Number Policy. When I first got there, the analyst, the staff and RSD came to me and said: We're spending a lot of time to give out or approve AS numbers.
It's complicated. The customers come in. They want to do BGP. They're starting up a network. They want to start out configured with BGP.
Sometimes they don't have the revenue to start out with two providers. So we ask them for just to have the contracts, but it's just — it seems to be a very convoluted process to get an AS number.
So the current policy text is in order to be assigned an AS number, each requesting organization must provide ARIN with verification that is either a unique routing policy or it's a multi‑homed site. I think we covered the unique routing policy in Jamaica and got some further clarity on that and understanding.
But the multi‑homed site portion is what I'm going to concentrate on today. So AS numbers are issued based on current need as well.
And it states in the NRPM that you can only get an AS number — well, it says you can only request an AS number when it's already multi‑homed or will immediately become multi‑homed. Immediately is kind of a problem. Usually, from what I understand, being there for the last two months, immediately is almost always interpreted as within 30 days.
So there you go. The current practice is to confirm connectivity with two upstream providers, making sure we either want to see connectivity contracts, invoices or address reassignments with the two providers.
As you can see, there's problems with that. Sometimes when the address — two providers won't both give addresses, because they say, well, you're getting it from the other provider, so we're not going to give you any, especially today when addresses are getting scarce. And then to confirm the deployment within 30 days. The immediately portion of it.
So what we're asking is are these correct given that ASNs are no longer scarce, not considered like a limited resource.
So that's one of the things I'd like you to think about: Is this really the way you want us to be reviewing requests for AS numbers?
Some of the customer feedback that we've received is that 30 days is just too short of a timeframe. They want to have everything needed to deploy their multi‑homed site three months before turning it up. Some of the other comments, requirements to have connectivity with two upstream providers immediately is burdensome.
They don't want to spend the money on that second connection until they have a firm customer base that is providing the revenue that's going to pay for that second connection to a different provider. But they still want to start out configuring their network with BGP.
Therefore, they need the AS number. So a couple of options, some of the options — leave the existing policy procedures as it is; or we could do a procedure change, interpret immediate to be longer, 90 days, 180 days; allow verification by identifying two upstream providers and confirming multi‑homing will be turned up with them.
Again, it's the how long do they get to wait before they turn it up. Possibly we do officer attestation for how long they're going to use this many IP addresses within 24 months. Do we get that and say, hey, we're going to be multi‑homed within six months, 12 months, 24 months, whatever makes sense there?
That would be more into the policy change itself, which that's the next item there. Insert specific time verification requirements.
And that's it on — that's all I have for the AS number. But we really want to — once I finish with the next one, I really would like to hear your feedback on what you think we should be doing or what's the best way to tackle that.
I can tell you, it is a very time‑consuming process for getting an AS number today, and there's a lot of AS numbers that come in.
So now on to the reassignments to the multi‑homed downstream customers. The policy text reads "This policy allows a downstream customer's multi‑homing requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements."
What that allows is when we allocate to an ISP, they can then assign or allocate a /24 to one of their customers based strictly on the fact they're multi‑homed.
There's no host requirement there. The problem is that ARIN itself, we can't do that. We can't do what we allow the ISPs to do.
There's nothing in the NRPM that says ARIN can issue a /24 regardless of host count just based on the customer being multi‑homed.
So the problem is networks may be unable to obtain a /24 to multi‑home post depletion. Going back to scarcity of resources, some upstreams don't want to give addresses anymore. They tell them, oh, we're not giving them to you; we just don't have them.
Yeah, it might be that they don't want — they want to give them, but they just don't have them.
So there's no policy to allow that network to obtain a /24 on the transfer market since 188.8.131.52 applies only to ISPs and not to ARIN.
Really they're not going to come back and get a /24 from the free pool because there are none. They could go on the waiting list with it if we change that. But basically what we're looking at is a way they could — they're multi‑homed, their upstream wants to take back their IPs, but they could go and get a /24 on the transfer market under our rules.
So the frustrations we've heard is "I don't understand why an ISP can assign me a /24 but ARIN can't." "I can't use anything smaller than a /24 — you guys don't seem to understand that." And "How am I supposed to multi‑home if I cannot obtain a /24?"
So again to the options on this one. Some of the options we thought of — there's probably more, so if you have a better one, please share it. We can leave it as is.
We can change — NRPM Section 4 could be changed to allow multi‑homing to be a good justification for a /24. And, again, it would apply to the waiting list and transfer requests.
And/or we could change NRPM Section 8 transfers to allow multi‑homing as justification, and that would only apply to transfer requests.
So the difference there is if it's in Section 4, it would apply to both the waiting list and transfer request. If it was in Section 8, it would apply only to transfer requests and not to the waiting list.
And that's it.
John Curran: Okay. Lovely. So we've got a presentation — first thing is does anyone have any questions for John regarding his presentation, any clarifications, additional information, confusion over what he presented? Yes, Kevin.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. Very quickly, it might be very beneficial to include — like you did in the first one, to put in what a unique routing policy is, because I think many people today will actually just use, oh, I'm a unique routing policy and not even touch the multi‑homing.
So while I agree that cleanup is probably needed, I don't think most people outside of this room will know what a unique routing policy is in regards to how ARIN defines it.
So I don't know if that's anywhere. It's sort of amorphous. That's the first thing.
The second thing is, in regards to this /24 requirements, absolutely agree it needs to be simplified and brought in line.
But the other problem with that is that we also have the reserved pools. And it's important to take into account how this will apply to reserved pools as well, because we've had policy previously that would have done that partially for 4.10 and it failed with the community previously.
John Curran: So want people to come up. Any clarifications or questions on John's presentation? We need to be careful not to go into advocacy of a particular policy change, because we could be here all day, and this isn't a policy block.
So go ahead. Questions to John about his presentation.
John Sweeting: Kevin, the unique routing policy was covered in depth in Jamaica. It was on the Policy Experience Report there. I'm not really — I'm not prepared to like go any deeper into it right this second.
Kevin Blumberg: It's not on the website for the average person to see; that's the point I'm trying to make.
John Sweeting: Okay, thank you. We'll take care of that.
John Springer: John Springer, ARIN AC. I'm going to be presenting a Recommended Draft Policy this afternoon that will hopefully take care of your second bullet point here. That's Policy Proposal 2016‑4.
You can find it in your guides.
John Curran: Excellent. Back microphone.
Chris Woodfield: Chris Woodfield, Twitter. Regarding the AS allocation, given now that we're in a 32‑bit address space, it seems to me that an allocation of an AS number is — sorry, the AS number pool is no scarcer than, say, the IPv6 address pool.
Have there been any proposals to tie the allocation of an AS number to the allocation of an IPv4/v6 prefix?
John Curran: I haven't seen a proposal to that effect in this region. Is there a region out there where the v6 and AS allocations are given the same time? I know it was discussed in one region.
No, I guess not.
So right now I don't know of anything where you get them both at once.
Chris Woodfield: Not necessarily get them both at once, but maybe the fact that you have an allocation can be used as justification for obtaining an AS number.
John Curran: Certainly a possibility.
Owen DeLong: Owen DeLong, ARIN AC, Akamai. In regards to the unique routing policy, it was covered pretty well in Jamaica. It should be on the website.
It is a bit amorphous, and in my experience that's a pretty good thing. Because there are actually a lot of things you can do that qualify as a unique routing policy, and I've had many a customer in my consulting business in the past that has taken full advantage of that fact in order to be able to get ASNs for creative and interesting purposes that are perfectly legitimate and would otherwise be very difficult to deal with.
And I've had a few customers, for example, where that's not permitted in APNIC. They strictly require multi‑homing or did up until a recent policy change. And it's been problematic.
And so I'm strongly in favor of keeping that provision and explaining a little better, but not locking it down too tightly would probably be a good thing.
John Curran: Okay. Back microphone.
Robert Seastrom: Robert Seastrom, ARIN AC, Charter Communications. I've got ASNs back in the dawn of time. And the bar for demonstrating need was extraordinarily low, because there was no scarcity.
In the absence of a scarcity regime, I am in favor of making the bar similarly low. I think that you needed to be able to spell EGP at the time in order to qualify for an ASN. I'm not in favor of just handing them out with prefixes despite the fact that 32 bits for ASNs looks pretty good. Thank you.
John Curran: Thank you. Any other questions for John? Thank you, John.
John Curran: Okay. So, members of the ARIN Advisory Council, raise your hand again. If you have thoughts about what we were just presented — get your hands back up, come on — the people with their hands up, look around, see the closest one.
They want to talk to you about your thoughts on these changes. Okay. If you have an idea about what should be changed, find one of these people. Thank you. Okay. I now want to move into the Advisory Council On‑Docket Proposals Report with Dan Alexander, the AC chair.
Advisory Council On‑Docket Proposals Report
Dan Alexander: All right. Good morning, everyone. As John mentioned, the AC has a lot of work on its docket. So I'm going to try to run through a number of the things that we're going to discuss today and tomorrow and hopefully try and make some sense of it and prepare everybody for the individual conversations.
We actually — the AC has one proposal on its docket. It's a new proposal that came in just before our last meeting. And that one actually will not be discussed on the agenda today, because it's still in a proposal state and it hasn't been actually moved to a draft.
During the Newcomer meeting yesterday, we were talking about some of these different proposal states. And at ARIN, in this policy development process, it typically goes from a proposal to draft to a recommended and then moved on to the Board in a very generic sense. So that proposal's still in its initial stage, so we're not going to be talking about it here.
We have one draft proposal. That will be discussed Friday morning. It's 2016‑3. That one is related to several others, and I'll get into those details in a bit. But we're going to discuss that one Friday morning.
That being in a draft state actually can't move to the Board after this meeting. One of the requirements of the policy process is a proposal has to be discussed here at a meeting in a recommended state before the Advisory Council can advance it to the Board.
And since that's a draft, we won't be able to do that after this meeting. But it's also, I wanted to point out, as this one relates to the others that are in a recommended state, that's more of a procedural issue, and it was in no way because the AC felt that we should be doing one or the other.
That preference is really for this discussion here in the room. And it's important to get all of your feedback to decide which ideas are better.
Because in the end, the goal of all of this is to get a consensus of the room and on the Mailing List of which are the best proposals to advance.
So there's seven recommended drafts that we're going to work through. Four of them, as John mentioned, we have four being discussed this morning.
There's two this afternoon and one on Friday morning. All of these are in a recommended state and, based on the feedback here, could be advanced to the Board after this meeting.
Now, we have four of these recommended — sorry, not all recommended. Four of these proposals are directly related. And in order to advance any one of them, we have to make sure the requirements are met where they're fair and impartial, technically sound and supported by the community.
But while each one of them can stand alone as a particular change, all four of these can't move together as a set, because they're all approaching a solution to a problem from a slightly different angle.
So these discussions that we're going to have will help the AC understand which approach is preferred.
To try and make sense of some of this, because with the number of proposals that are trying to solve, essentially a similar problem from different approaches, we put together an additional insert in the Discussion Guide that everyone should have, to try and chart out some of the differences and similarities between each of these proposals.
If you back up a second — and the veterans here, bear with me awhile because I want to help the newcomers kind of make sense of this as well — when you look at ARIN's policies on how the resources are located, if you back up a step, it's essentially, when we're talking about a needs basis, you're looking at how is an organization using their existing resources that helps explain how they would need resources in the future. There's different levers that we pull. So based on previous growth, you could justify X future growth for Y timeframe.
These are the different conditions that we apply to a lot of these policies. So this slide here is kind of talking about the existing policies, how we manage some of those conditions.
What these four proposals try to do is slightly adjust those approaches in different ways. When you look at the policy manual, Section 4 is really focused on IPv4 requirements.
Section 6 of the policy manual is IPv6 requirements. And Section 8 of the policy manual is really focused on the requirements of transferring registrations from one organization to another.
The approach of 15‑7, one of the things that it does is current policy takes transfers, the transfer requirements of Section 8 and looks at the usage requirements in Section 4. 15‑7 essentially adds some additional conditions into Section 8 as a means for people to justify the resources required in a transfer.
2016‑3 also does something similar in that it adds an additional condition to Section 8 for v4 transfers. But it does it in a little different way or in a new approach where essentially you can get up to a /16 as long as you're using what you currently have.
So you could essentially double your existing allocation up to a /16, if you're already using your existing space.
2016‑4 takes a slightly different approach, where it's modifying Section 4 requirements, but just applying a minimum, which is actually, as the several Johns — there's too many Johns in this room — John Springer and John Sweeting were just discussing, that helps the case of applying minimum allocations to organizations so they can acquire space via transfer, if they couldn't get it from their upstream ISP.
Then finally 16‑5 takes a completely different approach to this situation in that it tries to detach the needs requirements in Section 4 and put them in Section 8 as they apply to transfers.
One of the things about these different approaches is that there's — there's been a conversation, now that the free pool is gone, how do we manage requirements for transfers in a depleted state?
2016‑5 in that separation of requirements actually sets up for a potential solution down the road in the event, if ARIN ever got a free pool again, if people started returning space because they're migrating to v6, it leaves the free pool requirements in Section 4 essentially intact, where some of the other ones alter Section 4 in a way that if the free pool ever returned, we would then have to consider how we would want to manage that going forward.
So the next couple of slides simply kind of break out how these different proposals take those approaches. Here we're looking at how much space can be acquired.
These are the differences that are also laid out in this chart as far as looking backwards based on how much is required, what is the requirements on the existing space that people have in order to justify that.
Then there's the forward‑looking requirements, where the current policy, you know, transfers can do up to a 24‑month supply as long as that request is utilized up to 50 percent within one year.
And then 15‑7, 16‑3, 16‑4, 16‑5 all tweak that slightly in that they change the time frames into which that space has to be utilized.
And then, finally, each one, for the most part, a number of them just leave the evidence required intact, but some of them, in particular 15‑7, changes the justification slightly, in that 15‑7 essentially says as long as an officer attests to the requirement, that's good enough for staff. They don't have to dig into the details or provide like utilization proof.
So we're going to be talking about these this afternoon and tomorrow. Sorry, all day today. It's going to be a long day.
But there's also a number of different ways, not just here at the microphone, but you'll also have the opportunity to grab AC members and discuss these in different places, one of which is during lunch we like to have several tables designated for different topics. So we set aside four tables, two of which are set to discuss these four policies. And you can get with the shepherds and voice your opinions, your experiences, ask questions.
There's also two other tables, aside from all these policies. One of the things that the Advisory Council is always curious about is how can we expand participation, bring more people into the community. The number of first‑timers here is actually really encouraging. It's always good to see. We'd like to continue that trend.
Another topic that we're interested in is how are these RIR transfers working? What are people's experiences?
For those who were actually at NANOG there were two really good presentations yesterday from Amy and David regarding some of the experiences of the transfer market.
And finally we also — if you would like to break out and have a conversation about any of the policies, feel free to grab any one of the AC members, because we'd always be happy to sit down and discuss any of these proposals in more detail.
John Curran: Any questions for Dan?
Dani Roisman: Dani Roisman, SoftLayer. Not a question, just a comment, a compliment. I wanted to thank whoever worked on the quick‑reference guide, fly‑in that you guys put into the booklet. Thank you, it's a very helpful chart.
Dan Alexander: That would be Amy.
John Curran: Thank you, Dan.
John Curran: So one of the things that affects what we do here is all of these policies apply to the number registries. The number registries don't just exist. They come from somewhere.
When the IETF defines a protocol, they often define a registry. And sometimes they do things after the fact that affect the registry, registrations, other changes.
We actually have someone who goes to IETF and tracks some of the more interesting developments since not all of you can do that. I'd like to invite Cathy Aronson up to give the IAB IETF report, and this is a way to keep up to date with what's going on over there.
Cathy Aronson: So now that I'm known as the photographer on the Advisory Council, I'm glad that I put a photograph, because my whole career went away and now I'm just a photographer.
But this is the Aurora from a class I taught two weeks ago in my neighborhood. So neener‑neener‑neener.
Anyway, I was at somewhere, sometime, and somebody referred to something as the magic of watching grass grow. And as you know, my theme has always been watching paint dry, watching grass grow. Welcome to the IETF. Super awesome.
John said I could still make up whatever title I wanted. So I did.
How do I — awesome. So this is the standard disclaimer, which I believe we'll be changing soon, because of some changes.
Anyway, but for right now I'm not officially anything. I just go there as a tourist, and I laugh at people and live stream on Facebook what I think. And I'm going to tell you some of the things I think.
I think there's always something that just makes me laugh hysterically at the IETF, and this is one of my all‑time favorites.
So the IETF has this elaborate process for standardizing things, and they usually follow it. But it turns out, with Homenet, they used a top‑level domain — a special purpose, top‑level domain called .home — and all the documents that made it all the way to RFC 7788, and guess what, they didn't follow the process to make .home an actual special purpose domain name. So they have a standard that references a special purpose domain name that isn't actually standardized.
So there's a process I'll talk about later in my slides, they're trying to decide, well, should we say not to implement .home? Should we change it to something else? What should we do, because it's not actually officially a special purpose, top‑level domain.
Something else of note. There's a lot of work to like modernize a transport. So there's QUIC and PLUS, and they're both, like, the beginnings of maybe optimizing the transport over UDP instead of TCP. So those are some things to follow.
I heard the same talk three times. I have a bunch of slides on that. That was super exciting.
IPv6 RFCs are not official Internet standards. So we've been deploying it for a really long time now. And it's not actually an official IETF standard, which I think is interesting.
And we'll talk some more about that. And Ross Callon is definitely and literally a graybeard of the IETF, and he's retiring. And he gave an awesome talk that I'll talk about in a little bit about the cost of having too many standards all for the same thing.
And there's these really cool little computers called hacker boards that I'll talk about in a little while. I think I have to get one because they're like puppies, super cute.
A lot of people tell me that they loved my talk, especially the footwear part. So here it is again. I don't know, people seem to like it. Aaron Hughes is to blame for this because of the guy who had neon green Crocs. Anyway. Onward.
IEPG, I talk about it all the time because the bulk of what's interesting that happens at the IETF happens on Sunday from 10:00 to 2:00. It's an operator's group that's been meeting at the IETF for 25 years, maybe. I don't know. A long time. And nobody at the IETF seems to know that we exist, but we meet and the talks are really interesting.
So there were some talks about little changes to the IANA registry to help the IETF, just little bits and pieces.
There was an IPv6 Deployment Survey that's of interest that if you're interested you should look up. There were 900 responses, and 300 of them said it's a commercial service on their network, which is promising. Different charts of prefix sizes and that sort of thing.
And then there was a talk about IPv6 performance, and Geoff Huston also gave a talk at NANOG about IPv6 performance. And it seems like maybe things have changed since the IEPG talk, because he said it was — what did he say? Total crap, something like that.
So if you want to take a look, stats.labs.APNIC.net, which is, of course, Geoff had this presentation and the NANOG presentation.
Let's see. Randy Bush talked about invalid ROAs, which is an interesting talk if you're following that sort of thing.
Yeti DNS, there was also a talk about this at NANOG. It's really cool. They built a whole parallel root to the DNS so that they could test things because you have this big distributed system and maybe you want to try some new feature. But if you're just trying it in a little test lab, maybe that won't really mimic the real world. So they've actually built a whole parallel root system where they're testing various things they want to test to the root, which is really pretty cool.
And these are some more things that are going on. I have 30 minutes and 62 slides. So I tend to skim some of these things, because it's a lot of slides. But these are some other things that were talked about.
The RIPE Atlas traceroute, there's data you can go use for your own research, and it's available to everybody. So that's pretty neat. They have those RIPE Atlas probes all over — there's even one in Wyoming where the Aurora was. And you can see what's going on on the network.
So this is the presentation I saw three times. And I have a couple of slides about it, because she's trying to solve the age‑old problem of multi‑homing with provider aggregatable address space.
And I'm not sure that it's really a problem that's easily solvable. But in v6 there's this source address‑dependent routing option that's supposed to be implemented. And so she's trying to grapple with how you could use that to perhaps solve the age‑old problem of multi‑homing with provider aggregatable address space. This is more notes from the second time I heard the talk.
And this is some details about it. It's basically multiple scoped forwarding tables using that technology in v6, so if you're interested in that. And there's many different ways that have been tried to solve this. SHIM 6 was probably the last most memorable one. So we'll see what happens. It could happen.
Okay. So 6man. This is what I try to put at the beginning of each of these. What is this working group, anyway? So the charters are a lot longer, but I take a little digestible part of it and stick it in so that you can kind of see what they might be talking about in this group.
Let's see. So this is the work that I was talking about in the highlights, while maybe we should make v6 actual Internet standards. So they're going through the draft standards and taking all the bits that we learned from all this time deploying v6 that's not an Internet standard and then they're going to take that, update the documents, gen them again and then make them official Internet standards.
So there's special purpose address — v6 special purpose address registry work going on. There's — global is used in a lot of different contexts and they're trying to define global. And the special purpose registry. So there's some drafts going on with that.
This is that presentation I saw three times. I have a lot of slides about it. It was like, really? I'm going to watch it again? I don't know. Anyway...
V6 operations is slightly different than 6man. This is less protocol work and more operations sorts of things with deploying v4 and v6 in parallel.
This is some work being done that actually affects us or maybe long term affects this community. They're talking about a prefix per host as opposed to an address per host and why that might benefit your network, provide more isolation between devices on the network.
And that would, of course, use more address space than we're already using in v6, because if you're using a prefix per host instead of an address per host, it's a lot more address space. So that's something to keep an eye on, that I'll be keeping an eye on.
This is a v4 v6 translation prefix being proposed. This is actually pretty controversial, because it's not unique and a lot of people in the meeting were like, yeah, I'm just going to use my address space, I have a ton of it.
And then other people are like, well, maybe I'll use this. So we'll see what happens with this. But it's being proposed. So when you're doing translation between v4 and v6, you would use this or maybe you'd use your own address space. I think it's ISP by ISP who would do what. But it's being standardized.
So the Routing Area Open Meeting. I try to go to a meeting every session, and when there's nothing to do with v6, I pop into these other more generalized to try to get a little view of what's going on. And Ross Callon, for those that don't know him, he's been going to the IETF — I think he's gone to more IETFs than anyone. I'm not sure if that's a good thing or bad thing.
But he's a super neat guy. He's retiring, and he gave this really thought‑provoking presentation about what happens when you have too many standards for the same thing.
And those of you who have seen my talk before, you've seen me go on and on about — especially the encapsulation protocols, this wrapped in that wrapped in this divided by that sent by — there's just a ton of them.
And they all really do the same thing. So what happens when you have eight protocols defined that do the same thing? That means that maybe you don't really have a standard protocol, because this guy implemented version A, this guy implemented version B, and they don't talk to each other but they're both standard protocols.
So he gave a really thoughtful presentation about that, just saying, hey, people, maybe we don't need IP in IP and IP in UDP and IP in GRE and IP in IP — and, like, if I was making this up it wouldn't be nearly as funny.
These actually exist. Like there's that many protocols for encapsulation.
So, anyway, it's really thought provoking, and I think the IETF really needs to do some soul searching about that very topic.
CodeMatch is really cool. They're matching, they're starting to get more and more people coding to IETF standards and tracking whether there's implementations, because the whole premise of IETF is rough consensus and running code. And over the years we've had less and less and less running code and more and more and more Internet standards.
So this is really, really good work. And if you're involved in any sort of educational institution, there's a hack‑a‑thon before the IETF. There's all these groups putting students together with standards that need to be implemented.
So it would be good to pay attention to if you have students that need things to work on. I think I can probably skip that. These are some other things that are going on.
So the Routing Area Open Meeting is basically all the routing gorp that isn't assigned to a working group yet. These are some of the high‑level routing things that are going on in the IETF.
So I started going to the Human Rights Consideration working group because I thought, what in the world, Internet protocols and human rights? I get, like, data on the Internet and human rights, but Internet protocols and human rights?
So it's really interesting stuff. I've been really surprised. So this woman, I'm in the process of getting her book. I haven't had a lot of time since the IETF to do that. But these folks are really looking at how what we do in the IETF, how does that affect people around the world and their rights. And are we doing anything that would prohibit them from having freedom of expression, freedom of association, and it's interesting work. I've really enjoyed going.
And this guy is from the UN. He also gave a really good presentation. And the IETF wrote an RFC — there was a presentation on lessons learned from the privacy consideration and Internet protocols RFC, which was also a really good presentation.
If you're interested in that sort of thing, it's definitely worth checking out. Because in the beginning I just didn't even really think — I didn't think that — I thought they were apples and oranges, but actually there's a lot that protocol specs can do to make sure that people's rights aren't infringed upon.
So 6lo is basically v6 over all those little things that go to sleep and wake up. Maybe they're asleep for a long time, and they have a little battery and they have not a lot of space for code, you know, like your thermostat or your refrigerator, some MSTP, like machinery in a factory or whatever.
So this is all those kind of devices and how do we run such a big protocol over them and make sure that they still can survive.
So there's a bunch of different things going on with, like, Bluetooth networks and MSTP, like I said, machinery and like factories and stuff.
There's a border, 6Lo Border Router work is being done because there's this whole thing where your duplicate address, you detect a duplicate address and you turn yourself to death, so they're trying to solve some of those problems for these little devices.
There's also been a couple of Plugfests where they take all these little devices and they hook them together and they see if they work. And it's pretty interesting work.
Let's see. I thought that I had — I guess it's a different one where I had the guy with the little mini PCs. I guess that was Homenet.
So DHC is everything automatic addressing, like DHCP. And every kind of dynamic address assignment goes into this group. And there's a lot of work to secure DHCP right now, because, you know, a lot of this stuff got implemented and it wasn't particularly secure.
It's like we're trying to secure the DNS. We're trying to secure everything kind of in hindsight, because in the beginning it was an experiment that got out of the barn or whatever. There's a lot of work securing the dynamic host assignments.
These are some other drafts that I'm not going to tell you about, but there and there. And OPSEC is operational security. And this is sort of a little bit of the charter of what they do.
Let's see. This guy, he came up with this model, this STRIDE model, spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. He took all the IPv6 transition technologies and sort of rated them against this scale.
You could argue that maybe not all of the security gorp is in there, but it's an interesting exercise of taking all the stuff that we're starting to use and looking at it against a security model to see what we need to fix and what we don't need to fix and that sort of thing. So it was a pretty interesting exercise.
And there was a lot of arguments about you forgot this one or forgot that one. But you have to start somewhere.
And there's been a lot of work about filtering extension headers in IPv6. I think I talk about it pretty much every IEPG, because there's a fellow who always talks about it.
And there is a little bit of work being done to talk to providers about maybe what you should filter with extension headers and what you shouldn't filter, so that people who are trying to use extension headers for something they need, maybe they could still have their packets go through. So someday maybe that will get settled. It's ongoing — ongoing.
This is just me being goofy. But addressing, readdressing apparently is hard still, even though it's not supposed to be from the document. I just pasted that in there.
It's me being goofy. But apparently it's still hard even though we have a new protocol and it wasn't supposed to be hard. It's still hard.
SDN. So they finally have a charter, because, I don't know, for those who have seen my talk before, they were — what did they say — unconstrained by charter was the SDN motto until now.
So I took some bits from the new charter. So basically SDN is separating the network infrastructure from the management plane so that maybe you use some big, all‑knowing management system to push out everything to the network devices instead of configuring them all individually.
There's a lot of other SDN‑like things, but it's basically separating the management plane from the — I can't think of the right word for it, but from the network infrastructure.
China Mobile is doing quite a bit with SDN. And this was a talk by China Mobile about what they're doing to manage their network with SDN.
Let's see, and then this is some more gorp of people using different kinds of SDNs. So it's starting to happen, I guess. Let's see. This is a way of using SDN to synchronize all your clocks on your network and coordinate various things that are going on on your network.
Some more SDN‑like stuff. Like I said, I have a lot of slides.
So in the Internet Area, let's see, well, this is what it is. This is another one of those overarching groups that I go to when there's no v6 and I could probably go have a coffee, but I always go to a session, because I'm kind of like that.
So the IAB stack evolution program, those two things, PLUS and QUIC, that I talked about in my highlight slide, those all fit under the stack evolution program. And I think all of us need to be following that because it could really affect a lot of what we do on the network over time. Could speed things up, which would be really great.
So this GUE, it was super timely that he — poor guy — so it's another encapsulation protocol and, of course, Ross Callon had already spoke at the plenary and at routing area about having too many protocol standards for the same thing. So, of course, somebody got up and said, "Did you see Ross's talk? You got another encapsulation protocol. What's up with that?"
Well, the guy said, "Well, this will be the last one."
And of course we all laughed hysterically, and he sat down. But apparently we're going to have yet one more encapsulation protocol.
So this is basically GRE, and we've had GRE for, what, since like 1990 — I don't know, 1989. I don't know, a long time. This is basically GRE with, like, maybe a couple of little bits flipped.
I know, it's so different. And apparently it will be the last one. I'm so excited. Some other topics that are going on in the Internet Area and maybe eventually it will move to individual working groups are these.
And one of them, I think, me as a network operator, it would have been really nice to have this extended ping, where if you don't number your interfaces, you can still ping them. That would be kind of cool to have. So we'll see what happens with that.
Okay. Homenet. My favorite. All‑time favorite. A bunch of geeks designing a network for people who aren't geeks is really entertaining, because we're geeks and it has to be arbitrarily complex and ridiculously huge and it provides a lot of fun for me. I just love it.
So HNCP is like the basic protocol that gives you your brain when you connect to a home network, and it's being — they're starting to talk about what happens when they try to use it.
The architecture is on its way to being done. I think I actually sent comments on that draft to the author, which was fun.
Users should not be skilled or knowledgeable. And I think everybody at the IETF should remember that when they're designing a Homenet, but they forget because they're geeks.
Let's see. And then RFC 7788, what do we do about .home. That went on for a long time because .home is out there and not standardized. So we'll see what happens. People are writing code to use .home in the Homenet, so I imagine we'll continue to use .home in the Homenet, but there's some debate and should we write a draft to say don't use it while we figure out what they should use. It still makes me giggle.
Let's see. These are some more drafts that are going on in Homenet. Babel for Homenet, or Babel, whatever you want to call the routing protocol that they invented for Homenet, which I'll rant about in a few minutes.
Some other drafts for Homenet. There's a lot of work being done with naming in the Homenet, and how do you name all the devices in a Homenet securely, and then the people on the Homenet don't, shouldn't need to know how to do DNS, but how does everything figure itself out. So we'll see how that goes.
So Babel, however you want to call it, it's a routing protocol, yet another routing protocol that is apparently for Homenet because we couldn't decide between RIP, OSPF or ISIS, so we picked a new one.
So the guy — it would be funny if — it's funnier because it's true. But basically it's a protocol for determining changes to the protocol.
So onward. The hacker boards were really super cool guys. These little, teeny computers and this guy — he handed them out. It was so much fun.
He made a Homenet of all these teeny, weeny, little computers. They're like — you can fit them in your hand. And there's a whole article that I put a link in to here, to all the different little — it's like a full PC on a little USB dongle thing. It's amazing. Everything's getting smaller except us, I guess.
So SIDR, which is the Secure Inter‑Domain Routing working group, I got to go — sometimes it overlaps with v6 stuff, so I don't get to go. There's quite a bit of work going on within SIDR with RPKI and BGPsec, and stuff. We have people in the room who could speak more to SIDR than I can, but I like to at least put some of the drafts down, so that if you're interested you can go and check them out.
So there's some global statistics information going on of what's happening out there in the wild. And, okay, I've heard little bits about this over the years and I keep thinking, I really need to look that up.
But in ARIN, when you get PI space, you get it from ARIN. If you get provider‑independent space, you go to ARIN, you get a block of space.
So in other regions apparently you get PI space from your upstream, and that's something that I have been pondering now for quite some time that I didn't actually realize.
Maybe I'm the only one who didn't realize that. So I guess the RIRs give blocks to ISPs so that they can assign PI space. I didn't know that. Maybe you didn't know that.
Ruediger has his hand up. Anyway, that was something that — how long have I been doing this and I just learned that. So anyway —
Owen DeLong: To my knowledge, that's unique to RIPE.
Cathy Aronson: Is it unique to RIPE? But still it seems different, right?
Let's see. Oh, we all learned a new word at the IETF, mergence. And it actually fits us perfectly. I put the definition, because it's actually a really useful word that we don't use in our industry.
But this woman, English wasn't her first language, and she found an awesome word that perfectly described what she was talking about. It's pretty cool.
And a couple of people in the room actually looked it up because they didn't know what it meant. And then one of them, the most outspoken — not me — got up and said, wow, that's an awesome word, thanks for using that. So who knew?
So it's basically if you take a routing, a ROA, and you put too much information in it, if one little bit of it is invalid, the whole thing is invalid.
So there's a lot of effort going into making one ROA one block so that you're not invalidating a huge amount of information if one thing is invalid when you're trying to validate your routing advertisements.
So mergence would be like the smooshing of them all together. And I guess pulling them apart would be some other fancy word I don't know.
So, anyway, there's some work being done there. Her talk was super interesting. And there's a link to the slides.
Some more work on RPKI that's happening. Consolidating RAs. That sort of thing. I've been trying really hard to break out the acronyms, and if I'm still not doing a good enough job, let me know. I'll try really hard.
Then I'll have like 75 slides. But I'm happy to do it.
So let's see. The Meeting Venue Working Group, we're really doing some soul searching in the IETF on a lot of levels, where we have meetings, how do they affect the attendees. Are the human rights, you know, laws in that region, do they affect our attendees? That sort of thing.
Which is really interesting. And they've also been doing a lot of work on diversity of leadership roles in the IETF. I think I've talked about that a few times. It's a little bit easier in that community because there isn't an election. So it's not a popular — it's not as election‑oriented. So the leadership has really taken a role of seeking out qualified, diverse candidates and then choosing from them.
The view on the stage in the last six years at an IETF meeting of when the leadership is up there has changed significantly, which is — it's really cool.
And I think that this is a really good exercise. Like, where are we going? And why are we going there? And how does that affect our attendees? I think it's a really good thing.
So there's some more slides about this. I don't know. It's not really technical. But it's still pretty interesting.
So here are some links to all things IETF, different things about BoFs, the daily dose, pretty much anything you'd want to look at with respect to the IETF is here. If you are going to go to your first IETF these are the things you should check out.
There's actually a really good video explaining that not everyone is friendly and you need to try to have a thick skin, basically, is what it says.
But it's still pretty interesting. And if you are going to your first IETF look me up because I'm happy to show you around, introduce you to other people.
This is my favorite cartoon ever. I just love it. It makes me so happy every time I see it.
Anyway, I was going to put names of people, but I didn't.
So does anybody have any questions or comments. If you go to the IETF and you want to embellish on something I said, this is certainly the high‑level view — high, high‑level view.
John Curran: Any questions for Cathy?
Andrew Dul: Andrew Dul. Not really a question but a comment. In the NANOG meeting earlier this week there was a really good presentation about the work being done on extended communities that we have talked about as necessary for 32‑bit ASNs. So just a pointer to that for those who may not have been in the room earlier this week.
Cathy Aronson: And that's extended BGP communities, right?
Andrew Dul: Yes.
Cathy Aronson: Large.
John Curran: Large communities.
Cathy Aronson: Large communities. Awesome. Ruediger?
Ruediger Volk: Large communities is a new attribute type and not loaded with any structure, which was one of the bad things about the extended communities.
Cathy Aronson: Cool.
John Curran: Any other questions for Cathy?
John Curran: Thank you Cathy. Excellent presentation.
Okay. We have a brief break before we come back and start our heavy lifting of the policy work. So, yes, exactly. So if everyone will head out, you have a break out in the hall, and we'll be back here promptly at 10:45.
(Break at 10:19 AM)
Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients)
John Curran: Lovely. We have a very busy morning. We have to keep the railroad running on time. Okay. So, we're going to start off immediately with the policy block. That includes four policies we're going to consider this morning.
I will do the staff introduction to each one. The first one up is Recommended Draft Policy ARIN‑2015‑2: Modify 8.4 (Inter‑RIR Transfers to Specified Recipients).
This policy proposal was proposed in May 2015 as Proposition 216. The shepherds, the two AC members who helped lead it through the process, are Cathy Aronson and Chris Tacit. It's been at two Public Policy meetings and two consultations.
It was revised in February 2016, again in April and again in May. It was recommended for adoption by the ARIN Advisory Council in May of 2016.
So it could be moved to last call after this meeting. The text is in your Discussion Guide and available on the Web. Staff understanding: Currently, organizations are unable to act as a source in an 8.4 inter‑RIR transfer of IPv4 address space if they have received an IPv4 address space in the last 12 months from ARIN's free pool or from the waiting list for unmet requests or via an 8.3 transfer. This Draft Policy lifts the 12‑month restriction in cases where the source of the recipient entity owns or controls each other or both are under common ownership or control.
If the policy is implemented, ARIN staff would no longer apply the 12‑month time restriction to organizations who wish an 8.4 transfer to themselves or in cases where the source or recipient entity owns or controls the other or both are under common ownership or control.
The policy proposal could be implemented as written.
And then the legal assessment, general counsel raised concerns in the previous versions but they've been addressed. We don't have material legal issues with this. In order to determine what entities are under common ownership or control, traditional legal rules would be applied.
Resource, it would be a minimal resource impact to implement this within ARIN. As typical, it would occur within three months after ratification by the Board of Trustees. We'd have to update the guidelines and internal procedures and do some staff training.
That's it. I'm now going to turn around and bring Chris Tacit up to do the AC presentation.
Chris Tacit: Thank you very much. So you've already heard the problem statement. Basically the anti‑flip provisions are an impediment to the ability to export IP addresses that have been either acquired under parts 4 or 8 of the NRPM.
And it was acknowledged that global network providers need to be able to do that, not because of restrictions that ARIN imposes but because of restrictions that other RIRs have for requiring you to import addresses in their regions if you want to use them.
So the problem was the word "transfer" in the policy statement, which triggered the anti‑flip provisions in these circumstances.
So various legal solutions or various solutions involving legal terminology were considered along the way.
I won't get into the whole history. But at the last ARIN meeting, the proposed text that you see on the screen is what was reviewed.
I should add that bullet 4 there should actually say bullet 3 for 8.4 in the recipient portion. That's just an error that was caught this morning and brought to my attention. Thank you for that.
In the end, there wasn't really any big discussion as a result of this proposed text. Although, there was a suggestion to make an editorial change.
You've already heard about the staff and legal, so I won't go through that again. There was pretty much widespread support at ARIN 37 for the suggested text, except for the editorial change that was proposed just to clarify the relationship among the source and recipient.
So the proposal was moved to Recommended Draft as you heard, and this is now the current text of that replacement bullet, which will be 3, not 4.
The red text is the new text. So basically what it does is creates an exception to the anti‑flip provision in case there is an affiliation relationship, a common control relationship among the source and recipient. Because under those circumstances it's believed there isn't really a material risk of fraud by circumventing the anti‑flip provision. There hasn't been any additional feedback from the community since that last editorial change was posted.
So the questions that we have for you now are is the text now sufficiently clear for the proposal to be implemented as policy, and are there any last‑minute concerns or issues?
I was going to mention in your slide deck after this there's a bunch of slides that deal with the history of the proposal but I'm not going to go through them here.
Paul Andersen: This is our first recommended draft policy, so just as a reminder for those that have been around and also those that are new, this is a very important time for you to come to one of the microphones located in the middle and two at the sides. Please come and give any comments you have about the proposal. Please start with your name and affiliation.
And I'd ask if you could state whether you support or do not support the policy as it's written, and then give any comments or statements you may have.
It's very important that we get as many people: Me too, or just I support or I don't support is also really useful feedback.
And with that we'll go to Microphone No. 1, the gentleman on the far — I'm sorry if I can't see you that well. There are lights, very bright, pointed at me, so it's very hard to see in the back.
Kevin Blumberg: My voice will probably help. Kevin Blumberg, The Wire, NRO NC. I support the policy as written and I would actually like to point out, this is part of the external, the global allowance for policy or spaced move from our region and out and vice versa, which has now become trilateral. Before it was just bilateral. It's now trilateral and at some point it might even be more people.
My understanding — and I'd love clarification from the other regions — is that we have the most restrictive policy in this case, that the other regions don't have this anti‑flip in there. So this would actually bring us in line with what is going on in the other regions, which I think is important. I believe it's important for us to all have similar policies and procedures.
So that's why I support this policy as written.
Paul Andersen: So you'd like input from the other regions?
Kevin Blumberg: As long as what I've just said in that other regions do not have this restriction in place, if that is the case, I don't need to hear from them. But if I'm wrong in that assumption, having talked to some people, I would like them to come to the mic if possible.
Paul Andersen: Okay. Thank you. So if someone would love to approach on that, please do. Center microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I'm speaking in opposition of the policy.
While it is unlikely that a related party would transfer space to another region in contravention of the anti‑flip provisions directly, because Kevin is correct, this provides a tremendous avenue for those that wish to do an end run on our anti‑flip provisions that we crafted carefully for very good reasons.
And I, therefore, oppose the policy on that basis. It does not provide adequate protection.
Paul Andersen: Sorry. Before you go. So is there a change that you'd propose that would be amenable, or just —
Owen DeLong: No, I oppose the policy concept.
Paul Andersen: Thank you for the feedback. Center rear microphone.
Andrew de la Haye: Andrew de la Haye, RIPE NCC. Just to come back to the request we just received. We have a 24‑month ruling. That's one.
Secondly, the ruling is based on the prefix and not on the account. So there's a small difference there.
Paul Andersen: Thank you for that input.
Others who would like to comment on the policy, please approach the microphone.
Rear microphone, center.
Ray Bennett: Hi. Ray Bennett, Google. I like the policy. All I had to say.
Paul Andersen: Sorry, you cut off. You support?
Ray Bennett: Yes. Support.
John Curran: So we have 15 ARIN Advisory Council members who work really hard on making good policy, and they're capable of doing it completely on their own, but they really try not to.
And the difference between them doing it on their own and them doing it on behalf of the community is getting the community to come up and speak about what they think of policy proposals, whether they support them or whether they're against them and, if so, why and could it be changed.
It's really important for folks in the room to express their views. So microphones remain open.
Dani Roisman: Dani Roisman with SoftLayer. Do we have a sense of how many people this policy change really applies to? Are we fixing a corner case for one, two, three organizations, or is this really a common prevalent problem that we think we need to solve?
Paul Andersen: John Sweeting or John Curran? Go ahead, John.
John Curran: Recognize that large organizations that are multi‑national within the ARIN region are capable of removing their addresses between business units under 8.2 reorganization and it's routine to do so.
The moment they go outside of the boundary of ARIN's region, presently they trigger the anti‑flip provisions. Is that common? It may only be half a dozen a year that we've had people approach. But that's only people who have approached us. That's not people who have just decided to cope with it and leave with the registration and the wrong organization or the wrong business unit.
So it is a fairly common occurrence for large multi‑national organizations. We only actually hear about them coming to us and getting upset a few times a year.
Paul Andersen: Did that address your question?
Dani Roisman: Sounds like you don't necessarily have firm data. Makes sense why you wouldn't.
Chris Tacit: I would just add to it that it's possible to do this through a different mechanism, which is using 8.2 and 8.4 improperly, and so what this does is regularize something that should exist to meet the needs of global networks instead of trying to dance around the policy. Thank you.
Paul Andersen: Thank you, Chris.
Paul from APNIC.
Paul Wilson: Paul Wilson from APNIC. Did I hear correctly that this policy is justified by the perception that other RIRs insist that IP addresses be transferred to that RIR's registry in order to be used in that RIR's region?
Chris Tacit: Probably more NIRs than RIRs, but the problem remains.
Paul Wilson: If it's NIRs, then maybe that applies to APNIC, but I'm just not aware of those circumstances. If there's an NIR case, I'd be interested to know what that is.
Paul Andersen: Cathy, I see you very rapidly approaching a microphone.
Cathy Aronson: This is Cathy. Probably the person better to speak to this is sitting right next to me, but I believe it was more of a country issue, not an NIR, LIR issue. But certain countries require you to have your address space in the RIR associated with that country before you can route it in the region.
Paul Andersen: Thank you for that, Cathy.
Owen DeLong: If I can clarify that a little bit more.
Paul Andersen: Please, Owen.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. Specifically the most common places where this occurs are China and South Korea, where they, in order to get your space routed within the country, insist on having it within their NIR.
And especially in the case of CNNIC, space goes in but it can't come out.
Paul Andersen: Useful clarifications on the requirement for the proposal.
Chris Woodfield: Chris Woodfield, Twitter. I wonder if you could clarify for me, after reading the anti‑flip provisions in the section, it's still unclear to me what ownership ARIN maintains over that allocation after it is transferred to another RIR. There's no ownership whatsoever, so ARIN no longer has jurisdiction over the use or subsequent transfer of that space; is that correct?
John Curran: You used the word "ownership." I'm going to try to —
Chris Woodfield: Stewardship.
John Curran: Let's start out. An IP address block is an entry in the Internet Numbers Registry System, which is a single registry that five RIRs coordinate.
So and collectively the five RIRs maintain the full registry, but people have rights to various entries. We stopped paying attention to address block entries that are no longer in our management. Once it's been transferred to the stewardship to another RIR, we're no longer watching them.
The problem is that the act presently of receiving address space via transfer, even if it's just a reorganization between affiliated business units, could prevent you from being able to do any subsequent transfer for 12 months.
So it's not that ARIN is in somehow affecting that address block that moved to another region or moved into ARIN, it's that that organization is under a constraint working with ARIN for a period of 12 months.
Paul Andersen: Thank you. Scott, anything on the tubes? Nothing coming from the remote?
So if you would like to comment on this policy proposal, which, again, is in Recommended Draft Policy — Dan, could you just explain how the AC will deal with this based on the vote, what would be the next step for the policy? For those new that might not be familiar with the intricacies of the PDP.
Dan Alexander: Since this is in a recommended state, based on this feedback, based on the input from the Mailing List, based on all the discussions, the AC has to take all of this into consideration and decide whether or not we have enough of a consensus to move this forward and recommend it for adoption.
If we were to recommend this for adoption, we have 60 days after this Public Policy Meeting to do so, in which case we would send it to a last call period where everyone would then have a final say in the change.
Then what happens based on any input there, the AC then decides whether we want to send it to the Board for ratification.
Paul Andersen: This may be the last in‑person opportunity to comment. With that, I'll put a last call on comments from the microphone. If you would like to comment, approach a microphone now. Or if you're remote, start typing feverishly.
David Huberman: David Huberman from Oracle. There are operators who have a real need for this type of a policy. This is real. And I would rather we consider policy in light of actual operational need rather than inchoate fear.
It's important to recognize that the 8.4 anti‑flip language as it is is essentially no op, and while the folks in this room who deal with IP addressing and ARIN and the registries regularly as part of their jobs understand that, others outside may not.
So the provisions as they exist have some utility. But without this, large operators, or operators who operate in multiple countries, continents, have to go through a lot of make‑work with ARIN, and it's all just show.
So as Mr. Tacit very elegantly put it, we're just streamlining what the policy should be.
Paul Andersen: And you are in support, then?
David Huberman: Strongly.
Paul Andersen: Microphones will be closing momentarily. I'll take one more microphone over there. If you're not standing in front of a microphone or typing feverishly by the time Kevin finishes his comments, that's when the microphones will close. So it's last call.
Kevin Blumberg: Kevin Blumberg. So I'd like to actually thank the representative who pointed out a fundamental difference. And I think as you get larger, that plays more into it. ARIN blocks an entire Org — correct me if I'm wrong — for 12 months. The larger you get, the more transactions you do, the more that 12 months gets reset and reset and reset.
In the RIPE region, it's just the address record that gets blocked. And a large Org can then do the things they need to do.
So I think that now that we are — we've just run out 12 months ago, and now that we're in that position, we're starting to see some of the — failings is too strong a word, but we're starting to see some of the assumptions that we made originally in our language for our region when it comes to the transfer market and out of region starting to play in once actual use happens.
Paul Andersen: Thank you, Kevin. The microphones are now closed. Chris, any final comments?
Chris Tacit: No, thank you.
Paul Andersen: Let's thank Chris for his presentation.
It's audience participation time. If I can get my counters to give a sign, just because again it's very bright. We see them. Thank you. I'll be asking a question. Anybody who can hear the sound of my voice, whether in this room or remotely, has the ability to participate in this.
So by raising your hand, the question I will ask will be whether or not you're in favor or against the Advisory Council moving forward with this policy as it has been presented to you today. So first ask for the yeses and nos.
So if the online can start voting.
And all those that are in favor, please raise your hand nice and high, and keep it high. That's it. There we go. Don't be shy. Just keep it. We'll give a moment for those online. Please keep them up. We're not trying to torture you. Thank you. You may lower them.
And I would ask now those that are opposed, the nays, please raise your hand nice and high. Thank you. You may lower them.
Please wait while we await the tabulation of the votes.
Any public service announcements, John, while we're waiting?
John Curran: No.
Paul Andersen: Anything interesting happening in your country this month? Next month?
John Curran: Yes.
I see the envelope making its way down. On Recommended Draft Policy ARIN‑2015‑2: Modify 8.4 (Inter‑RIR Transfers to Specified Recipients), in the room and online, 130 people. In favor, 46. Against, one.
This information is being provided immediately to the AC for their consideration. Thank you very much. And I'll turn it over to John.
Recommended Draft Policy ARIN‑2015‑7: Simplified requirements for demonstrated need for IPv4 transfers
John Curran: Moving right ahead, the next policy up for consideration is Recommended Draft Policy ARIN‑2015‑7: Simplified requirements for demonstrated need for IPv4 transfers.
This was proposed in June of 2015 as ARIN Policy Proposal 221. The AC shepherds are Robert Seastrom and Milton Mueller. It's been presented to two Public Policy meetings and one Public Consultation.
It was revised in June of 2016. The ARIN Advisory Council recommended it for adoption in September, meaning it could be advanced to last call after this meeting.
The text is in the Discussion Guide and online.
Okay. Our staff understanding: The policy allows requesting organization to demonstrate need by having an officer of the requesting organization attest that they will use at least 50 percent of the aggregated IPv4 addresses, including the requested resources and all previously held resources, on an operational network within 24 months.
For 8.3/8.4, staff would no longer conduct a needs assessment for the requested IPv4 block size per NRPM Section 4 and would accept an officer attestation as full justification for the requested block size.
Staff comments: We would apply this to the assessments for 8.3 and 8.4 and transfer pre‑approval requests. It could be implemented as written.
No material legal issue exists if the policy is adopted. Comment from counsel: Permitting receipt of resources based solely on attestation by an officer permits some amount of fraud as it enables those willing to make a fraudulent statement to obtain resources. The present combination of officer attestation and staff verification provides stronger assurance of compliance with the policy intent.
The policy would have a minimal resource impact on ARIN from an implementation aspect.
We'd update the staff guidelines and internal procedures and staff training. And that ends the staff introduction. I'll now have Rob Seastrom come up and give the presentation.
Robert Seastrom: Thank you, John. So this is 2015‑7: Simplified requirements for demonstrated need for IPv4 transfers.
As everyone is no doubt aware, the current policy for transfers inherits the demonstrated needs requirement from Section 4 of the NRPM. That's centered around the notion of there being a free pool.
There is no more free pool. So that was then. This is now. This is one of several proposals that we have in our docket that seeks to move this regime more in line with our current reality.
The policy statement for 2015‑7 is that we add a section to 8.1 that states: The recipient of IPv4 Number Resources has the option to demonstrate need by having an officer of the requesting organization attest that they will use at least 50 percent of their aggregate IPv4 addresses, including the requested resources, on an operational network within 24 months.
By popular demand, based on discussions here at these meetings and on PPML, we have retained the option to use Section 4 criteria to demonstrate need.
To recap what John just presented in the overview, staff and legal, staff says we can do this as written. Staff says that officer attestation will be accepted as full justification for the requested IPv4 block size.
Counsel points out that this constitutes an increased risk of fraud. Do you support this policy as written? And what do you think of it vis‑a‑vis the other three policies that are on our docket that deal with similar problems?
Paul Andersen: Okay. Microphones are open for discussion of this proposal. Same deal as last time. If we don't get input, it's hard for the AC to do it. So center front microphone.
Alison Wood: My name is Alison Wood, and I work for the state of Oregon, and I'm also a candidate for the Advisory Council. I do support this policy as written, but I do have some concerns over the fraudulent pieces and how the enforcement and auditing of those allocations will be monitored by ARIN.
John Curran: So if this policy is implemented, the — ARIN's enforcement would be moved entirely to an after‑the‑fact basis based on fraud reporting. So we would have a circumstance where if someone thought there was a material omission from someone, thought that in fact an organization made a statement that was actually inaccurate and wasn't using the addresses or used them, ended up doing something else with them, and they knew that at the time they made their attestation, someone could submit a fraud report to ARIN.
We have a Number Resources fraud reporting page on the website. We would investigate that. It is possible for us to turn around and if we believe there's been a material misrepresentation, we can pursue that both by reclamation of the block and/or by fraud proceedings, criminal proceedings.
So but we would have no way of doing that other than if the community brought it to our attention sometime afterwards.
Alison Wood: Understood. Thank you very much.
Paul Andersen: Are you still in support?
Allison Wood: I'm still in support of this policy. Always when there's simplification.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. I do not support this policy as written. There are no changes to this policy today that I would recommend to allow this policy to move forward. And I prefer any other of the transfer policies over this policy.
And my reason is this: We already have officer attestation and transfers. It's just part and parcel of what ARIN does.
The officer attestation is to say, yes, everything that we're giving you is legitimate. But the gate is that staff actually looks at the documentation that is given and says this is a legitimate operational network.
You can put the words in that you're going to run it on an operational network and you're going to do all this stuff, but without any proof to ARIN, as simple as it may be, that's a whole different discussion, the level of proof that ARIN wants.
But without any proof, we're really just gutting out needs and calling it officer attestation.
Any of the other policies I believe today will improve the situation for companies looking to do transfers. This is the one policy that I do not feel comfortable with today. Come back to us in two or three or four years, once we've had a much better show how the transfer market is working. But that's my piece.
Paul Andersen: Thank you. Remote participation.
Scott Leibrand: I believe this works. Jason Schiller from Google and ASO AC says he opposes this. He said, "This would remove all verifiable criteria and simply requires an officer attestation that the proposed usage of the IP space in two years might happen even if it doesn't materialize.
This is not only abused by fraud but also by overly simplistic goals. I lament the lack of recommended draft for Policy Proposal 2016‑3 which adequately simplifies need without eviscerating it."
Paul Andersen: Thank you, Jason. Thank you for submitting while you're under the weather, and we hope you feel better soon.
Dani Roisman: Dani Roisman with SoftLayer. I'd be remiss to mention that we have four varying policies talking about adjusting needs for Section 8. Just wanted to make sure for folks who didn't have it in forefront of their mind, two years ago 2015‑9 was proposed that simply eliminated all needs‑based assessment for transfers.
I was the author of that. I just want people to consider we can hem and haw and chew over four very varied versions of a similar issue, which is simplified needs, justification for transfers, and I would really love it if we could move forward and just say none of this is necessary, we're working way too hard and we need to move forward and eliminates needs based like what was done at RIPE.
That being said —
Paul Andersen: Continue please.
Dani Roisman: Specific to 2015‑7, I'm still on the fence as to which of the four I would be — which is the least evil of the four.
But 2015‑7, anything that simplifies and ridiculously simplifies to the point of "I'm going to assign a letter; now let me get on with my transfer" I'm a huge fan of, if that's all I need to do, especially since 2015‑7 specifies it's not just the new address space that has to be utilized but all the address space in aggregate.
So as I understand it correctly, let's see, for example, I have a /16, and I'm using 95 percent of it, and I'm trying to get myself a /17. So half of that. So that means in total aggregate I'm already way over 50 percent; is that correct?
Paul Andersen: Yes.
Dani Roisman: So in that case, where I'm at 95 percent of my /16, I need to get a /17, I can easily say, of course, I'm planning on using 50 percent of my entire aggregate because I'm already using it; is that right?
Robert Seastrom: Yes, if I'm still able to do subnetting correctly, that's correct.
Dani Roisman: In that case, I do support at least the effort being made here to significantly simplify the transfer process.
Paul Andersen: Thank you for your comment. Center rear microphone.
Milton Mueller: Milton Mueller. I'm on the AC. I support this policy, but rather than having another AC member give you his opinion, I just wanted to clarify what I think are some misunderstandings that continually recur around the discussion of this policy.
In particular, those misunderstandings were evident in what Kevin was saying. Essentially, the mistake that's being made consistently is that people are applying free pool criteria to market transfers.
And they're saying we're going to have all this fraud if people can get these addresses without actually proving need in the traditional sense.
And what people seem to be consistently forgetting are two things: Number one, they're paying for these addresses. They're not just getting them for free.
Okay. And, number two, why are we concerned about needs assessment — actually, we aren't any longer concerned about needs per se. We're concerned about whether these are in operational networks or not.
And so what is the issue with proving that they are operational networks? In effect, people are concerned about massive kinds of speculation taking place if we don't have needs assessment.
Maybe that's a valid concern, maybe it's not. But the point is if you're going to engage in massive speculation, the officer attestation is sufficient to prevent that.
If you are going out and getting gigantic numbers of address blocks and then simply reselling them, or that you don't really need them, it will be extremely obvious, I think, to ARIN and obvious to the community and people can report that.
If it is minor, if you're using 40 percent instead of 50 percent, do we really care? Remember, they're paying for the addresses.
So let's have a reasonable discussion about what's actually being proposed here, which is, as the previous speaker just said, a massive simplification of the process of market transfers. And we are not giving away addresses for free. They are being paid for, and very few people are going to go around paying for addresses that they have absolutely no use for.
And if they are lying about the fact that it's an operational network and doing it on a large enough scale for it to matter, I think that will be obvious.
So please have a real debate about what this is proposing.
Paul Andersen: Thank you, Milton. Just a small — we're running a tiny little bit behind. We want to make sure everybody has a chance to comment. For my time management, if you want to comment on this policy, approach a mic. I realize you have to wait a bit, but just so I can have a handle on how many people would like to speak. Center front.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. Yes, let's have a reasonable discussion about what's actually being proposed here. What is being proposed here is that, without limitation, as often as you want, simply on the basis of an officer being willing to sign a piece of paper that says I think I can probably use half of the total space within 24 months, you can get double what you currently have.
So let's say you start with a /12 and you think you can use half of an /11 by the end of 24 months, and a month later you think you can use half of a /10, and a month later you think you can use half of a /9 within 24 months, you can actually parlay that month after month into a pretty large block on repeated officer attestations without any real necessary ability to prove that you can actually use that within the 24 months.
This is a wide‑open policy allowing you to do whatever you're willing to attest you might think you might be able to do in 24 months and to consume as much space on that basis as you would like, as long as you're willing to pay for it.
I do not believe that dollars as the only modulator on fraud is a good solution. And I do not support this policy.
Robert Seastrom: Owen, may I offer a friendly amendment to your statement?
Owen DeLong: Possibly.
Robert Seastrom: Since you had a coda that you don't believe that the dollars are the only moderator, yet you use the verb "get," may I point out that since you're talking about /9s, /10s, and /11s that you're well into the seven‑digit mark on your budget and you have to answer to that to the officer of the company who signs it?
Owen DeLong: Completely understand. And I think that there are a few different environments where I could see acquiring that large of a block of space just to deprive it from my competitors would be potentially justifiable.
Paul Andersen: All right. Thank you. I'm going to ask if all future participants can keep their comment to a minute or under and not be too far over time. Left microphone.
Joe Provo: Joe Provo, Google, also an AC candidate. I'll be very brief. My colleague, Mr. Schiller, has pretty much provided decent detail that I don't disagree with.
And out of the four, I oppose this policy as written and prefer one we will be discussing later.
Paul Andersen: Thank you. Front microphone.
Chris Woodfield: Chris Woodfield, Twitter, AC candidate. My reservations about the policy as written — I realize I'm fifth to the mic, so a lot of my concerns have already been voiced — is the fact that any enforcement of any misrepresentation is entirely up to the community.
If ARIN had some mechanism for proactive retrospectives on these transfers to make sure that a year later that the space is being used as advertised, that would allay many of my concerns around this policy.
Paul Andersen: Thank you. John Curran?
John Curran: The only reason ARIN would go back and look at a transfer after the fact would be is if that organization came in with a subsequent transaction.
Obviously as part of that we would be doing it. But otherwise we're not in a position to even have the information necessary to do what you asked.
It would really need to be either as a result of a resource review triggered by fraud report or as a result of the organization coming back in.
Paul Andersen: We're going to close the microphones after left microphone's comments. So please approach a microphone or start typing feverishly if you'd like to be included.
Kevin Blumberg: Kevin Blumberg. Two things. The first is: Don't appreciate the personal attack. Would prefer that we keep this to the policy and not people's intelligence.
The second part is that once something is approved, once it is done, i.e., once the community's will has been taken care of, it is now under RSA. And what is allowed under RSA versus what we think as the community we can do is a very different scenario.
And, John, correct me if I'm wrong, it is very difficult, unless there is blatant fraud, to revoke space. RSA is a contractual document that makes it significantly more difficult than just rewriting a policy.
John Curran: I would actually not agree with that characterization. Because of the fact that both the RSA contains language that would trigger on a fraudulent representation, and our policy has a very clear resource review. If there is misrepresentations to ARIN, we're extremely well set up to recover the address space.
So I have no concern about that aspect if there's a case where there's a clear misrepresentation.
The problem that we'll have, and if there is a problem, but I want to characterize it differently, is a business anticipates using something within two years and then eight months later goes to a change of business plan. It's next to impossible to refute their statement that they had a need and no longer do.
And so it's not that we're not equipped. In the case of someone who is truly making misrepresentations, we have every tool we need, rest assured.
But in a case where someone's business plans have changed, it's not appropriate to, without a basis, say they're making a fraudulent statement the first time.
Kevin Blumberg: I guess the point is you need the bar of willful, correct? So there is a much higher bar compared to policy.
John Curran: Willful or blatantly obvious, yeah.
Paul Andersen: Go to the tubes next.
Scott Leibrand: Chris Blecker from Walt Disney Company says he opposes the policy as written. "There are better proposals that better address the desire for simplification. Totally open for reasonable discussion, but removing the need for basic documented proof of use and replacing it with officer attestation isn't reasonable in my opinion."
Paul Andersen: Center microphone.
Amy Potter: Amy Potter, Hilco Streambank. I'm concerned about the implication of the potential increase of fraud on other IP address buyers in the market. So right now we already have a situation where there's a problem with registration hijacking going on, and that's making the job of organizations that are out there trying to purchase IP addresses more difficult, because they have to engage in an increasing amount of diligence.
And when the space is already in the name of an organization in ARIN's database, if you have to question whether or not there was some sort of fraud going on there, that makes your life really difficult. And I think that there are other ways of addressing the needs issue that doesn't add this extra problem for people trying to participate in the market in a legitimate way.
Paul Andersen: Are you in support or against this policy?
Amy Potter: Against.
Paul Andersen: Thank you. Next speaker, center microphone.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I'm wondering, as a community, seems to be polarized in talking about this. Some are for; some are against. I'm wondering if there's an opportunity to consider this in a more nuanced way; that is to say, use some sort of materiality threshold based on the size of the transfer should drive the degree of diligence that's required, is it really an all‑or‑nothing situation.
The other thing is perhaps converting the attestations to sworn statements such that if they're false, it amounts to perjury might also be of assistance.
Just a couple of thoughts.
Paul Andersen: Thank you. Just to note that the microphones actually are closed. I apologize for not stressing it after Kevin's comment. But they're closed.
So last microphone comment.
Julie Percival: Just real quick. Julie Percival with Bureau of Labor Statistics, but I'm not here representing them, I'm here representing myself.
From an economic point of view, I think that this policy, or policies like it, that allow for less restrictive requirements instead of more restrictive requirements on policy transfers on IP address transfers, are going to keep people more involved in IPv4 addresses instead of moving to IPv6 addresses.
Paul Andersen: Thank you. Scott, any last — because sometimes there's a bit of a delay. Nothing remote. Microphones closed.
Anything further, Rob? Thank you to Rob for his presentation.
Paul Andersen: We'll engage our counters. The same question as before, well, with the policy number changed, obviously. This is a Recommended Draft Policy. We are talking about this policy specifically. So please consider that when deciding how to vote.
Again, anybody in this room can — or who can hear me is free to support. So let's see if we can keep the same good numbers that we did last time.
Those that are in favor of the AC continuing to advance this policy, 2015‑7, please raise your hand nice and high or indicate online at this time. Nice and high.
Scott, that's not nice and high. There we go. You're at the head table. You've got to set — we want no hanging chads.
Thank you. You may lower them.
Those that are opposed, please raise your hand nice and high and keep it that way until I ask you to lower. Thank you. You may lower it.
So just a reminder as we await the results, if you want to continue to talk about this topic, please find an AC member at the break, at lunch.
There's table topics for some of these policy proposals we're discussing otherwise. Policy breakout room that you can on this or any topic. There is a table topic on this specific policy. If you feel you didn't get a comment in or like a more casual setting, please find that table at lunch.
I see the results on 2015‑7, Simplified requirements for demonstrated need for IPv4 transfers. The number in the room: 137. Those in favor, 12. Those against, 35.
This input will be provided to the AC for their consideration. Thank you. I'll turn it back to John.
Recommended Draft Policy ARIN‑2016‑1: Reserved Pool Transfer Policy
John Curran: Love to get that coordinated. So we'll move on to the next policy. Next policy is ARIN‑2016‑1: Recommended Draft Policy for Reserved Pool Transfer Policy.
I'll give the staff introduction. This was introduced in March 2016, and it's ARIN Policy Proposal 226. AC shepherds, Andrew Dul and Amy Potter. It was presented at one Public Policy Meeting. It was recommended for adoption in June. The text is online and in your Discussion Guide.
The staff understanding: The policy would make IPv4 addresses issued under NRPM 4.4 and 4.10 ineligible for transfer inside the 8.3 and 8.4 specified transfer and inter‑RIR specified transfer policies.
If it's implemented, the staff would not allow those transfers to include IPv4 address blocks previously issued under the reserve pools for NRPM 4.4 and 4.10.
We would continue to allow IPv4 transfers previously issued under 4.4 and 4.10 to be included in NRPM 8.2 transfers, mergers and acquisitions. So if one organization acquired another and they had resources under 4.4 or 4.10, that would move. But it would otherwise not be transferrable.
And the policy could be implemented as written. It does not create a material legal issue. It should be noted that ARIN does permit transfers of resources. This policy would be an exception to that and is consistent with the intent and the policy by which these allocations were made.
In other words, the reserve blocks have particular purposes, and because they have particular purposes it's unclear if the present policy of allowing a transfer simply based on an organization wanting to acquire something and having the need is sufficient.
Resource impact: Implementation of this policy would have minimal resource impact. It could be done in three months.
And we'd update, of course, the guidelines and internal procedures and staff training.
And I will now turn it over to Andrew Dul who will give — I'll turn it over to Amy Potter who will give the AC presentation.
Amy Potter: Currently the NRPM doesn't distinguish between the addresses handed out as part of the reserved pools. The space that was set aside for IPv6 transition and critical infrastructure, there were specific requirements for those organizations that received that space from ARIN.
But at present they can be transferred just like any other IP address just based on the 24‑month need but without showing that you met those original requirements for receiving that space.
This presents two issues that come up. Obviously the recipients of the space won't be using it in the way it was intended in the first place, which sort of undermines the reservation of those pools.
And also if we were to allow out‑of‑region transfers of the 4.10 space, it could complicate the single aggregate from which the providers are being asked to allow block sizes smaller than a /24.
So this one's pretty simple. We just add under the conditions on source of transfer in Sections 8.3 and 8.4 that address resources from a reserved pool, including those designated in 4.4 and 4.10, aren't eligible for transfer. And it's important to note that this wouldn't apply to the 8.2 M&A transfers.
So here you can just see what that would look like. So the staff and legal assessment: The policy doesn't create any material legal issues.
Staff just wouldn't allow transfers of the 8.3 and 8.4 transfers of the reserved pool space.
So the last time this was presented we did have some individuals come up, expressed concerns about dead space being left in the organizations that had originally received the reserved pool space, and there were some suggestions about allowing transfers if the recipients of those transfers were able to meet the original requirements that were placed on the original recipients of the space directly from ARIN.
However, it sounded like pretty much everyone that had that view was also okay with us moving forward without allowing the transfers and then coming back at a later date if that became an issue.
And it looks like we received a much larger amount of support for just moving forward without adjusting to allow transfers of the space.
So what we'd like to hear from you guys today is do you want to move forward with the language as it is? Would you like to add in some transfer language? What do you guys think would be the best solution here?
Paul Andersen: Thank you. Amy, the microphones are now open. So, again, we need some input on this change.
Simply saying you're in favor or against is useful information. We'll start with the microphone on stage left.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. I was the author of this proposal. It came out from an earlier discussion.
Reserved pool is just that, it's reserved. If I'm an Internet exchange operator and I'm legitimately getting it for an Internet exchange, and the community has set aside space for the next 20 years to support Internet exchanges, I need to give it back.
This is just a pure fairness issue. And I don't want any additional language in there because I think that right now this is just clean, easy, get it done. Thank you.
Paul Andersen: So you are in support, then?
Kevin Blumberg: I'm absolutely in support.
Chris Woodfield: Chris Woodfield, Twitter, AC candidate. I would support it as written. The only thing that could improve on this, and I would be happy to save this for a later adjustment, if needed, would be to allow a transfer only if the special purpose of the block for which is originally allocated is going to be preserved.
That's where — that's a corner case of a corner case. I'm not going to ask for that be captured here. Just a comment. Thank you.
Paul Andersen: Thank you.
Next speaker, please. Same microphone.
Dani Roisman: Dani Roisman, SoftLayer. I wanted to also voice my support for this policy as written. I agree with what Kevin said.
And back to Chris's point, actually, there are number blocks we've reserved for a specific purpose. I think it makes sense if you're no longer using them for that purpose, your best bet is to return them back to ARIN so that if another entrant comes in needing that purpose, they can use actually reuse those numbers.
So back to Chris's point, I don't think it would be necessary to make a modification to the policy because those address blocks, the way to transfer them, if I'm no longer using them and you need them, we'll all just give them right back to ARIN and you can go ahead and get them from ARIN if you actually have the same need for which the numbers were originally reserved.
Paul Andersen: But in support as written?
Dani Roisman: In support as written, yes.
Paul Andersen: Same microphone.
Alyssa Moore: Alyssa, Cybera, AC candidate. I echo the comments of the last speaker as well. It's not really a corner case of a corner case because it can just be transferred back to ARIN and redistributed as required. So preserve the integrity of the reserve pool.
Paul Andersen: Thank you. Popular microphone. Same microphone.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I support the policy as written. The case of transferring it for the same purpose was discussed at some length I think on both the general PPML and on the ARIN council list specifically.
We pretty much came to the same conclusion others have mentioned of in such a case it's actually better for this kind of space to just be returned to ARIN and then reissued to the organization with the need within the policy.
We are hoping that as long as v4 remains unfortunately relevant, we won't run out of these particular reserved pools.
So hopefully that will not be an issue.
Paul Andersen: Thank you. We're starting — we only have one remote and one in person right now. So this is a bit of a warning: We'll be closing the microphone soon. Start approaching.
Remote participation, please.
Scott Leibrand: Two remotes. Gary Buhrmaster, unaffiliated, says: Being one of those that suggested allowing transfer under limited cases, I am in favor of moving forward as written.
As Scott Leibrand, plus one.
As Christoph Blecker from the Walt Disney Company, he says: I support the policy as written. I don't think we need to adjust to allow for transfers. If the need for the original allocation is no longer present, then the owner should return the space to the pool and the next person in line can get the space.
Paul Andersen: We got a bonus comment there. All right. Microphones will be closed after this next speaker, if you are not there at that point. Center microphone, please.
Patrick Gilmore: Patrick Gilmore, Markley Group and Board candidate. I support the proposal as written. I had lots of other comments, but everybody else said them. So move on.
Paul Andersen: There you go. So he was short. And nobody moved in time. So the microphones are now closed, and unless there's any remotes hiding there, because there is a bit of a delay. I give them an extra chance.
Amy, any last comments? All right. Thank you very much to everyone for the input on that.
We will go to our — thanks Amy for her presentation first.
Paul Andersen: Steaming along here, catching up on time. With our counters now ready, we'll do this. Get a few more people to put up their hand. Doesn't matter which way, just please participate because it is useful feedback.
On the matter of 2016‑1, those in favor of the Advisory Council continuing to advance this proposal, please put your hand up nice and high. Please leave them up high. I know, a little bit of exercise. Thank you. You may lower your hands.
And those that are opposed, please raise a hand, nice and high. At least one I see. Thank you.
All right. And just let the online finish. We'll allow the tabulation to occur here for a second.
Of course, after a busy day of policy proposals, please make sure you save some time and energy to come to tonight's social. Staff always put on an excellent social. Although I am sad to hear that even though we're back in Dallas there will be no armadillo races. I'm a little sad, but I'm sure it's going to be otherwise a lovely social. There's bull riding. Oh, okay. Can't have everything.
All right. On the matter of 2016‑1: Reserved Pool Transfer Policy, the results are — our timing wasn't as good this time.
The results in the room, still 136. In favor, 46. Against, one.
This information is being provided to the AC for their feedback. And I'll turn it back over to John. Thank you, everybody.
Recommended Draft Policy ARIN‑2016‑2: Change timeframes for IPv4 requests to 24 months
John Curran: Thank you very much.
Okay. We're going to move right ahead. We're right on time here. Next policy is Recommended Draft Policy ARIN‑2016‑2: Change timeframes for IPv4 requests to 24 months.
I'll give the staff introduction to the policy. And this was proposed in May 2016. The AC shepherds, Tina Morris and Scott Leibrand. It's not been presented at a PPM or PPC. It's recommended for adoption. It was recommended in September of 2016.
Text is in the Discussion Guide and online.
The policy language would change the needs assessment time horizon considered for requests to be added to the wait list and it would change that from three months to 24 months. For end user organizations, it would change the need assessment from 12 months to 24 months.
All requests for IPv4 address space destined for the waiting list for unmet requests would consider the 24‑month needs of the requesting organization. All documentation related to the request process on the ARIN public website and in outreach that describe the three month, 12 month, and 24 would require updating. This would include various guides, procedures, and documentation, training materials.
The ARIN Online IPv4 request screen would need updated accordingly to reflect the 24 month interval. It could be implemented as written. It does not create a material legal issue. The policy would have a moderate resource impact to implement. It is estimated it will take up to six months to implement following the ratification of these policy changes because of the extents of number of places that get touched with the timeframe.
And that includes development work and QA work for the online request screens, website outreach material, trade decks, and print publications.
And now I will turn it over to the AC, and Tina Morris will come up and give the presentation.
Tina Morris: Essentially, this is another simplification policy, simplification of NRPM as well as process.
Currently, when somebody comes in to request space, as they still do, not everybody realizes that v4 has run out, they request a three‑month supply of addresses. When they're offered to go to the waiting list, they qualify for the three‑month supply for the waiting list.
However, if they choose to go to the transfer market, they then have to reapply for a 24 month. What this does is simplify that to standardize everything to 24 month.
A list of, as John went through, all the sections of the NRPM that will be updated. And basically all references to three months will be removed.
Legal and staff. It's just updating resources and retraining on process. No real concerns here.
One thing that came up, and one of the first things I thought of when I looked at the policy, was the waiting list that exists today. Everybody that qualified for three months already and is at the top of the waiting list, would they then be able to requalify for 24 months. If space came back, they could take it all kind of thing.
And so we added this clarification of intent. Anybody that wants to requalify for 24 months goes to the bottom of the list. And they will — the current people in the waiting list can requalify but not for more than they originally approved.
So this will not affect anybody's status at the top of the waiting list. It will only apply to people that are way down below, which I think we're well over 3-400 people at this time. So there will be relatively no impact to that.
I guess the only risk to consider is if somebody gave back a very large chunk of space, how this would affect how that was issued. But that is unlikely.
And so just up for discussion, how do you feel about it? Does it seem like a good change to everybody? Is there support?
Paul Andersen: Thank you. Last policy before lunch. So take your time. It's just between you and lunch at this point.
So, okay, I didn't really mean to have no discussion.
So we do have some time allocated here. Please approach a microphone. Or start typing. Not that I don't see you.
Center microphone. Can't have that keep going, so...
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I support the policy as written. I think I had something to do with the writing of the policy.
I think it is a useful simplification. I don't think it presents any meaningful risk. I think it helps bring back in line and reduce some of the discrepancies between NRPM 4 and 8 that have evolved as a result of some of the cobbling we've done on rearranging deck chairs in v4 transfer policy. And hopefully we'll have some community support as well.
Paul Andersen: Thank you. Now left microphone.
Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. And I am trying to go slow so other people —
Paul Andersen: I appreciated that. I did notice that.
Kevin Blumberg: I oppose the policy as written. Unmet requests right now have, just guesstimating, a 10‑ to 20‑year timeline to full. Whatever it is, it's a long time, infinitesimal time out into the future.
The benefit of leaving things at three months is letting people know they can get a very small block, which is fair if it's going to take so long to get, but really that there's nothing there.
I would far rather that staff update their checkbox that says "I'm looking to unmet request for three months and, by the way, I'd also like to do my 24‑month at the same time" rather than radically changing policy.
But my bigger concern is this. This is not simplifying. This is actually going back, reordering Section 4 again to make everything 24 months to deal with the fact that Section 4 is just such a mess.
I would rather us extricate and leave Section 4, which we're dealing with elsewhere, as its own stand‑alone and not keep changing Section 4. Thank you.
Paul Andersen: Thank you. Rear microphone.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the policy as written. Although, Kevin has some valid concerns over there.
I think it's something that we missed a while when we first created the waiting list. The waiting list's purpose in ARIN policy isn't necessarily to provide resources to entities, its primary purpose is to ensure that resources aren't trapped in ARIN when they come back; that ARIN has a fair and useful way to get resources out to the community, whatever that trickle of resources is.
It's not intended to actually necessarily meet anyone's — no one should be under the misconception that it's going to meet their needs in the long term. There's no way to do that in the long term.
And I'll just leave it at that.
Paul Andersen: Thank you, David. If you would like to comment on this proposal, please approach the microphone forthwith. We'll have to close the microphone soon. Center microphone.
Isaac Levy: Ike, NYC*BUG, AC candidate. Question: are there any statistics on the frequency of basically how often three months versus 24‑month waiting period have been triggered in the last couple of years, like how will this change, statistically impact —
Paul Andersen: I forgot about you earlier. I apologize.
John, do you want to get a few points in?
John Curran: Last time I checked, the wait list had over 300. We were approaching 400 entries on it. So far we've removed six from the front. Those are six allocations based on the criteria that were in place, which is based on their immediate three‑month need.
So you've got a circumstance here where — and that was based on space coming from the IANA, which we'll be getting more, but we get less and less every time. It's the remnants in the system being allocated to the five RIRs.
Under the current procedures, because of the way this is written, the people in the wait list who are queue seven through 350, now one through 344, we're unlikely to get past probably the next 20 or 25 of them until such time five to ten years out when organizations literally abandon IPv4 and say I don't need the block, I'm giving it back to ARIN because I don't care.
Depending on where you put that cliff function, that's when this policy will start having any effect, in terms of issuance of space.
Parties that are going on the wait list now are engaged in a coping strategy. They want address space, and they coming to the realization that there is none available via ARIN via the free pool. It's not an effective way to get address space.
So the policy isn't actually going to have an effect on how ARIN issues address space. Or if it does, it won't for 10 to 15 years from now. It's simply a question of what work we ask people to do when they go to the wait list, which is not going to be productive.
Isaac Levy: Thank you for the clarification.
Paul Andersen: Rear microphone.
Stacy Hughes: Stacy Hughes, speaking for myself. If indeed moving this policy forward would result in the merging of the three policies for the best policy, as it says on the website, I support it.
Paul Andersen: Thank you, Stacy.
We're going to close the microphones after our next speaker, if there's no — we do have remotes queued up. We'll close them after the next speaker. Please approach a mic or start typing.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. To speak specifically to the issue of what impact this policy has and why it's useful in spite of the fact that the waiting list is effectively infinite at this point, this isn't about — excuse me. This is not about making the waiting list easier to get on or giving larger chunks of space to people on the waiting list or any of that, because I think everybody pretty much recognizes that we're never going to get to the bottom of that waiting list while it matters.
What this is about is simplifying the policy so that people who are coming in and considering waiting on the waiting list while they try and figure out how to do a transfer or get their transfer organized, or whatnot, have the ability to apply once instead of having to figure out, okay, do I qualify for a three‑month application or a 12‑month application or 24‑month.
We've got all these different time frames at this point in the NRPM depending on whether you're an ISP or end user, depending on whether you're going for a transfer or trying to get on the waiting list.
And it just simplifies everything to have the same time horizon so that it's less confusing to anybody that is coming in and trying to sort all of this out.
There's already enough confusion between the waiting list and transfers and whatnot without making all the time horizons different for no practical benefit as well.
Paul Andersen: Thank you. So last chance if you want to speak. I do see there's one more speaker over there as well. But if you want to speak, approach a microphone in the next couple of seconds. Going. Going, going. I don't know if he's going — he's going, going.
All right. Remote participation, please.
Scott Leibrand: No, this is Scott Leibrand speaking for himself. Scott Leibrand, ARIN AC, DLVR.
This proposal basically means that any application made to ARIN serves as a pre‑qualification for a transfer. Today that is not the case. Today, you can make an application to ARIN that is completely useless. That would mean that all applications to ARIN can be useful.
So given that simple fact, I support the proposal.
Paul Andersen: There are no remote participations?
Scott Leibrand: No.
Paul Andersen: Last intervention, sir.
Allen Shen: Allen Shen, ARIN AC candidate. Pretty much anything that increases consistency in the NRPM I'm for. I just don't think keeping it all different and keeping the three month in there really solves any problems.
Paul Andersen: So you're in support?
Allen Shen: Yes. As written.
Paul Andersen: As written. Thank you.
All right. Microphones are closed. No remote participation.
Any comments, Tina?
Tina Morris: No.
Paul Andersen: Thank you to Tina and the AC for their work on this.
Paul Andersen: Get your arms warmed up one more, and then we have a lovely lunch. So with the counters in place, I would ask those in favor of ARIN-2016‑2, that the AC continue to advance this policy, please raise your hand nice and high. Please keep it high. Thank you very much. You may lower it.
Those that are opposed to the policy as written, please raise your hand nice and high. Nice and high. You may lower it.
After lunch is the election procedures. As chair of the Board, I would encourage everybody to take some time. We have three great slates of candidates. They're going to be up to speak if they're here. And it's very important that you take the time to consider those candidates and vote. So that's my plug.
John, did you have a plug as well there?
John Curran: No, I was going to work on the banter that you wanted me to work on.
John Curran: If you wanted to talk about like property market outside the US, that might be helpful.
Paul Andersen: I was thinking of bringing my book, "A Practical Guide to Canadian Immigration," in with me and give it away as a door prize.
But I decided against.
On the matter of ARIN-2016‑2: Change timeframes for IPv4 requests to 24 months, we went up. 140 in the room and remote, by the way.
In favor, 40. Against, two. This input is being provided to the AC for their consideration. I will turn it over to John for lunch.
John Curran: Okay. We now have some final presentation, and then we're going to go to lunch.
Lunch is in the Gold Room. And there are, as we've talked about, lunch table topics. If you're interested in talking about a particular topic, gather your lunch, look for the sign, go to that table, and people with commonality will be sitting at those tables. There's a women's networking lunch in the Parisian room. If you're a woman, that's a good option.
Remember, take your valuables with you. This room is not locked during lunch. Wide open. If you have something particularly valuable, bring it with you.
That's it. I'll see folks back here at 1:30 promptly. Yes, 1:30. Thank you.
(Lunch break 12:04 PM)
NRO Number Council Report
John Curran: Welcome back from lunch. Some important announcements: Turn in your ticket after lunch to claim your ARIN 38 t‑shirts. You all have tickets, you received them, and you go out there and we have shirts for you.
Other announcement — I don't think we have any other announcements. That's it.
The afternoon agenda is we're going to have Louie Lee's report from the NRO Number Council. And we'll have a review from Wendy Leedy of ARIN's election procedures. We'll then go through and have the candidate speeches for the NRO Number Council, the ARIN Advisory Council, and the ARIN Board of Trustees.
And then we'll have Open Microphone session. So it's going to be a — should be a very good, productive set.
And the other thing we have this afternoon is we have a few policies. After our break we'll come back and we'll do a Draft Policy 2016‑4: Transfers for new entrants, and Draft Policy 2016‑5: Post-IPv4-Free-Pool-Depletion Transfer Policy. That's the rest of our day.
Remember that at the head table — at the head table, myself and Louie Lee at the head table. Louie is about to give the presentation. So let's get started.
Louie, come on up for the NRO Number Council, a.k.a. the ASO AC report.
Louie Lee: Okay. And I am failing to switch. Hi, I'm Louie Lee. I'm the chair of the ASO Address Council. Yes, you did see the NRO Number Council report. I'll get into the distinction in a little bit.
So it's not advancing from this. Here we go. All right. The Address Council is made up of the NRO Number Council.
This is an advisory body, and it's composed of 15 members, three from each of the five regions. In ARIN, two are elected at large and one appointed by the RIR board.
We're here to be observers of the RIR and the ICANN processes.
The term of office in ARIN, these are staggered in three‑year terms and, of which, two are elected, one is appointed. This year the elected seat is up for election there.
What do we do? We advise the ICANN Board, and we selected two ICANN board members. We also select the NomCom member and we appoint various individuals to various ICANN bodies.
What do we advise the ICANN Board on? Numbering policy, whether they should adopt a policy that the community has put up, whether they should adopt, ratify, put into action, execute — these are the ones that require outside parties to act on, like the IANA policy.
When do we meet? We meet monthly over teleconference, and we also have an annual, physical, face‑to‑face meeting.
And here we go. Specifically these are the members of the Address Council. You'll see Jason Schiller, Kevin Blumberg, and myself are the three from the ARIN region.
And I believe my clicker may need new batteries. Thank you.
So we do have two new elected or appointed members, that's whose term starts next year. Omo from AfriNIC, he's elected for a three‑year term. And we also have Brajesh, APNIC, elected for a two‑year term. When these members are identified, they are invited to begin participating with our group.
They are — status is observer and they can fully participate except for voting within our processes.
Our scheduled monthly meetings are at every first Wednesday of the month. We can have emergency meetings to address issues on immediate basis, for instance, issues that may be identified at an ARIN meeting. There may be a chance to, say, kick off some process, some way to look at issues before the next ARIN Meeting so that maybe we can advise the group what changes might need to be made to address certain issues.
Since the last ARIN Meeting, we've met five times teleconference and one face‑to‑face meeting.
Global policy management, we oversee the global policy development process. The global policy are policies that are defined within the scope of the ASO agreement. These are Internet number resource policies that have the agreement of all five RIRs, according to their Policy Development Processes and ICANN, and require specific actions or outcomes on the part of IANA or any other external ICANN‑related body in order to be implemented.
So in contrast, you may hear the globally coordinated policies. These would be policies that each RIR would enact but do not require an outside group to execute.
So what makes a global policy and how is it developed? The policy would need to follow each RIR's own Policy Development Process.
These processes have all the same characteristics in that they are open, meaning anybody can, from within or outside the region, participate, give input, be heard; transparent in that the conversation's available posted to anybody who would like to go see and follow along; and it's bottom‑up, meaning it's not mandated from the top. It is developed through the community.
So a global policy would be submitted in all five regions. And each region would follow its own process. Then when it gets passed to the ASO for review, the ASO — the Address Council's task would then be to make sure that the policy actually followed each PDP, the Policy Development Process; make sure that the timelines are met; and that all significant viewpoints were considered.
Then after doing so and acknowledging that this has happened, we will forward it to the ICANN Board for consideration and ratification.
There we go. The light's not coming on consistently. Okay.
Currently there are no Global Policy Proposals being put through the development process, but, as I mentioned, that there may be a coordinated policy that you may hear about soon.
So recently we did appoint Akinori Maemura to serve on Seat 10 on the ICANN Board of Directors, and we had a many‑month process in order to go through the selection process with the nomination, comment, interview, and due diligence phase.
So in June at the Helsinki ICANN meeting we held a public session to inform the ICANN community on what is the policy for — what's a policy for the numbers community, how is it developed.
We gave a summary of what are the current policies that we're putting through categorized. So here's a set of transfer policies. Here's a set of Whois policies.
And we would also invite them to come join us. We had meetings with the ICANN board members, with the number community. We also held a face‑to‑face meeting.
We held a discussion on updating and revising our procedures related to the ICANN Board selection. There were several items that we decided needed some clarification to match up our procedures to the ICANN bylaws. There was some clarification that was needed. For instance, the ICANN bylaws referenced that should a member of the ASO or any other supporting organization have a member standing up to be a candidate for an ICANN Board, then that person should not participate in any of the processes for the election.
Makes sense, but at some point during the election process, we had two members that were candidates, but one of them was no longer a candidate, and we had to decide, well, if this person is no longer a candidate, then can that person participate? And we made the clarification that if the person had even accepted the nomination, then that person is no longer available to participate in the process through to the end, rather than just the status of whether it's a candidate or not.
We made an appointment. Hartmut Glaser was appointed to the ICANN Nomination Committee. The NomCom, along with appointing to the ICANN Board, has appointments to various ICANN bodies also.
If you'd like to see what other activities we're involved in, please go to our website, www.aso.icann.org. Thank you very much.
John Curran: Questions for Louie?
Owen DeLong: Owen DeLong, Akamai, ARIN AC. There's a lot of dependencies and whatnot in there that reference ICANN directly, given the status of the SLA and the fact that ICANN can at some point in the future be replaced by somebody else by this community, if that should come up. Is there any move to make that more generic to the person holding the IANA contract rather than specific to ICANN?
John Curran: Let me address that. So recognize there's two very distinct relationships with ICANN. One relationship is the numbers community collectively has a Service Level Agreement for ICANN to provide the IANA Number Registry Services, the IANA services for the v4, v6, 32- and 34-bit ASN free pools.
Completely distinct from that is an MOU between the RIRs and ICANN to use ICANN for facilitating the development of global policy. It's the ASO relationship.
We could change the service level provider for the registries, and that wouldn't necessarily change our relationship with ICANN or the fact that they, via the ASO and their Board ratification, review the global policies that we develop.
So it's an independent relationship. There's two relationships right now with ICANN. They happen to hold both. But we could be using someone else for administering global IANA policies and still decide that we want to use ICANN to help us review and ratify them in their development.
Owen DeLong: Got it. Are we permanently, forevermore, locked into the ASO being a function provided by ICANN with no choice? Or is that a contract that we apply to ICANN independently also as a second contract that could be moved as well?
John Curran: So there's a very exciting question embedded there. Let me try to work at it at an angle.
I do believe we could end our relationship with ICANN. ICANN has in its bylaws a role called the ASO. And its bylaws presently say the NRO, the five RIRs collectively, should fulfill that role.
If we stopped using ICANN via our MOU with them, it's not clear that they would decide that they don't need an ASO and still have someone else fulfill that function.
They have a role for an ASO in their functions within ICANN. So, for example, they want to have number community representatives on their Board. They might decide to find some other way to get those appointments for those two seats.
They want to have an empowered community that helps provide oversight to ICANN, which is made up of representatives, including — the ASO holds a seat on the empowered community. They might decide, well, if the RIRs collectively aren't going to be the ASO, then how will they go about getting number community representation that they want for their governance functions?
Owen DeLong: I guess I'm a little bit confused as to what governance functions they would have related to numbers remaining if we moved the SLA off of ICANN and moved the IANA function out of ICANN. And so where would that remaining relevant —
John Curran: The IANA function is an administrative function. It's a clerical function. It's much like who we have cater the event here. You change the caterer, it doesn't change ICANN. If we change to a different IANA, none of that changes the ASO/ICANN relationship unless we sit down and talk to them about what that change is.
Owen DeLong: I get that. But their purpose is to — the purpose of that relationship, as I understand it, has basically two functions and only two functions, and that is global policy that dictates how the IANA does its thing, and creating new RIRs.
John Curran: Actually, it includes a role in helping assure the stability and security of the Internet identifier system, ecosystem. That's how ICANN defines its mission.
If they're going to be doing that and that includes numbers, it's probably good for us to talk to them. I see someone in the back who may have knowledge of this.
Mr. Ron da Silva. Do you want to speak?
Ron da Silva: Thanks. Ron da Silva, ICANN Board of Directors. I think it's important to note that in the whole Policy Development Process in ICANN there are various constituents or components that comprises the multi‑stakeholder model that's embraced there. The ASO, the Address Serving Organization, which is defined in the bylaws, is just one of seven.
There's the Government Advisory Council that has all the governments represented. That's one of those groups. So this is just a construct for how policy is developed within ICANN.
So the ASO function, like John described, is an ICANN thing. And the RIRs have come together with understanding an agreement with ICANN that they will fulfill, through the NRO, that function that is described within the ICANN ecosystem.
I think your questioning is if — specifically around the IANA functions, that's just a service agreement that is information that is stored in the database on behalf of the registries, with regards to numberings — if that's portable and it's moved and it's carried on to another organization or another entity to fulfill that service agreement, that is completely independent of still the need to have this multi‑stakeholder model that is embraced within ICANN. And having the addressing community participate in that is why there's an ASO described.
As John is saying, there are two very different things — the need to have accurate numbering and registry information through the IANA contract is one thing, and participating in the multi‑stakeholder model on behalf of the Internet numbering community is a separate item.
Does that make sense?
Owen DeLong: Yeah, I'll take it offline.
John Curran: Very good. Any other questions for Louie?
Louie Lee: Or my hat.
John Curran: Or Louie's hat. Okay. Thank you.
ARIN Board, Advisory Council, and NRO NC Election Procedures | Candidate Speeches
John Curran: We're now going to move into the next section of our program, which involves the election procedures and the candidate speeches. I'm going to have Wendy come up and give the overview of the ARIN Board and Advisory Council elections.
Wendy Leedy: Thank you, John. Good afternoon, everyone. Thank you for joining us. My name is Wendy Leedy. I'm ARIN's Member Engagement Coordinator, and over the next several minutes I'm going to briefly walk you through how to vote in this year's ARIN Elections.
Before I begin, however, I would like to take a moment to acknowledge ARIN Members and thank you for your ongoing involvement in and support of ARIN, especially during election season.
Now let's talk about ARIN Elections. Let's see. Each October, eligible General Members in Good Standing have the opportunity to vote in ARIN Elections.
Beginning today at 2:00 PM, the elections will open to eligible ARIN Member organizations voting contacts, who, on behalf of their organization, will virtually cast an electronic ballot to elect candidates to ARIN's Board of Trustees, Advisory Council, and the NRO NC.
This year, all voting contacts must vote through ARIN Online.
Sorry, I don't know why I'm nervous up here. Okay.
Now I'm going to highlight key voting details. To be considered an eligible Voting Contact, an organization must first be a General Member in Good Standing as of the voter eligibility deadline. This year, that was September the 6th.
This includes no outstanding invoices. An organization must also have designated a sole voting contact point of contact that's linked to an ARIN Online account.
This year, ARIN will have 3,975 ARIN Member organizations who will be eligible to vote in this year's elections. They will have the opportunity to elect two candidates to the ARIN Board of Trustees, six candidates to the ARIN Advisory Council, and one representative to the Number Resource Organization Number Council.
As I mentioned already, voting will open at 2:00 PM and will remain open until 3:00 PM Eastern time on Friday, October the 28th.
Voting is conducted online. So you may cast your ballot within minutes from your computer or mobile device and from the comfort of your own office or home.
As you will see, there are five easy steps that I'm going to go over momentarily that will explain to you how you can log on to ARIN Online and cast your ballots.
And why voting is an extremely important responsibility? It helps guide the future of ARIN, the Internet, and our community.
Before I begin to walk you through the process, however, I wanted to quickly highlight ARIN's election process in the timeframe in which we prepare for and launch our elections.
As you will see, this year in August the nominations opened and were opened from August the 1st through the 30th. In September we had the voter eligibility deadline, which I mentioned was September 6, and an initial candidate slate was announced and the petition process opened, wanting to note that this year we didn't have anyone petition.
Throughout September and October, Statements of Support were opened and remained open, and remain open. If you are still interested in submitting a Statement of Support, I encourage you to do so. We do check within, actually, probably every couple of hours, but we'll absolutely approve within a 24‑hour business timeframe.
And the petition deadline did close, which brings us to this month, October. Earlier this month the final candidate slate was announced and it's now time to vote.
Now, to review and show you what the process is going to look like, I'm going to go ahead and walk you through the steps. As you will see, step one is going to www.arin.net. From there on the left‑hand navigation bar you'll see a place where you can log in to ARIN Online.
Once you log in, it's going to bring you to your dashboard. Once you're logged in and you look at the top of your dashboard, you're going to see step three. You'll see a "Vote Now" message. "Vote Now" has been hyperlinked. You will need to click on that. Once you click on that, that will actually take you into the ARIN Election system.
There, for the voting process, the next screen you're going to see is ARIN's transparency agreement. You will want to go ahead and click "I agree," which is step four.
John Curran: So when you look at that text, it says: "By submitting your vote, you acknowledge ARIN will receive a copy of your ballot selections. ARIN receives this information to administer the election and audit the accuracy of the results. ARIN will not disclose this to any third party how specific votes or ballots cast within the authentication system without doing so a duly entered court order, subpoena or the form of legal process."
So just so you know, it says we do get a copy of your ballots. We don't show them to anyone. And it turned out this is pretty essential for us to be able to audit the election system. We figured we'd let you know.
Wendy Leedy: Thank you. From there, once you have clicked agree — and the one thing I guess I should also note, if you click you do not disagree, you do have the option to log back in later when you're comfortable and ready to move forward. Otherwise, if you do select disagree, you will be ineligible to vote for this year's elections.
The next screen that you'll see is actually the candidate ballot. So at this particular juncture, there's a couple different things that I want to go ahead and point out.
Every member organization, regardless of your size, has one vote. But if you're representing more than one ARIN organization, your vote weight will be the total weight of the number of organizations you're representing. So in the middle of your screen, this is a prepopulated number. For some of you it may be one; for some of you it may be different.
This particular screen shot provides you with an opportunity to see the example that if you have more than one you can alter it and go through the voting process again.
So if you wish, you can either leave the vote weight as it is or you can reduce the vote weight number.
Once you have made that selection, if that's an option for you, you will want to select your candidates. And then you'll click the submit vote. If you have multiple ballots you're wishing to cast because you do have a higher weight number, then just note that the ballot screen will re‑appear if you've changed that number, allowing you to repeat this process until you've cast each ballot for each organization you're representing.
And, of course, if you are changing it, you will continue to input the new vote weight less than your unused vote weight.
Again, you'll select your candidates and then you'll want to submit your votes. Once you've submitted your vote, you will, on your screen, see the ballot as you cast it. You will also receive an email confirmation with, again, the time that you voted, where you voted and who it is that you had selected.
Some key reminders I wanted to point out to everybody. Please, if you haven't already done so, review the ARIN Elections 2016 Voter Guide. A hard copy has been mailed to all of our members. A PDF is also available online at www.arin.net/participate/elections.
Again, as I mentioned, and I'm probably going to keep mentioning throughout the rest of my time here and with you, today voting is open at 2:00 PM, so please get out and vote. You do have through Friday, October the 28th, until 3:00 PM Eastern time to cast your ballot. And, again, you simply need to log in to ARIN Online.
For NANOG and ARIN Meeting attendees, you are eligible to vote in the NRO NC election. You would have received an email from members at arin.net on Monday the 17th with a unique link that will allow you to cast your ballots.
If you have any questions, if you need any assistance during the election process, feel free to email a member of our member services team at email@example.com. You may also submit an ARIN Online ticket by selecting Meetings/Elections.
And at this particular juncture, I'm just going to open it up for questions.
John Curran: Any questions for Wendy? I see someone coming forth.
Chris Woodfield: Chris Woodfield, Twitter, ARIN AC candidate. I'm the voting contact for my Org. Is there any explicit prohibition for voting for myself?
Wendy Leedy: No.
John Curran: No.
Chris Woodfield: Thank you.
John Curran: Vote for who you think is best.
Any other questions for Wendy? Thank you, Wendy.
Wendy Leedy: One quick thing I did want to let everybody know, I'll be outside at the election help desk until 5:00 today, if you have questions. I'll be back tomorrow from 8:00 until 3:00. Feel free to email us, we're happy to assist you. And, with that, I'll turn it over to John who will introduce this year's candidates.
John Curran: Here we go. First, I'm going to talk about the candidates for the Number Resource Organization Number Council. We have two of them, Jason Schiller and Robert Kenny. Neither of them are present.
I'm going to talk briefly about each. Jason Schiller, incumbent candidate, he's the one holding the spot today.
He's with Google. Engineer who solves problems on technical merit. Brings a level‑headed operations and engineering mentality to the table and provides good policy that is in the best interests of the Internet as a whole. And experienced in providing oversight in the performance of the IANA function.
This is the write‑up that Jason provided. We summarized.
Jason wanted me to add he's presently ill but recovering. He also wanted to point out that he spends time — there's a global policy facilitation team that Jason helped institute and has been involved, working on harmonization when there's global policy between the RIRs at the NRO NC. He's found that very helpful and wanted to make sure the community knows he's actively involved in that.
So moving on, Robert Kenny. This is his description. Network engineer at Pitt Ohio, in the transportation sector. Commitment to furthering education and compliance standards relating to the networking field. He has experience with IPv4 and IPv6.
The bios of these people are online. Feel free to read them. You can read the Statements of Support or make one as noted.
Advisory Council, as I go through each of these, we'll have each one come up and read a brief statement.
So the Advisory Council list is — I don't have a list. You'll bring them up one by one? It might be dying (referring to the clicker). Interesting.
So the list of candidates for the ARIN Advisory Council — Allen Shen, Owen DeLong, Alison Wood, Isaac Levy, Tina Morris, Joe Provo, Gary Giesen, Chris Woodfield, Alyssa Moore, Scott Leibrand, and Rob McCann.
First one up will be Allen Shen. Allen, come on up.
Allen Shen: Good afternoon, everyone. My name is Allen Shen. I work at Charter Communications. I'm not sure how I ended up first here, but I'm not going to say that this election is rigged or anything —
John Curran: Position of honor.
Allen Shen: Hasn't worked out for everybody. So why should you vote for me for ARIN AC?
So, well, I guess in keeping with the election theme, I'm a libertarian when it comes to kind of governance. So I think we should have access for everybody to get numbering resources to be able to conduct their business, but with as minimal bureaucratic red tape as possible. So that really means keeping the NRPM simple.
I don't really want to see the NRPM grow. I'd like to see more consistency. I'd like to see, if anything, it shrink and get rid of some of the language I think that — we're already starting, I think, with all of the transfer policy that we're all really focused on.
So I have 20 years of experience in building service provider networks, and that's really been my focus, build out backbone networks and focusing on peering. And I also manage the IP address management team with Time Warner Cable for many years.
And I think the big lesson of that whole leadership position there was stay organized, be transparent with ARIN, and the IP addresses will flow pretty regularly.
But certainly want to take some of that experience to be able to help guide the ARIN policies that goes forward and make sure that we can have a free‑flowing Internet that benefits everybody from the smallest of organizations and non‑profits to the largest of ISPs.
So I hope you'll be able to vote for me and appreciate your time.
John Curran: Thank you, Allen.
John Curran: Next up, Owen DeLong. We drew the names earlier, and that's how they ended up on the presentation order.
Owen DeLong: In case there's anybody in the room that doesn't know me, I'm Owen DeLong. I'm humbled and honored to be in my ninth year on the Advisory Council at this point.
I've been actively involved in the ARIN policy process almost since its inception for more than a dozen years or so now. I'm very passionate, as many of you know, about ARIN policy and about number resources.
I participate in the Policy Development Mailing Lists of most of the RIRs on a fairly regular basis. I'm very active in the numbers community and have been for a very long time. I'd like to continue serving the community, and I hope you will give me your vote and let me help serve the community for another three years. Thank you very much.
John Curran: Next up, Alison Wood.
Alison Wood: My name is Alison Wood, and I am an engineer from the State of Oregon. And I'm very excited to be here. I'm super excited to be nominated for the ARIN Advisory Council. I got involved with ARIN about three years ago through a colleague, and then was honored to be chosen as a Fellow in the Jamaican conference earlier this spring.
Today I work as a technical engineer and network engineer for the State of Oregon, which helps me to live in the technical field and also work with our Legislature, our governors, and our user base to implement policy and advise on different policies that are brought forth into my agency.
I feel like my unique experience in the public sector would help the ARIN community to bring the public perspective, whereas a public entity where customers of many of your companies, but we're also a public entity, so we do a lot of work with different policies and policy implementation.
And working in community outreach, which is one of my passions, to educate our user base, to educate our customers, and then to take their needs and their concerns and make it into a relevant network and have their applications relevant and purposeful in our environment.
And I see that with the ARIN Advisory Council of getting out there in the community outreach, which is phenomenal, they're doing such a wonderful job with it. And I would love to have the opportunity to work in that outreach, to work in the education, to work with the ARIN Members and the ARIN community to deep dive into the policies that are important to them, and then use that information to help route those policies — that was a network joke, routing — to route those policies through the Council, through the Board, and to stay educated, to stay relevant and to keep the community moving forward and thriving the way the council has been working the last several years.
If elected, I'd like to take the skills that I've had in those community outreaches, in the deep dives, in the policy implementation, and move them forward.
I'm very grateful for the opportunity to be on the Council. I'm very grateful to serve the ARIN community. It's an amazing group of people. And I'd like to continue the work that the council has done for several years.
One of the things that's most important to me as an engineer is deep diving into packet captures, which in this room is probably not a big deal, but in a lot of rooms people say, "Ew, why would you want to do that?" Well, it's taking the different pieces of the puzzle and bringing them together to have a successful outcome of a usually unsolvable or very hard problem to solve.
And I feel that with my skills and doing different technical things like that and with my skills in policy advisement, I can deep dive into the problems and help sort them out with the members and the community and then bring them forward to a successful outcome.
So I would be grateful for your vote. I would be very happy to serve all of you, to work with the members, to work with the community and to continue the awesome work of the ARIN Advisory Council. Thank you very much.
John Curran: Next up, Isaac Levy.
Isaac Levy: Hi everybody. Thank you very much for having me here. Let's see. My name is Isaac Levy. Everybody calls me Ike. Only my mother calls me Isaac.
I'm here as a nomination for the Advisory Council. Being very, very green in this room and in this community — I've been POC on a number of different net blocks for organizations I've worked for.
My work experience is in technology Internet start‑ups, small, growing, kind of psychotic companies. So I represent from that side, from basically the users.
But what I'm really here for, what I really thought was compelling when I was asked for the nomination, is to be here as a bridge to the BSD UNIX community, which is something I've participated in since the late '90s, as well as just a hacking community in general and other communities that have been around for a long time — DefCon and ShmooCon and all these other things, and places where I'm not just like an attendee but really care and a part of maintaining a community.
But in the BSD UNIX scene, and what I think is important in bridging gaps is to bring that experience as well as the experience of NYC*BUG, which is an organization I've been part of founding in New York, the New York City BSD user's group, bringing practitioners, sys admins, implementers, network engineers together. And in 2007, for example, we did the first like IPv6 LAN party as a hack‑a‑thon event to introduce people to IPv6 who had never touched it.
And these are the kinds of — how can I put it? — this idea of kind of bridging the gaps between practitioners on the ground, kernel hackers and committers on the core operating system projects has been something that's been really exciting and successful and been really beneficial to the BSD UNIX community.
So I see myself here basically being able to start to build bridges between what's going on in governance of IP space on the Internet and strategically being able to bring that stuff back to the BSD UNIX community, who care a lot about IP networking. If you've never heard of BSD UNIX in this room, I wonder why you're in this room.
Anyway, that's it. So thank you very much. Appreciate it.
John Curran: Next up, Tina Morris.
Tina Morris: Hi. I'm Tina Morris. I've been participating in the ARIN community since 2008, which I realized during this trip seems like it's gone by much faster than I ever expected.
When I first came to my first meeting, I was a network engineer that dabbled in IP address management. I was learning how to do my first ARIN request.
I moved on, became primary IP administration at a cable ISP, and now I work with Amazon doing their IP administration.
In my role at Amazon, I deal with transfers, legacy addresses, other RIRs, NIRs. I believe that gives me a somewhat unique perspective on policy. And I also enjoy bringing different perspectives to the community.
I have served one term as an AC member, and I look forward to trying to serve the community further in another term. I feel like I still have more to contribute and a lot more to learn. So please vote for me.
John Curran: Next up, Joe Provo.
Joe Provo: Hi. I'm Joe. Thanks for the nomination and the opportunity to stand for the AC. I'm not going to regurgitate what I put on the forum. So please do read. I encourage you to read everybody's bios to get a larger picture of everyone who is standing.
But, quite simply, my career has been working for the Internet. And that's it. I was no good for any other actual work.
I've been involved in resource management and allocation since getting my first CIDR block and dealing with knackers, back in the startup days in '94.
And therefore dealing with knackers, I was fully in support of the creation ARIN in '97. It was the first year I really got to participate in operations forums. And it became a bit of an addiction.
I've participated and helped run NANOG. I worked closely with someone I don't always agree with but we can drive together in the same direction when we had the change of NANOG into an independent organization.
I've been an active participant in the RIPE community since 2000. And I looked at this morning, at the first PPML, the first policy I was vocal about on the list was actually in 2002‑7, micro assignments for multi‑homers, and funny we're still talking about similar things. And, boy, a whole lot of IPv6 evangelism was still going on at that point in time.
The crux of it is that I just seek logical, transparent, and simple processes that can be engineered and implemented. I'm an engineer. I just like to make things go and move on. So I do have an eye for new entrants, because if the bar was as high as our telephony friends back in the day, I wouldn't have a career.
So I wish that we maintained the policies having an eye to enabling new entrants as we go forward. That's pretty much it. Thanks.
John Curran: Next up, Gary Giesen.
Gary Giesen: For those who don't know me, I'm Gary Giesen. And I'm a network architect at Centrilogic.
I'm also a former member of the Board of Directors at the Toronto Internet Exchange and a former member of the Canadian Network Operators Consortium Regulatory Committee.
I've been fortunate through my current employment, that with our various business units, I'm exposed to a wide variety of customers from private networks, managed private and public cloud, network consulting.
I get to see — like I said, I get to see a broad range of customers and industries and the unique challenges that especially small businesses face around acquiring and managing addresses.
There's many new challenges we face in the post run‑out world, and the biggest being ensuring liquidity of the v4 transfer market while maintaining appropriate controls and making sure that those wanting to transition to v6 can get access to the resources they need.
I believe that with my technical governance and regulatory experience, as well as my knowledge of the ARIN Public Policy Process, I can provide valuable insight — excuse me, I can provide valuable insight and sound judgment to serve the needs of the community.
And that while I think we have a great slate of candidates, that you couldn't go wrong voting for any of them, I ask you for your vote because I believe I'm the right candidate to get us through this critical juncture. Thank you.
John Curran: Next up, Chris Woodfield.
Chris Woodfield: Hi, everybody. I'm Chris. I am currently a senior staff network engineer at Twitter. I've been in this business for about 18 years now, which usually impresses some crowds. Probably not this one as much.
I've worked on both v4 and v6 address plans over my career, working with customer allocations as well as moving on to other content companies with address plans for my own organization, and have v4 and v6 implementations.
I'm mainly an engineer, not a politician. Hope that doesn't disqualify me. But this is an engineering policy organization, which means that the policies and procedures put forth, it's up to the engineers to work in those environments, and as such we need to bring our perspective into play in the Policy Development Process.
Why do I want to be on the AC? Frankly, I feel it's my time to start giving back. I've been a customer and consumer of many of the not just ARIN but NANOG and other organizations.
Earlier this year I joined the NANOG Program Committee, which has been an excellent experience for me, that I really appreciate. And I would like to try to be able to try to give back and help and work on the AC as well to contribute what I can.
I appreciate the fact that ARIN has worked with a community‑driven, community‑developed process for so long and has maintained the principles that allow it to maintain the goodwill of the Internet community at large, the ARIN user base.
One thing I'd like to bring to — one thing I could bring to the AC is that it seems that we do a lot within the Policy Development Process in terms of impact analysis. There's the Policy Experience Report, where policies are retroed and analyzed for various issues that come up after policies are implemented.
One thing I'd like to see, to the extent this isn't done already, is make success or failure criteria part of the development process. So to throw out an example, if there's a policy that we're concerned might open up a window for abuse, can we define what we're looking for, define a measurement for success or failure of a policy, work with ARIN staff to make sure that we can analyze that after implementation?
And I think that what that would allow us is to be a lot more flexible and quicker to adjust policy as needed.
At my day job, we do things called one percent experiments where if we want to find out if something works out or not, it's a very lightweight process to turn it on for a small set of our users. But with that obviously that doesn't work for a policy organization, but what it does bring is the concept of clearly defined success or failure measurements.
And I think that's something that I could advocate for on the AC and make us a more effective organization. Thank you.
John Curran: Alyssa Moore.
Alyssa Moore: So hello to those of you who know me, and allow me to introduce myself to those of you who don't, because I'm a very fresh face in the community. I've been following the Policy Development Process at ARIN for about a year now. Jamaica was my first meeting.
And while it does feel a little like jumping the gun to be running for AC at my second meeting, I have also been strongly encouraged to do so by many of the folks in the room today.
So that has quelled a little bit of the imposter syndrome, but I think that there is an incredible wealth of institutional memory and experience in here. And it's time that that's starting to get passed on to the next generation of stakeholders. And so far I have been very happy to be a part of that process.
In terms of my background, I'm a Policy Analyst by trade. My educational background is political science, which is not a super common background to have in this community. But given the fact that the most commonly accepted definition of politics is who gets what, when and how, I think it fits because that's exactly the point of the Policy Development Process here.
So in my day job, I do things like respond to government consultations, and I follow regulatory affairs in telecom quite closely. I've done things like appear in front of the CRTC, many submissions to the government of Canada, reports to the government of Alberta. Stuff like that.
I'm also involved with the Internet Society, Canada chapter. And in my other volunteer pursuits I'm very politically involved. I sit on the executive of a political party in Alberta, things like that. So the community process is something that's very close to my heart.
I would just really like to be involved in the simplification process of the NRPM. I think that's something I can bring a lot of experience and policy wonkery to. I'd love to be a part of that if you'll have me. Thank you.
John Curran: Next up is Scott Leibrand.
Scott Leibrand: Hello. I'm Scott Leibrand. I build artificial pancreases. I've also been on the ARIN Advisory Council for nine years, and I think that's enough. So I'm up here to tell you not to vote for me.
I accepted the nomination, and I will serve on the AC if elected. But I accepted the nomination on the basis that there was some concern that we wouldn't have a strong enough slate for the full six seats that we were going to have available with the resignation. I've looked at the slate. I think it is strong.
I think it would be better for the world if I were off building artificial pancreases, and someone else were elected. With that said, I don't think there are enough people hearing my voice that will not vote for me, so if I'm elected, I hope it's for the one‑year term and not the three‑year, and I'll be happy to keep on contributing. But as Leif said, save your vote and save the world.
John Curran: Next up, Rob McCann. Not here. Okay. So I'll read his bio summary.
Founder and president of Clearcable Networks. Has practical experience in traditional information technology and service provider networks. Brings a unique perspective on matching emerging technology with sound business principles to establish successful strategies for product and service deployment. Broad view of network deployment with business and social issues that surround broadband, and that will provide valuable insight.
His full bio is on the web along with Statements of Support.
So this concludes the slate for the ARIN Advisory Council. I'm actually going to briefly ask that some people who didn't speak come up.
If Cathy Aronson, Milton Mueller, and Kevin Blumberg would come up for a moment. Among our list of AC members who didn't get a chance to speak are Cathy, Milton, and Kevin.
And they're not speaking because they're not up for another term. They opted not to run. But they've all given years of service to ARIN, and I wanted to call them up and give them a round of applause for their service.
John Curran: Thank you. Okay. Now I will move on to the ARIN Board of Trustees. And this year the slate has four candidates — Bill Sandiford, Merike Kaeo — am I close? Close. You'll correct me when I get close. I maim these, even the ones that are simple. Patrick Gilmore and Charlie Liu.
First up, Bill Sandiford.
Bill Sandiford: I'm not used to going first. I'm used to going last with an S last name.
Hello, everyone. For those that don't know me, my name is Bill Sandiford. I'm proud to have been part of the ARIN community for a little over eight years now, including four years spent on the Advisory Council and three years as a member of the Board of Trustees, including this past year as our treasurer.
I spent over 20 years of my life in senior management roles at Internet Service Providers in different types of telecommunications businesses.
When it comes to experience and my suitability to serve on a Board, which is a little bit different from something like the Advisory Council or other policy positions, I'm actually a graduate of the University of Toronto's Rotman School of Management who has a program that's specifically directed towards being directors of not‑for‑profits or trustees for not‑for‑profit organizations like ARIN.
I've spent a significant amount of my time in my private life or in my business life doing work with governments, government relations, whether it be the government of Canada or others. And outside of ARIN I've done a lot of work with other boards, including the Canadian Network Operators Consortium. I'm currently on the Board and vice chair of CIRA, the .CA folks, and the Toronto Internet Exchange community. Outside of the industry, I've done things like local service organizations, minor hockey, et cetera.
I'm very proud of a lot of the work that the Board has accomplished over the last few years during my term. If reelected, I continue — I promise to continue to help move things forward, like additional Board transparency so that the members understand what's happening with the Board and what's going on. Continuing to dedicate more resources towards some of our engineering products, which a lot of you knew for a long period of time we had a long and seamlessly ever‑growing list of projects.
And that's about it for me. I ask that you give me your vote so that I can continue to serve you for another three years. Thank you.
John Curran: Next candidate for the ARIN Board of Trustees, Merike Kaeo. Closer? Further away?
Merike Kaeo: You were close but not quite there. But don't worry about it, because I've had colleagues for 25 years who are still learning. So not an issue. So my name is Merike Kaeo. The name is Estonian, for those of you that have any curiosity.
Most of my background, or at least a quick synopsis, is listed there. I have spent 25 years basically in the Internet ecosystem. And for me it's a lifestyle, as it is for many, especially those that I've seen in different continents in the last two months.
So I started my networking career building the backbone for the National Institute of Health. So that was back in the late '80s. So since then I've also been participating in the IETF. That was since 1992. So besides my operational background, I have a very healthy technical background.
And for the last five to six years I've participated as a security Advisory Council member for ICANN and also the Internet Governance Forum, which really had me understanding global cultures and policies as well as human rights issues.
And I think as the Internet keeps evolving, there's really a lot of cross‑pollination between the operational, technical, and policy communities. And I've seen at least in the last six to seven years that most of the technical, operational, policy meetings that I go to, that all the constituents, at least the leadership, is there.
So while the Board functions primarily as a role of governance, and I know that the role — and to ensure that the ARIN functions according to its charter mission statements, I do believe that my well‑rounded understanding of the Internet ecosystem will be an asset as a Board member.
I think very important for continued ARIN activity is, as Bill was saying, transparency. That's absolute.
I also think that community consensus and feedback is important, and also inclusiveness. The younger generation is increasingly more important.
I keep seeing the same folks giving the same talks, and I love the Fellowship programs. I love the inclusiveness of the younger generation, because we need to keep making them aware how important it is to contribute even in policy decisions. And policy, technology, and operations in my mind go hand in hand.
I think we need continued outreach and education as well. I'm a huge proponent of education. For the last 15 years, I've spent my life really dealing with security privacy and Internet safety issues. And I think that's paramount.
So in terms of leadership, I think fiscal responsibility is very important. That will be very important for the ARIN Board. In my career, I've held a lot of executive positions in the last five to seven years.
I have, for 15 years, run my own consulting company. And also while, okay, it's not in the technical community, I was president of my homeowners association for five of the nine years that I was on the Board.
So I deliberated for quite a while when I got a phone call to say "I want to nominate you for the ARIN Board," because I wanted to understand specifically what time was involved and what dedication. And so I spoke to a number of former Board members, because I don't want to accept the position if I don't have the time and cannot make the commitment.
I have the commitment. I want to spend the time. I hope you will vote for me. Thank you.
John Curran: Okay. Next up we have Patrick Gilmore.
Patrick Gilmore: Hi, everybody. I'm Patrick Gilmore. I'm going to try really hard not to regurgitate what's on the candidate website. Should read all those things. It's really a great slate of candidates. I'm kind of proud to be among them.
Anyway, as it says on the slide, I've been working on the Internet for a couple of decades now, mostly in operations network architecture, but I've also been on the Board of a bunch of non‑profits. I'm better known in operational communities, but I know a lot of you guys out there.
I know most of the Board, most of the AC, most of the candidates, to be honest. Instead of talking about my day job, I think I'm going to talk a little the bit about my board experience. I think it's more relevant.
I've been involved in a lot of bottom‑up, non‑profit organizations. I've helped start some. I've been on the board of some that are 20 years old. This means that I really know what it takes for a community‑based company to satisfy the members as well as stay for the long term, which is, I think, a couple of things that is really important to the ARIN Board.
So in addition to my volunteer jobs, because these things don't pay, if you know what I mean, my volunteer jobs plus my day job means that I travel a lot. I spend an inordinate amount of time in airports and airplanes.
Doesn't bother me. I actually like it. I like meeting new people, meeting old friends, and getting a bunch of new ideas.
I think this is really important, because if you're going to be involved in guiding community‑based organizations, you need to have a big personal network.
You need to see a lot of different perspectives and points of view. And I think that by going to all these different places overseas, managing companies overseas, going to conferences overseas as well as in the United States, I get that perspective.
One of the big benefits of this nice, wide‑ranging experience I have is that I get to see both the policy and the operations side. I spend an awful lot of time teaching people on the operations side about policy, and to a lesser extent I teach some policy people about operations.
I think it's very, very important, and I do spend a lot of time on it because it's something that's important to me personally. I'm very passionate about the Internet itself.
I think that the Internet is — honestly, it's one of the greatest inventions of all time. Not the greatest, but it's pretty up there.
I really think that, like, the things that — the open and free sharing of ideas, the ability that I can sit here and talk to somebody in China instantly, all the things you guys know about that make the Internet great, is very important. And keeping the Internet running in a way that is available to everyone, that is correctly managed so that it's not captured, so that we have proper stewardship of not just number resources but everything, but for ARIN obviously number resources is personally important to me, and I'm very passionate about that.
Anyway, that about sums me up. Hopefully that gives you an idea of why I think I have both the experience, the passion, and the motivation to help ARIN as it goes into the future.
And I humbly ask for your vote for ARIN Board of Trustees. Thank you very much.
John Curran: Final candidate for the Board of Trustees is Charlie Liu.
Charlie Liu: Good afternoon. Ladies and gentlemen, I'm Charlie Liu. I run a small team to manage IP space for my company, Charter Communications, the second largest cable operator in the U.S. with more than 20 million customers.
By trade, I was a physicist. I joined AT&T build‑out to pursue my career in telecom industry back in 1991.
It's interesting to note that that year there's only one — there was only one website in the whole world. And today we have millions, hundreds of millions of websites.
The growth was tremendous and truly amazing. As the Internet grows, World Wide Web multiplies in that it's getting more complex and more risky. Names and numbers become big issues and big business.
We've already run out of the free pool IPv4 address, and arguably that progress on IPv6 adoption is not as fast as most people would like to have.
Starting for IPv6 actually is pretty complicated. We know more than 50 percent of the Internet content is accessible by IPv6. However, the local content is the issues. Internet companies like Google, Facebook, Yahoo!, YouTube are doing great in IPv6 front. But the global content, such as the website of your township, your bank, your kids' school, they are pretty much behind.
ARIN already has a very good program for all these to educate the public in IPv6. But I think we can go one step further, go one extra mile to organize local IPv6 experts in companies and institutions to reach out to their own community, to make their local content IPv6 reachable.
Due to the human natures, names and numbers actually are pretty intertwined. Being able to use names instead of IP address is a huge convenience. And it's going to be more so as IPv6‑based Internet in the near future.
There are a lot of concerns about the security, the reliability, and control of the Internet‑naming system today.
And ancient wisdom states that the name that can be named is not the eternal name. And easy to say there's no perfect naming system, and agree to that. And I think the issue on the governance of Internet domain system will be with us for a long time to come.
Fortunately, every RIR, including ARIN, has already earned great trust in the Internet community. If needed, we can serve together as an anchor of future Internet.
For the next two to three years, the main challenge to ARIN is to help promote and observe the growth of IPv6 Internet, particularly on the local content side, while still allowing IPv4‑based service operate securely and grow economically before IPv4 runs out of its useful lifetime.
And that would be my focus if I have your vote to become a member of the Board of Trustees.
Thank you very much for your attention.
John Curran: So there's also a Board of Trustees member who's not up on that list. I'd like to ask him up on stage. Vint, if you could take a moment. Vint also is not running for the Board of Trustees. His present term will end December 30th. I'd like to take a minute to thank him for his years of service to the ARIN Board.
Vint Cerf: Well, I do appreciate that. I don't think I deserve a standing ovation, but I'll take it anyway.
First of all, it's been an honor to serve on the ARIN Board. I have watched an organization struggle with issues and policy successfully. I think largely this is a consequence of the people, you, who are involved.
I wanted to give a lot of credit to the CEO over here who has carried a great deal of weight not only with regard to the operation of ARIN itself, but in presenting ARIN's views to the rest of the RIR community, to the IGF, to ICANN and others. He's been a very, very effective spokesperson for the policies that you've adopted and for positions that we need to keep the Internet open and operational and as free as possible.
He's also done a good deal of work with our own US government and other governments persuading those things.
So it sounds like you're leaving and I'm not. But either that or you just — or you just died or something like that.
The answer is no, I just want you to understand and appreciate how critical it is to have someone in the CEO position who's capable of doing this.
John Curran: If I knew this was your topic, I would have given you a much larger slot.
Vint Cerf: So he earns his pay, let me tell you.
I also want to acknowledge my fellow Board members who have made this a relatively easy task. When you chair a Board that's capable of cooperating, willing to have disagreements in a constructive way, things are much easier — why are you laughing about that (referring to Paul Andersen)? Well, you're chairman now, so now you have that problem.
So I just want to say that you have a very effective team here. I must tell you I'm very pleased to see a mix of people standing for the Board, and in particular Merike. I'm so happy to see a woman up here at last, running for the Board position. We've lacked that for a long time.
So I won't exactly disappear in a puff of orange smoke. First of all, I'm going to continue to be interested in what you're doing and caring a great deal about getting IPv6 in place.
I kept listening yesterday to all the problems with IPv4 transactions and the like, thinking: The solution to the problem is to deprecate v4 and adopt v6. Why don't we just do that? I know it's a lot harder than that.
And, finally, I think I may end up as the wine steward for the Board, because I have to say that I have a couple thousand bottles in my wine cellar, and I need help consuming. And the Board shows up in the late months of the year, so I would be happy to offer access to the wine cellar to the existing and incoming board members, and I look forward to that.
So thank you very much. See you on the net.
John Curran: Okay, with that we'd like to go and tell everyone voting is open. You have the opportunity to go online and enter your ARIN Online account and cast your ballot.
We now have a break coming up, and, folks, we need you all back here to do more policy at 3:30.
The t‑shirts are available. For those people who need to pick up their t‑shirt, that's available out there as well. So everyone take a moment, go on out, enjoy break, get your t‑shirt. See you back here promptly at 3:30. Thank you.
(Break at 2:48 PM)
Recommended Draft Policy ARIN‑2016‑4: Transfers for new entrants
John Curran: If people will come in, get settled, we'll get started. We're going to resume our afternoon with two draft policies. First one of these is Recommended Draft Policy ARIN‑2016‑4: Transfers for new entrants. I'm going to give the staff introduction.
This was proposed in June 2016 as ARIN Policy Proposal 229. The AC shepherds are John Springer and David Farmer. It has not yet been presented at PPM or PPC. This will be the first Public Policy Meeting it's been presented at.
Recommended for adoption in August 2016. Text is in your Discussion Guide.
So, staff understanding: 2016‑4 allows IPv4 requesters to qualify for up to a /24 without demonstrating prior utilization from an upstream or other source and removes the exceptional immediate need classification currently used in IPv4 needs assessments.
ISPs may automatically qualify for up to a /21 or provide supporting information that justifies more. If specified, transfer‑related, 24‑month needs will be considered. If not, three‑month need will be considered. In all cases, renumbering needs will be taken into consideration.
End users may automatically qualify for up to /24 or by supporting information — if specified transfer‑related, it's a 24‑month need that will be considered. If not, 12‑month need will be considered. In all cases, the basic criterion for qualification for an end use will be 50 percent utilization within one year.
So yes, let's see, all documentation related to the request processing would need to be updated. This is a pretty significant amount of work, but it could be done.
It's unclear whether ORGs who are identifying as ISPs should automatically be considered such or whether ARIN should confirm the organization provides network services.
The policy can be implemented as written. Policy does not appear to pose any material legal risk.
This is a pretty significant change, however. The policy would have a moderate level of resource impact. Take up to six months after ratification to make the policy changes.
We would be updating guidelines, internal procedures, ARIN Online, nearly all the descriptions that accompany the request, outreach materials, and our training decks. We would be doing staff training.
Now, I will now turn it over to the AC to give their presentation. John Springer is going to come up and give it.
John Springer: Thank you, John. Hello, ladies and gentlemen. I'm John Springer. Normally when I do these things, I essentially just stick to the problem statement, policy text, so on and so forth.
But in this case I was requested to do a little bit of translating. So I'm going to — I've supplied some text here that's more in the vernacular.
So if you look at the policy text in the guide, it's got a problem statement and several sections of the text that I'll be going through one by one.
Okay. So the problem statement essentially says that a new entrant that's going to start business or end‑user might not have a /24.
There could be a lot of people that fit this criteria. And currently there's kind of a catch‑22 situation for both ISPs and end users, that you need to have a /24 from your upstream to qualify for a /24 from ARIN. And it might be hard for new entrants to get that. And if they don't have it, it's currently not permitted to get a /24 from ARIN.
This Recommended Draft Policy would permit this. It's going to change several sections of the NRPM. 184.108.40.206 would be replaced, including the preamble and all the subsections, and places the policy text in directly under the 4.2.2 heading.
The wording is quite formal. And I could spend a lot of time translating all the equivalencies between the text and this. But essentially this allows, this 4.2.2 section allows, new interim ISPs who do not have a /24 to get one via transfer and thus satisfy the requirement. It can also get more than that if they have the appropriate documentation.
4.3.2 concerns the end users, same operation as the previous section. There's a dif here. Replaces one clause with another clause.
And this section applies to both ISPs and end users and allows for larger initial allocations with the proper documentation via the transfer process and specifies the term.
There's another policy proposal on the docket here today. I don't know if it's today. During this meeting, anyway. 2016‑2 is going to work on the horizons, all the time horizons in the PDP and change them to 24 months.
If that gains consensus, all of the horizon‑related text in this Recommended Draft Policy will be updated accordingly.
Paul Andersen: All right. Thank you, John. I know it's after lunch, so everyone's feeling — but if you could just get up and get some input at the microphones, that would be much appreciated. So the microphones are open for your comments on this proposal.
Dani Roisman: Hi there. Dani Roisman with SoftLayer. I had a question as to how 2016‑4 relates, I don't know if it's premature to ask, to 2016-5. So 2016-5 includes initial block for transfers specifically. So it proposes in 8.5.4 that organizations without direct assignments or allocations from ARIN qualify or transfer for an initial IPv4 block of ARIN's minimum transfer size.
Is that in conflict? Does that complement or does it happily co‑exist with what's presented in 2016‑4?
Paul Andersen: I would just say that the policy proposals have to live by themselves. I realize there's a multiple competing one, and that's something the AC will have a challenge to resolve in their meeting and all that.
But they're not in conflict because they're two separate policies, I would suggest. I understand you're saying if they were, for instance, both to be forwarded, the AC would have to resolve those conflicts before they can go forward. Dan, did you want to add something? I'm saying that, in general, the policy itself is stand‑alone.
Dan Alexander: Correct. And John will correct me if I'm wrong as well. But typically with 2016‑5, that's primarily operating on Section 8, related to the transfers. Whereas this one we're discussing changes Section 4. So they would technically be — they can't operate independently of each other.
Dani Roisman: The reason I brought this up is this one specifically — first of all, it's titled transfers to new entrants. And it speaks about, specifically about, transfers. It says it speaks to updating NRPM Section 4.
So just to talk about transfers for new entrants.
Dan Alexander: Correct, because in the current situation, the needs requirements for a transfer are based on the requirements spelled out in Section 4.
Dani Roisman: Thank you for answering that question. So as far as my support, I do support 2016‑4 the way it's written. I appreciate that it strips out language which is not necessarily applicable to today's environment. And it simplifies, seems to simplify the workload that's required for new entrants, for ARIN registration services to go through what new entrants are requesting space. So I'm in support.
Paul Andersen: Thank you for your comment of support. Rear microphone in the center.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO. I support the policy as written, but as has been asked of us in the previous ones, I support this as a secondary. I do not — I believe it's an incremental change that, when you look at it and even the description that was given by the shepherd up at the front, is complicated, because we are dealing with Section 4 and having to make multiple, multiple changes.
While I understand there's changes and I feel it would be a good incremental change for the community, I believe that we're better suited with the next policy.
Paul Andersen: Thank you. Remote participation? We have one early.
What do the tubes got to say, Milton?
Milton Mueller: Okay.
Jason Schiller, Google. "When ARIN had a free pool, they did not ask ISPs getting space under slow start to provide proof that they were an ISP. This policy is intended to be slow start in the transfer world. As such, it parallels ISP transfers.
"It also extends slow start to small end sites who have complained at multiple ARIN meetings that they would have trouble qualifying for IP space.
"I support as written."
Paul Andersen: Thank you, Jason, although you should be getting some rest and getting better. Front microphone.
Scott Leibrand: Scott Leibrand, ARIN AC, co‑author of the proposal. I want to address Dani's question. The short answer is this is not in conflict with 2016‑5, I believe you're asking about.
However, 2016‑5 would essentially make this not as necessary, because 2016‑5 does the same thing in Section 8.
But there is still an effect of having adopted this, which is if there ever becomes a waiting list that's meaningful, then people could get their /24s from that as well.
I would say that if you support the general idea of this and you think this is a good way to do it, support this. If you also want to support 2016‑5, great.
The AC will make a decision after this meeting as to whether it's still worth moving forward with this one if 2016‑5 passes, but they're not in conflict and they certainly could move forward. There's no problem there.
Paul Andersen: Thank you for the comment. Rear microphone, please.
Alison Wood: Hi, my name is Alison Wood, State of Oregon and Advisory Council candidate. I support this policy as written because a lot of the community members that I've spoken with have indicated issues with complications, and I think encouraging ISPs in the marketplace and simplifying their process is only positive for all of us.
Paul Andersen: Thank you. I've been talking for about 10 minutes on this policy. So if you would like to have some input, I'd appreciate if you could approach a mic or start typing. We'll close the mics in about a minute.
Owen DeLong: Owen DeLong, ARIN AC, Akamai. I support the proposal as written. This is, as Kevin mentioned, an incremental change. It goes in the right direction.
I think that the next proposal, which I will talk about more at the time that that's being discussed, conflates the architecture of the NRPM in a really negative way.
Section 4 describes the policies governing the distribution of v4 addresses. And I'd like to see us keep v4 policy in Section 4.
Section 8 describes the policies that are specific to transfers and unique to transfers, and I'd like to see it remain as small as possible and only expressing what is unique to transfers rather than essentially eliminating Section 4 in favor of putting all of our IPv4 policy in Section 8. So I support this policy as written, and I think it's a much better alternative than the next one.
Paul Andersen: Thank you, Owen. Last call for the microphones. Please start making immediate movement to a microphone if you would like to comment on this proposal. Otherwise, the microphones will close.
I don't see Milton suggesting that the tubes have anything. Any last comment? Let's thank John — microphones are closed — let's thank John for the presentation.
Let's lock and load our counters.
I know, lunch. Come on, doesn't hurt to do a little bit of stretch break. Feel free to do a practice one right now before we call the question.
The question will be, again, on the item of 2016‑4: Transfers for new entrants as a Recommended Draft Policy, whether you are supportive or against the AC continuing to advance this proposal.
I'll ask those in favor to please raise their hand nice and high. Get that energy going. Online please indicate accordingly. Please keep them nice and high. All good. You may lower.
And now those opposed please raise their hand nice and high. I do not see any, but there's also very bright lights in my eyes. Thank you. You can lower your hand if it is actually raised, but I don't see any.
Now we'll wait for the results, which will be momentarily. The results are being fed into the ARIN PDP‑11 right now to process the results. No one has maintained the code in 15 years. Somebody...
Are you offering? A little rusty.
All right, on the matter of ARIN-2016‑4: Transfers for new entrants, the envelope is — yes, online votes were counted? Yes. So, oh dear, 124 people in the room. In favor, 38. Against, nil. This input is being provided to the AC for their consideration.
I'll turn to John for the last policy of the day.
Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy
John Curran: Okay. We have one more policy to cover today. And it is Recommended Draft Policy 2016‑5: Post-IPv4-Free-Pool-Depletion Transfer Policy. I will do the staff introduction, and then we'll have Leif come up and do the AC presentation.
This was proposed in June 2016, ARIN Proposal 230. Leif Sawyer and David Huberman are the AC shepherds. It has not been presented. It is recommended for adoption by the AC. They recommended in September 2016. Text is online and in your Discussion Guide.
Draft Policy 2016‑5 creates clear policy separation between the needs assessment conducted for transfers and the assessments conducted for nontransfer‑related IPv4 requests. More specifically, the Draft Policy places needs assessment‑related policy language for transfers into Section 8 directly and removes the use of Section 4 of NRPM from the transfer process.
If implemented, staff would no longer use Section 4 but would use the new Section 8 to review needs assessments. The use of the word "blocks" without IPv4 may introduce ambiguity. In the past we found the ambiguity to be sometimes concerning to people. So we just noted that. But the policy can be implemented.
In terms of potential issues, transfer customers may interpret it to 8.5.1, the new language to require a newly signed RSA for each transfer. It's not that way. You need an RSA to receive those blocks but you can use an existing one.
And we propose slightly different language. But, again, the current language is implementable.
There is a question regarding the language staff interpretation of 8.5.6. It says intent is that — we believe the intent is that all previously IPv4 blocks must be cumulatively utilized. Existing policy may cause confusion because if it's unevenly utilized and it's not the cumulative measure, then some people may not believe they qualify.
We have again suggested language, but we would interpret it as cumulative even without the change.
The policy does not appear to create any material legal issues. Resource implementation, have minimal resource impact. It's very similar to existing policy. And we'd be able to accomplish it within three months after ratification.
We would update the guidelines and internal procedures to make sure they have the right references.
That's it. And I will now turn it over to Leif to give the presentation by the AC.
Leif Sawyer: Thanks, John. So this is three of four of semi‑tied policy proposals, this one being recommended. First, actually, I just want to thank Kevin Blumberg for his work on this proposal before he rose up in stature and then passed this off to me. So thank you, Kevin.
IPv4 was depleted, pool was depleted in 2015, which means that a lot of the policies we developed aren't relevant to transfers. So that means in order to make things easier for the transfers, we need to figure out how to streamline the process.
And that's what this proposal does. You can see we have a number of benefits for that. Reducing complexity is always a very good thing. The NRPM is getting along. And there's a number of AC candidates here who came up and said that one of their priorities is to help streamline.
So we know that that's a good thing to do. Separating the free pool criteria from transfer criteria, again, the big benefit there. Reducing the complexity, making it easier for folks to understand what they need to do in order to get IPs on the transfer market.
Right now there's a whole bunch of one‑off policy bits in Section 4 trying to find the edge cases in the free pool market which don't make sense in the transfer market.
So making that cut gives us a clear set of criteria for all the transfers. And once we make that break from Section 4, we need to add in something for utilization criteria so we don't just have an open free for all on the transfer market.
So we added in some verbiage here which will lower thresholds on utilization and future allocation size.
So, the new Section 8.5 gives us the new requirements. You can see that in the little handout streamlined or in your Discussion Guide.
And then we updated Sections 2 through 4 — paragraphs 2 through 4 in Section 8 to reference that Section 8.5.
So as John mentioned, staff and legal came back. We did resubmit some text to try to clear up some of those concerns that staff had. So we do mention that they must have a current signed RSA, no more than two revisions behind.
It's solely for the purpose of use on an operational network because we want to prevent financial speculation on the market.
The minimum initial or subsequent IPv4 allocation is a /24 because that's what can be routed.
And again to address this second, we made sure it's efficient utilization of the existing cumulative IPv4 space. And continuing the officer attestation of the use of the transfer space within 24 months.
So the questions are: Is it useful for the community to break the dependency between Sections 4 and 8? And is it useful to simplify the transfer requirements?
Are these proposed new requirements too lax or too restrictive? And is this less complex and fair, more fair than any of the other three policies presented?
That's up to you.
Paul Andersen: Get myself organized here. Okay. Microphones are now open on this issue. Who would like to be first? Somebody must have a thought.
You have somebody over there already. Let's lead off.
Milton Mueller: This is from Jason Schiller of Google. "I have a question about the meaning of, quote, ARIN will proceed with processing transfer requests even if the Number Resources of the combined organization exceed what can be justified under the current ARIN transfer policy, end quote.
Does this mean if I have a need for one host, I can transfer a /24 and claim I can't dispose of the unused space because it is below the minimum?
If I have need for 200 hosts and decide to buy a /8, can I hold the remainder of the /8 for resale or plans to use it in the far future?"
Paul Andersen: Who would like to take the first? Andrew Dul would like to take the first crack at that.
Andrew Dul: Andrew Dul, CrowdStrike, ARIN AC and policy author. The text that Jason is referring to is not actually changing from the current NRPM, I believe. It is the editorial change that was made to the NRPM in the last six months to clarify ARIN's practice with regard to 8.2 transfers.
And, John, if you have any additional comments —
John Curran: That's correct. This doesn't represent a policy change. That section is simply the existing language that indicates that we will process transfer requests even if the number resources of the combined organizations exceeds.
Paul Andersen: Thank you for that clarification.
Scott Leibrand: Can I comment on that particular thing, very briefly?
Paul Andersen: That was Jason's only question, Milton? Okay, a quick comment on this.
Scott Leibrand: Scott Leibrand, policy co‑author, ARIN AC. I believe the text might be slightly different, but the meaning is the same. The important part there is that only applies to 8.2 transfers, which, under the current rules, if you have an 8.2 transfer, it's going to go through and then ARIN has obligations to help you dispose of those unneeded addresses via other ways.
But the language is intended to be very clear that ARIN is not going to block an 8.2 transfer or take space away, and that's in line with current text.
Paul Andersen: Thank you. Stage left microphone. See, I fill the queues. I just keep going around. If you want to speak quickly, find an open microphone.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. Yes, it is not only useful to break the dependency between Section 8 and Section 4, it's critical moving forward.
We spend too much time on Section 4 making change after change and then finding that we've iterated a bunch of changes that then break a bunch of other things in Section 4.
The whole point is that what ARIN is doing now is, correct me if I'm wrong, 99.x percent Section 8 transfers.
This would give the community a very clean set of transfer rules, which have been made a little easier for everybody; but, more importantly, this would give us a future to keep things clean when it comes to the transfers, which is where the bulk of our work is going to be in the future.
So at the end of the day, all of the changes in this policy are good. This, to me, is the top policy of all of the policies that have been brought forth in regards to the transfer market. And I wholly support it.
Paul Andersen: Leif, did you want to comment?
Leif Sawyer: No.
Paul Andersen: Front center.
Dani Roisman: Dani Roisman, SoftLayer. On the discussion points, I agree with Kevin. It's definitely useful to break the dependencies between Section 4 and 8.
I think the policy governing transfers really deserves to be unique to policy governing free pool assignments.
Plus, the complexity that exists in Section 4 is a significant barrier to entry for unexperienced entrants in the transfer market and I believe adds additional delay and complexity to completing a transfer transaction.
I think it's also useful to simplify the transfer requirements. Regarding my opinion whether or not the needs are too lax or too restrictive, as I said earlier this morning, you can guess my gut is they're, of course, too restrictive because I believe in elimination of all justifications for transfers.
That being said, I do appreciate the improved — the simplified language in this policy. I think it's a really good next step for us.
Paul Andersen: So you're supportive?
Dani Roisman: I'm very much in support of this policy as written. Thank you.
Paul Andersen: Thank you.
Peter Thimmesch: Peter Thimmesch, Addrex. First‑time speaker at an ARIN meeting.
Paul Andersen: But long‑time listener, right?
Peter Thimmesch: A long‑time listener.
Paul Andersen: And big fan.
Peter Thimmesch: First of all, in support. Addrex has been watching this, obviously, with great interest for about five or six years. But I want to actually bring up that we we've been noting the slow evolution here of people supporting the wholesale change.
Wanted to give some statistics to kind of help. People have been — half the people in this place are marketplace participants.
We've had in five years, three months 2,105 companies around the world ask for access. We've looked at them as close as we can. We found two that possibly could be speculators. One was a law firm representing someone. And then there was a venture fund that was looking.
That's it. And neither of them have ever done a transaction. So it's nice to finally feel like that's actually part of the mix, is the straw man that you're fighting, speculators is not part of this, it's more operational requirements.
So we're wholly in support of the fact that that just didn't appear; that no one appeared in this marketplace with hundreds of millions of dollars to effect it. That didn't happen.
But we also wanted to say it's very nice to see a discussion where it's getting to be simplification and look at the complexity, because it is very hard for small companies to meet this burden.
It's actually weirdly anti‑competitive for small business to get involved now since there's no more free pool. It harms their ability to get into the marketplace because they don't have the ability.
So we looked at this and we actually appreciate it. Thank you.
Paul Andersen: Thanks for that information. It's great to get that in.
Alyssa Moore: Alyssa Moore, Cybera. AC candidate. I strongly support this policy. It's my preferred one of the four today.
We talk a lot about simplifying and removing complexity. I think this is one of the first major steps in that direction and taking away from the unwieldiness of Section 4 that's emerging. So I support this policy.
Paul Andersen: Thank you. We're running low on speakers. And that's not a bad thing. But it is a reminder if you'd like to give some input to the AC that they very much are eager for, please approach a microphone with haste.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the concept of this policy. However, due to the staff comments, I can't support it as written.
There's a number of things that still need to be cleaned up in it for it to really be ready to move forward.
There's some things that need to be taken care of regarding those staff comments. So while I support the concept, I cannot support the text as written.
Paul Andersen: Leif, did you want to comment?
Leif Sawyer: There was an update posted, David, which addressed the staff comments. The updated text has not yet been re‑sent to staff and legal.
David Farmer: Yeah.
Paul Andersen: John, do you have a comment?
Owen DeLong: Owen DeLong, ARIN AC incumbent candidate and Akamai.
Paul Andersen: Oh, dear.
Owen DeLong: I strongly oppose this policy. It is an abandonment of the basic structure of the NRPM.
It conflates IPv4 addressing policy with transfer policy in such a way that you now have more dependencies, not less, between Section 4 and Section 8, because now you've got this sort of "is it still operative or is still not operative?" governing IPv4 policy. And then you have this Section 8 that sort of loosey‑goosey replicates much of the complexity from Section 4. And then you have to figure out how they all fit together.
I tried to go through this exercise a couple weeks ago; it made my head hurt, and I stopped.
But if I as a very experienced person with ARIN policy had such difficulty reconciling the results of this policy, I'm not thinking that it's going to make it easier for the average small business or the average newcomer, but actually harder.
I think we would be much better off simplifying Section 4 very extensively. And I'm all for that at this point.
But there are reasons for most of the stuff in Section 4 to be there. They are not necessarily specific to having a free pool as has been repeatedly claimed.
But I am all for going in there and looking at Section 4 in a meaningful way and simplifying it to the bare bones requirements that we need to preserve in Section 4 and having Section 8 remain specific to the things related to how transfers are conducted and try to eliminate the variance of IPv4 policy that have crept into Section 8 and move those into Section 4 and keep Section 4 as our complete repository of v4‑specific policy.
I think that's a much better structural way to approach this. If you want to deprecate Section 4, we can do that, too.
Paul Andersen: Thank you.
Microphones will be closing in 60 seconds.
Mike Byrnes: Mike Byrnes, IPTrading. I support the policy as written, but I do have a couple of questions.
I see an officer attestation is required for blocks larger than a /24. Is there a definition of an officer that ARIN uses in receiving this attestation?
Paul Andersen: John, do you want to start with that?
John Curran: It's a corporate officer. It's someone who is listed on the record of the organization with the state that it's incorporated in.
Mike Byrnes: Not a manager; it's got to be a listed corporate officer?
Paul Andersen: Listed corporate officer.
Mike Byrnes: Second, there was no maximum size that I saw. So am I to understand that the officer attestation would serve, if he attests to the need for use on an operational network, for any size transfer?
Paul Andersen: I believe that is — Leif, did you want to?
Leif Sawyer: I can let the policy authors —
Paul Andersen: Do the policy authors want to give their intent?
Andrew Dul: There's no maximum. There is no maximum in the current transfer policy.
Mike Byrnes: I still support.
Paul Andersen: I apologize. Rear microphone.
Kevin Blumberg: Kevin Blumberg, The Wire, NRO NC. One quick question to start with. In regards to the changes, the editorial changes or the changes that staff have recommended, I believe, when I read both of those changes, there would be: staff is okay, we would prefer it to be this, we will interpret it this way, and moving forward.
So as a community member today, my feeling is pass it. If the ARIN AC is able to make those editorial changes, wonderful. If they're not able to make it as editorial changes, still pass it, because we know the way that staff is going to interpret it, and we will do follow‑up policy to clean up that little bit of text.
There is an immediate need for this policy, which is small Internet providers need to be able to be pre‑approved at the 50 percent mark to be able to have the ramp time to get the space and the funds that they need for it.
This actually really helps the smaller players long term.
Paul Andersen: Thank you.
John Curran: Your interpretation that staff sees the two clarifications as editorial and clarifications only, we can't implement the text as written.
Paul Andersen: Before we go on — if you don't approach a mic now, we'll close the mics in a second here. Either please start approaching, otherwise the microphones will close. We'll go to the tubes next.
Milton Mueller: Yes, we just have Jason Schiller wanting to clarify that he supports this policy as written. And he thought that the lack of clarity was that it wasn't clear to him that it only applied to 8.2, whatever. So he thanks Scott for the clarification.
And he tries to answer, "Addrex." He says, "It appears that the previous policy will pass and it will not be hard for small players to get into the transfer market."
Paul Andersen: Rear microphone.
David Huberman: David Huberman, Oracle. John Curran, if this policy were the only policy to move forward from this meeting and this text were in the NRPM and I ran a Canadian third‑party Internet access provider and I came to you and I said I needed a /x, you'd say — what criteria is RSD going to use to see that I'm at 50 percent? Are they going to use the TPIA criteria that are well elucidated in Section 4 today, or the criteria that don't exist in this policy?
John Curran: You're saying for purposes of a transfer? You come to ARIN and you say you're going to do a transfer and now there's no longer reference to the TPIA practice?
David Huberman: If I may, John, really the question is I strongly agree with Owen. Section 4 is big and it's complex, because it deals with a lot of different architectures that exist and are real. Yesterday and today.
This policy, I worry about it because it says in the problem statement that it wants to outline the criteria that should be used and that it even puts a Section 8.5, what are the criteria, and then there are none. It just says 50 percent.
So what's the staff going to use to judge that when it's not a simple flat architecture that is used versus not used, when it's TPIA, when it's other forms of cable, when it's anything else that's not standard.
John Curran: To answer the question, staff would use the new 8.5 specified transfer recipient requirements and would apply it to the best of its ability to the person's circumstance even if they would have prior had TPIA or had multiple discrete network or some other allocation policy. Instead, we would just be using 8.5.
David Huberman: The reason I said TPIA is the space is not in a traditional sense used. So —
John Curran: It's possible someone would be — it's possible someone would be declined depending on the nature of the request.
David Huberman: Thank you. That's an honest answer, and I appreciate that. Folks, this policy is not ready. It's a good — it's a really good framework, but if you ask the staff to do this over the others, and this is what comes out of this, this is more chaos. This is not simple.
I'm therefore opposed.
Paul Andersen: I have to correct you. The Canadian would come in say: I'd like to have a /x, eh. Like, come on, get it right.
Oh, come on. Everything's falling flat today? Geez.
Front microphone. It is a tough crowd.
Andrew Dul: Andrew Dul, CrowdStrike, ARIN AC. As author, I, of course, support this policy. While I understand the concerns that my colleagues have raised about issues that exist in the linkages between the old Section 4, I really believe that this is our best step forward to really simplify and make this marketplace more valuable and useful for all of our community members, including those that may have an issue with a specific element of the policy. There's no reason that if that is actually an issue we can go and fix that.
And this was the first time, I believe, this issue specifically has been brought up. Maybe I'm misremembering that all. But I really think that we need to take this step and not keep holding on to a whole bunch of rules that don't necessarily apply.
Maybe the TPIA rule is important. I also believe that there's enough latitude in the current language that I believe maybe staff — it's possible for staff to interpret it in a way that could actually be more favorable to certain organizations.
But I don't think we should stop moving forward just because we are afraid of change. And that would be my comment with regard to those. Thank you.
Paul Andersen: Thank you for that comment. Owen, the mics have closed.
Owen DeLong: I want to rebut something.
Paul Andersen: Can you rebut it right now so we don't have —
Owen DeLong: If I understood Andrew's last statement correctly, he said it's possible that this policy will disadvantage some and advantage others.
And he seems to think that's a good thing.
Andrew Dul: Anything we do has pluses and minuses to it. And what we're here doing is weighing all of the advantages and disadvantages of changes here.
So as Owen said, doing nothing has pluses and minuses — or Owen didn't say that. As one might say, doing nothing has pluses and minuses that might disadvantage certain groups or individuals. So we have to weigh all of those, not just the fact that there might be a smaller corner case.
Paul Andersen: I think the point's been made, gentlemen. Front microphone.
Scott Leibrand: Scott Leibrand, DLVR, ARIN AC. As co‑author of this, I looked specifically at the TPIA requirements, the MDN requirements, the everything else requirements in Section 4 and very specifically made sure that the new 8.5 thresholds, 50 percent, were more liberal or as liberal as anything in the current NRPM 4.
If someone who's got an actual need for using one of those policies can come forward and say "This would disadvantage me in this particular situation because I have a particular architecture that's not covered," then I might reconsider whether we accomplished that.
But the goal was this policy should be at least as liberal as the current policy for anyone doing a transfer. And to Andrew's point, if we missed any corner cases, those can and will be addressed later either by staff interpreting things sensibly or by us doing a new policy proposal.
But the idea was that there should not be any cases where anyone is restricted by the new policy proposal. And to Owen's earlier point about the Section 4, Section 8 linkages, our thinking here is by putting just these very simple criteria into Section 8 for IPv4 transfers, that it will make it possible to do the surgery on NRPM 4 that needs to be done because NRPM 4 will only apply to wait lists. And guess what? Nobody is getting any space off wait list that isn't already approved.
So I think this, as Andrew said, is the most sensible path forward to accomplishing the simplification we need to do of the NRPM. It's definitely not the last step.
Andrew and I had a draft of simplifying NRPM 4, and we decided it was actually really hard to do that while everything depended on it.
So by putting just what we need into Section 8.5, we're making it possible for the community to continue simplifying things in the future.
And I would hope that as I do that you would support this proposal.
Paul Andersen: Thank you. Quick response, succinct response.
John Curran: I want to be clear with respect to what this means for someone who might have been using Section 4 to justify a very large transfer.
You could be in circumstances right now under current policy where, because of third‑party Internet access or because of MDN and existing block allocations, you could justify a transfer of very large size.
Under the new guidelines, you wouldn't be able to use those, but you would be able to use the new 8.5.5, which are generous.
To be clear, you would still be able to do a transfer. You may just not be able to do one that is exceedingly generous by using the specialized policies in 4.
So I want to sort of respond because someone may think, oh, I won't be able to get addresses. No, you'll be able to qualify for something under the new policy if we use the criteria supplied in 8.5.
What you don't get is you don't get the advantage of the very specialized policy in 4 that may allow some very unusual and much larger transfer to occur. It's not as if you won't be able to get addresses at all.
Scott is correct in that the 8.5 criteria are fairly generous. They just aren't specialized by architecture.
Paul Andersen: Last two comments. If you could gentlemen be succinct as possible. Running short on time.
Kevin Blumberg: Kevin Blumberg. So I actually very specifically looked at TPIA. I was the original shepherd on it, I spent a lot of time on it. This policy benefits the TPA providers because of its generosity far more.
And my only question for staff, because I had actually asked this question, is: since there was run‑out, how many TPIA requests have come in? I believe it's a red herring, effectively.
John Curran: I'm not aware offhand. We'd have to count. By the way, you're asking it two different ways. How many TPIA requests have come in for assignment or for allocation, versus how many TPIA — how many times has the policy been used in Section 4 TPIA to justify a transfer?
I don't know. It's a very little used policy section. I think we might have produced stats on it, and I can look.
Kevin Blumberg: I'm effectively saying it's a red herring. Thank you.
Paul Andersen: Last comment.
Chris Woodfield: Chris Woodfield, Twitter, AC candidate. First a question. My reading of the 24‑month 50 percent plan requirements, comparing that to 2015‑7, which merely required an officer's attestation of 50 percent utilization, am I correct in understanding that the crucial difference between those two utilization requirements is the existing of a plan as opposed to simply the attestation?
John Curran: Compared to the Draft Policy proposal, the officer attestation doesn't require any plan and is sufficient in and of itself.
I'd have to compare the utilization level. Remember that that requirement is only for the end‑user assignment, it's not for ISPs which is a different number.
Chris Woodfield: The problem going last is everyone made your points for you already. I wanted that clarification made, thank you.
Paul Andersen: Not last. We'll sneak in remote participation.
Milton Mueller: From our surprise commenter, Jason Schiller of Google, and his comment: "Plus one on what Owen and Jason said. Opposed."
Paul Andersen: There you go. Jason, you have the last word, unless, Leif, you wanted to add something. You're good? Thank you to Leif, then, for the presentation. Let's thank him.
Paul Andersen: All right. The last poll of the day before social. Counters ready? Good. Excellent. Same question. On the matter of 2016‑5: Post‑IPv4-Free-Pool-Depletion Transfer Policy, all those in favor of the AC continuing to advance this proposal, please raise your hand one last time for today high.
Remote participants, please signal your intent accordingly.
John Curran: Please hold your hand up high if you're holding it up.
Paul Andersen: As high as you can.
John Curran: We have this in a ballroom so you will not hit the ceiling.
Paul Andersen: Thank you. You can lower them. And all those opposed to the policy, please raise your hand — one, Owen, one. One hand only, please.
We have one on stage in case you guys didn't look — thank you. You may lower while we wait for the tabulation. Just reminder that the AC are volunteers and they are going to spend tomorrow in person and many hours over the means trying to put all these proposals together.
So, please, find them at the social tonight. Shake their hand and buy them a drink. They need it. All right. The results are coming.
On the matter of 2016‑5: Post‑IPv4-Free-Pool-Depletion Transfer Policy, in the room 123. In favor, 33. Against, 6. Thank you very much. This input is being provided. And thank you for your participation today in the policy process.
Turn it over to John for whatever we have next. Open mic?
John Curran: Yes, we're getting towards the end of the day. And we have 30 minutes for Open Mic and closing announcements and we adjourn.
So Open Mic session is where we open the microphones for any topics that haven't been discussed, any additional questions.
Sometimes this can be five minutes long and sometimes it can be the main event. So I'm now going to open it up to open mic. This is people in here and remote participants who have a question that they might want to ask or discussion or raise a topic that hasn't come up. This microphone on the side first.
Peter Thimmesch: Peter Thimmesch, Addrex once again. One of the things we wanted to find out and wanted to know how the community felt with this is unfortunately we're now getting wind of a lot of the AC members are also working as, the better word, consultants, paid, whatever, for certain brokers and attorneys.
We kind of want to make sure that's something which either is vastly discouraged or it's required if you're an AC member that you have to disclose that you are also being paid by a broker or by a lawyer.
We as a process, Addrex, does not pay any outside consultants. We have our own attorneys. But we are hearing this quite a bit, and we are deeply disturbed that there could be — there is — several members of the AC who are being paid to be consultants outside their normal job.
John Curran: Can I ask a question for clarity? Your concern is that AC members are busy working on policy and the bio that they publish on the website may not be complete with respect to these consultings.
Peter Thimmesch: Correct.
John Curran: Okay. People who want to speak on that topic? If you want to speak on that topic, be at the mic; otherwise, take two steps back. Who do I have that wants to speak? I see Owen and R.S. Owen.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, and somebody who occasionally does consulting gigs for people looking to acquire addresses.
I have not done any consulting gigs where I've been paid by a broker except for one where the end customer of the broker for contractual and legal reasons of their own chose to pay me through the broker. And so the broker passed my fee billing through to the client directly without markup, but I was still effectively paid by the end client.
I have always been paid by the end client and not by the broker or attorney. And I don't believe that working for organizations that request address space on a consulting basis represents any sort of conflict of interest.
I have readily disclosed that whenever it's been asked of me. And I do not understand the concern.
John Curran: R.S. in the back.
Robert Seastrom: So I have provided pro bono advice to organizations that are trying to get their request for address space approved by ARIN. I've not accepted money for that except in the ordinary course of my employment.
I have personally held v4 and ASN Number Resources, which are part of my disclosure as potential conflicts of interest, and we have all made disclosures of potential conflicts of interest which I believe are minuted in our annual meeting, and you're welcome to avail yourself to those minutes if you like.
John Curran: Just for clarity, so all the AC members have a bio on the website, but also at the beginning of the year they look to each other and detail their activities.
And that's something that they do so that AC members know when they're in the room and they're discussing policy, whether there might be a potential for conflict of interest.
Now, some of that is confidential because some people don't — sometimes they have business dealings you can't publicly post. You're prohibited from doing so, but the AC members know they have to do a disclosure to each other at the beginning of each year in addition to their bio.
But if that's insufficient, that's something certainly worth talking about. And microphones remain open on this topic, anyone who wants to talk about AC disclosure.
Amy Potter: Hi, Amy Potter. I'm on the AC and a broker. And that is something I disclosed when I ran, and I think that's actually a big part of why plenty of members in this community voted for me to be on the AC. But in case anyone wasn't aware, I am a broker and I do get paid for selling IP addresses.
John Curran: Anyone else want to comment on this?
Chris Tacit: I'm here for a different reason, but I might as well because the lawyer in me can't resist on this. So I guess I don't see it that much differently than any other interest that an AC member might have with regards to their employment or contracting generally.
And the one thing I'd like to remind everybody is that when you're facilitating a transaction, it's about interpreting existing policy, not making new policy.
And the timeframe is usually very short. You're not going to be able, typically, even if you wanted to effect policy to try and facilitate a particular transaction within any reasonable timeframe.
Just to me it makes less sense to worry about that than other possible situations.
And as I said yesterday in the newcomer session, when we were talking about why the whole process works so well, at the end of the day it's the Board of Trustees that have to be concerned about the real conflict of interest as part of their fiduciary duty. That's where the buck really stops on that issue.
So those are just some remarks. I don't have an axe to grind one way or the other on this, but I just wanted to make those requirements. Steve you wanted to comment?
Steve Ryan: I'm Steve Ryan, General Counsel of the company since I think 2004. From the standpoint — I want to close the issue on the Board.
The Board does written disclosures. Those written disclosures exist on an annual basis and are changed every year, and they update them if their situation changes during the year. And it is correct what Mr. Tacit said that the Board has a financial and fiduciary obligation to the company that is different than AC members.
So, from the Board's perspective, there is, I think, more than full disclosure of any employment or compensation issues.
With regard to the AC, the situation is different. The AC is not in a fiduciary obligation standpoint. However, I wanted to just emphasize that in January of each year, each member does disclose their unique relationship to the community so their fellow AC members will understand that relationship.
So, for example, if you have a single employer, you explain your job at the single employer. I think actually Peter's point, though, is an important one. And I think it's worth thinking about whether spot assignments during the year are adequately addressed by that.
And I think we can evaluate that. I think it was helpful to bring it forward. And if anybody is ever concerned about the confidentiality of information in the AC, generally the AC is not exposed, generally, to confidential information.
There are times when they'll be briefed on an existing legal matter. Although, that hasn't happened for several years.
There is also a nondisclosure agreement that each Board — or, pardon me, that each AC member signs if they receive confidential information and it's emphasized as confidential information, they cannot share that without violating their nondisclosure agreement.
So we do have some — I wanted to just share the panoply of how we've addressed this, because I think we have good systems for this, but this is a new issue, and I'd like to think about it with the AC and with the Board, and I appreciate Peter bringing it forward.
Peter Thimmesch: If I may, we have absolutely no issues with the way the Board disclosure is. We've looked at it. We're actually very proud how you've done that job. So kudos to how that's worked out.
You're right, this is a new issue and something we're now getting — it's a feedback loop that we talk to people, and we wanted to bring that forward for everyone to discuss instead of just at the AC meetings. It should be brought forth here for people to discuss whether they would like to know more about how that is being built. That's our point.
John Curran: You were in queue, Vint.
Vint Cerf: I wanted to get some clarification. Is the issue simply a matter of transparency? Is that why this is brought up? Or is there, in fact, a concern, a specific concern about conflict of interest? I hadn't been able to figure out the nature of the conflict, and I wanted —
Peter Thimmesch: It's a combination of both, Dr. Cerf. We look at it first as a transparency issue because people should know. Amy Potter is very clear. She works for brokers. She's on the Advisory Council. People know how she works. It's not a question of transparency for her.
But we are getting, unfortunately, because we are very active, and there's probably 50 people in this room we work with, they will come to us and say, hey, I was at a party, I heard this. And it's kind of stunning to us that it's not something that was added to the list.
But that's right. Steve Ryan is correct. This is new. And so there is the potential, though, for a conflict because they are now shepherding or stewarding certain things that may actually either help or further their own just area.
So we do kind of — policies make big differences in how well a transaction goes through. Or, in a weird way, it can actually make it so it makes the bar much higher and keeps them so they're still a cottage industry.
So we are concerned about the conflict of interest as much as transparency.
Vint Cerf: John, may I continue?
John Curran: Sure.
Vint Cerf: Let me try to summarize. You're saying essentially that a party who is providing advice, paid or not, might use the Policy Development Process in order to influence the force of a transaction or future transaction, and specifically that is the nature of the conflict that you're trying to expose; is that correct?
Peter Thimmesch: That is correct.
Vint Cerf: Okay. Thank you.
John Curran: We'll definitely take that with counsel and the Board as well. Milton has been waiting?
Cathy Aronson: I'm sorry. Cathy Aronson. The reason I was originally on the AC a really long time ago was because I needed policy for my company.
I mean, everybody knew where I worked. But the whole industry that I worked for needed policy. And I worked on that. And we got consensus. And we made it policy.
So I didn't think that was against the rules. So is it just that maybe nobody knows that they're doing whatever they're doing and then they're getting policy for that? Because I was clearly on the AC for a long time to help the cable industry have a decent policy where they could get address space and succeed in business.
John Curran: The question would be if you're on the AC and helping get policy that allows satellite companies to get address space and you didn't tell anyone you were consulting for a satellite company.
I don't think it's a question when we all know everyone's relationships. It's some people may have dynamic relationships that have started up where they're consulting for an entity. And if they're also working on a policy, that's germane for everyone to know. Their advocacy may not be entirely based on what they hear in the community.
Milton Mueller: I think one of the things I've heard is not so much that, "oh, you're working for a cable company or this company and you're shaping the policy in a way that favors them."
What I have heard — and this is not something coming from me, it's coming from third parties who have asked me about this — is like why do certain people seem to continue to support certain intricate needs‑based policies when the rationale for them has gone away?
And the speculation, and I'll call it that, that fills the gap is maybe they're like these complicated, arcane policies because they're helping people get through it and they're consulting.
I have no direct evidence that that's true. It could be. It may not be. But I have heard people speculate about that and it's directed at AC members, not at Board members.
John Curran: To the extent that someone has a business in advising people on policy process, then that's probably something that's important for people to know because the nature of the policy process itself is germane to their business.
Milton Mueller: It's not really the policy process, it's the fact that they're not simplifying the policy. The assertion is they're not simplifying it and streamlining the policies because they benefit from it being complicated.
John Curran: Right. But I was not thinking about whether it was complicated or simple but just the idea that they're in the business of facilitating it. If people know that, then they understand, indirectly, complexity improves the volume of business.
Okay. So obviously someone who is advising people on how to go through and make requests under policy, that's a business segment that is important to know someone's employed in, one way or the other.
Chris Tacit: I'll just add a comment on that and then see if that's it for that topic.
It seems to me that if the NDA requirements are observed by AC members and there's sufficient disclosure, we can't really do much more than that; otherwise, there wouldn't be an AC because everybody has a master of some sort, whether it's a consulting company or whether it's an employer.
And at the end of the day, everybody on the AC has some interest in helping to advance those interests in terms of policy development.
But the group as a whole is still trying to work for the benefit of the community. And there's balance because of we do take into account the community's interest and because there are 15 of us who come and go at different times during the three‑year cycle.
John Curran: It's entirely a question of completeness of disclosure.
Chris Tacit: Because otherwise there would be no AC. Everybody would be conflicted.
John Curran: We'd all be conflicted out. It would be an empty room. But very quick meetings.
Yes. On this topic.
Kevin Blumberg: Kevin Blumberg, two things. I'll look forward to whatever the review shows, but I think, quite frankly, you're doing a great job and the AC is doing a great job.
What I would say is this: if you look through the history of the meeting minutes, the number of people on the AC that have abstained for conflict or even for the perception of conflict, I'm in tangentially this industry, I don't feel comfortable voting. I have absolute respect for the colleagues I was with on the AC for those years. And any disclosure is good disclosure, but I have a lot of respect for all of those people.
Paul Andersen: It's important to say, on behalf of the Board, the Board takes conflict of interest very seriously. We've kind of noted our procedures, and John has instilled I know in the staff the importance of that.
And the AC has been doing their process for some time. My experience is they do take it quite seriously and all that.
Having said that, counsel has noted that there's an issue here that might be worth noodling on, because if there's improvements to be made, there is. I really thank the issue, and we will — once counsel reports back, the Board will advise.
I just wanted to thank that, for bringing attention.
John Curran: Ready for the next topic? Center front.
Chris Tacit: I wanted to pick up on a comment I made during the discussion of one of the policies earlier. Because I don't know about other AC members, but I need this help and guidance from the community to help me sort out the policies we discussed today that were overlapping.
And the questions I'd like to ask are this: when it comes to the tests for transfer, does it matter what the size of the block is in terms of how stringent the test should be?
And, two, when it comes to the evidentiary requirements required to support whatever the test is, does it matter what size the block is?
And the reason I ask this is because I've noticed the tendency, which I mentioned earlier, for us to look at these things in a rather black and white, some people completely opposed or completely support.
But I don't know if people have thought about nuancing this and saying, well, if you're getting a /24, maybe the test should be light or maybe the evidence should be less than if you're getting a /16 or whatever.
So I don't know what the answer to that question is, and I don't know whether the community wants to go down that path at all. But I'd certainly like to hear what people have to say about it.
Because if it's more of a continuum than an either/or, then the AC has some work to do in finding the sweet spots for that.
John Curran: People want to respond to that topic, whether or not the criteria or evidentiary requirement should vary based on the size of the block. Center front.
Owen DeLong: Owen DeLong, Akamai, ARIN AC. I do think that it should vary somewhat with the size of the block. I think that we can be a lot less cautious about /24s and maybe even up to /16s than we want to be with, say, /12s and /10s and larger blocks, if there are such things.
So that's one of the reasons that I supported the policies that I supported, which had a more nuanced view and oppose the policies that were more absolute.
John Curran: Got it. On this topic, center rear mic.
Kevin Blumberg: So I really don't want to talk about existing policy, because I think we had time to talk about existing policy. I do want to confirm that when it comes to the needs test as a whole, that is not in policy. That is ARIN staff deciding and making sure that they follow initial set of guidelines.
But if they feel they want more information, because there's something wiggy going on, they will ask for it. And that is for staff to deal with.
We say need. You do the rest.
John Curran: There's a criteria that's specified in policy. We ask for evidence of that, of meeting that criteria.
There are some times that we will put a credence level on the evidence you give us and we will ask for more evidence. And that can go on repeatedly. It is not common. And a lot of people, particularly new organizations that have no record, that have interesting documentation that seems to have fallen out of a Perl script, may disappear the third or fourth time we ask for more detailed information.
It's very hard to — it's easy to fabricate; it's hard to answer the follow‑up questions from fabrication.
Kevin Blumberg: I don't know how to say please make a lighter touch, because at the end of the day, it's the staff's judgment. Thank you.
John Curran: On this topic, any other responses?
Isaac Levy: On this topic, I had a question for everybody about actually how much scrutiny there is in the smaller blocks, like the /24s, /22s.
After managing a number of those blocks in various organizations, I see that as some of the worst stewardship. I say that after working through cleaning up and trying to become a better steward of these things in those organizations. But it's an overwhelming problem for ARIN just because of the sheer number of blocks.
So how much attention does everybody actually want to pay to this particular problem as opposed to moving forward for v6?
John Curran: There's two questions there. The question is what's present policy and what do people want. Present policy doesn't distinguish between that /24 and that /20 and that /18 when we're busy doing our validation. We're still looking to make sure the source is valid and we're still making sure that the recipient has documented need, and we're not applying a different level of evidence unless what we were given is somehow questionable. We can do that, but that would need to come from this community about at least what thresholds, give us some ranges in which we should relax evidentiary criteria.
Isaac Levy: With, I guess, the expense of diving deeper into this problem, is there actually a desire from ARIN to do so as a group?
John Curran: I want to be very clear. You need to distinguish very carefully if you're going to have us relax the approach, whether you're referring to needs assessment or whether you're referring to source validation. Because in the case of source validation, we're trying to confirm whether that's the actual party that was assigned the resources. And if we get it wrong, there's a harmed party out there. So let's be really clear.
Isaac Levy: Understood.
Vint Cerf: It feels to me like this is largely a risk mitigation issue. And what John just said about potential hazard of a person showing up who is making source information, that's a pretty serious problem.
On the other hand, let's suppose for the sake of argument that small allocations didn't get as much scrutiny as larger ones. This is similar to what happens in some credit card transactions, where anything below a certain amount doesn't require a signature or other thing.
I'm not advocating one way or the other, but I would like to suggest if you reduce the level of scrutiny with regard to meeting criteria for receiving a transfer, would you end up with a run of large numbers of small things because they didn't get looked at as carefully, and what would that do to the staff?
So this is a nontrivial question. It's not a simple one.
John Curran: Remote participant, Milton.
Milton Mueller: Yes, it's a different topic.
John Curran: Oh, let's hold on it. Keep it.
On this topic, center front.
Patrick Gilmore: Patrick Gilmore, Markley Group, Board candidate, but speaking for myself. As a member, just to answer Christian's question, I actually would support the idea of doing something different for small blocks and big blocks. I totally recognize everything that's gone before about — Dr. Cerf mentioning a run on small blocks and other reasons why this may or may not be a good idea, but he asked if the community would support it. And I'm a member of the community, so I'm saying that if the AC came up with a plan like that, I would probably support it. I'd obviously have to see the actual policy before I could say for sure.
But I have no problem with small blocks, for instance, /24s, having essentially no validation or something like that. Other than you can't have two in the same Org or something.
So hope that answers your question.
John Curran: On this topic.
David Huberman: David Huberman, Oracle. How handy of a conversation, because tomorrow we have a fourth policy in this vein to discuss. We only got through three of them today.
That fourth one tomorrow is exactly this. It's a very simple policy that says if you are requesting less than a /16, you can — excuse me, if you're requesting to transfer into your account a /16 or less, you can get up to double the amount of space you have with no needs tests.
And we'll show statistics tomorrow on how much that — the utility of that and how relevant that is. So stick around for tomorrow because that policy is on the docket.
John Curran: 2016‑3. Okay.
Rear microphone, same topic? New topic. We'll go to remote, then. New topic.
Milton Mueller: This is from Kevin Otte, O‑t‑t‑e: "At NANOG I noted there were two presentations on IPv4 transfer markets. At this meeting we've had four policy proposals surrounding that market.
"We know that IPv6 is the way forward, and yet there has been little talk this week about actually making that happen. ARIN has a great campaign in the form of Get6, but there seems to be a disconnect between that and the policy discussions here.
"Is there something we can do to make IPv6 a more attractive option to those who might feel they need to approach the market?"
John Curran: I'll take people who want to respond to that. I'm going to take the opportunity myself first and say: Note that policy discussions in ARIN are not an indication of level of interest. They're an indication of fixing something that may not be working well.
The absence of IPv6 policy discussions may indicate really good policy. Okay. Anyone else want to respond? Go ahead. On IPv6? Yes, go ahead.
Izumi Okutani: Izumi Okutani with the hat of IPv6 coordinator within IGF for the best practices. Excellent question. And I also agree with John's observation that this is a good sign that in terms of number resources, we're actually not facing issues.
But if you want to contribute, there's a place that you can actually share your business cases. We're actually working this year in Internet Governance Forum on documenting what are the business incentives and what are the successful cases on IPv6 targeting policy makers and business decision‑makers which hopefully would actually make a difference in moving things forward, not just on a technical level.
And we really would like to hear more cases from North American region. For example, companies such as Google, Yahoo!, LinkedIn, Apple. We really haven't really heard from those companies. So we really would appreciate your contribution.
And we're actually planning to publish a draft document. So your input, again, would be appreciated. Actually handing out stickers on this forum. So if you can go to ARIN's desk, you can collect more information. Thank you so much.
John Curran: On the IPv6 topic.
Owen DeLong: Owen DeLong, Akamai, ARIN AC, and, as some of you may have known, I was once an IPv6 evangelist for a few years. I'm still relatively active in trying to evangelize IPv6 and trying to get people onto IPv6, including parts of my own company.
Having said that, I think that the lack of v6 policy discussions really is a sign that we've made the v6 policy as simple and attractive as we possibly can and that people are generally happy with it.
We had little trouble at Akamai getting our v6 /24 squared away. And the existing policy was quite useful and we were able to get what we needed, and we think that will serve us for at least a couple of years and we're in good shape.
So I don't think that we should conflate how much v6 policy discussion there is with the level of interest in v6 or the amount of push for v6 that ARIN is engaged in.
I also think we need to be careful, as much as I'm a huge fan of v6 and die, v4, die, please, I think that ARIN doesn't have a role to evangelize the death of v4.
I think ARIN as a registry needs to remain protocol neutral in the policies and in their actions and that while they've done a great job of pushing the industry towards v6 in the interests of the industry, that going any further than gentle encouragement departs from ARIN's mission statement in a non‑trivial and harmful way.
So I think we're in the right place.
John Curran: Thank you. v6?
Scott Morizot: Yes. Scott Morizot, IRS. Way back in the dark ages of v6, when we got our allocation, we actually encountered quite a few policy‑based issues that we had to work through. It's my perception that at this point in time those problems have been addressed in policy.
John Curran: Excellent. Rear microphone on v6.
Kevin Blumberg: Two quick things. Kevin Blumberg. The first is that penalty, penalizing people, is a really bad idea. And I know over the years we've talked about reclaiming v4 to try to extend it along. We've talked about penalizing in v4 because v6 is the way to go.
That is not good. That hurts small players and it hurts our image. Penalizing is never a way to get things adopted. You support them both. You really make it as easy as possible, which is I think what is going on with v6.
And the only concern I have that we've seen in the last I would say two years is where people who got space originally had some sizing issues, and I believe as a community we resolved those.
John Curran: Okay. On v6, any other speakers? I'm going to move to new topics. Center front.
Dani Roisman: New topic, but I'll use that last question as a perfect segue. So as we know, ARIN runout occurred a little over a year ago. I think what we're seeing right now is people have tried to squeeze, stretch and economize as much as possible, and over the past year more and more players have pretty much exhausted every last resource of v4 as they had, which is why there's so much activity happening in the transfer market and so many new people are talking about it that, even as recently as a year ago, had no interest and never imagined they would enter the transfer market.
That being said, we consider that by the fact that we have four very similar proposals to talk about this week that all have to do with the transfer market.
And thanks to Amy's wonderful, handy reference guide, I did some research. What I was trying to learn, how all these talks relate to each other, what's the nexus of talk A versus talk B.
I looked at the original authors, and I found it really interesting. I don't want to necessarily name anybody, even though it's a compliment. I, first of all, wanted to give appreciation for of the four people that worked on these policies, three are active AC members.
So thank you so much to the three that were involved for your diligence and your hard work on these. So that's a compliment. Thank you for working on these.
But I also found it a little troubling that as a community there was one non‑AC member who worked on one of these, and there was nothing else being proposed by the large holders, by the brokers, by the large sellers.
This really is a hot topic, and I do encourage people — I myself have made a proposal last year. I encourage people that actually are affected by this to speak up.
I found the ARIN AC members very approachable. The shepherds were extremely helpful. I had no idea how to write a policy. And I think if you have a proposal and it's not being met, I encourage people to not sit back and let the AC do the job of what I think the community is.
I think they're filling a gap because they're very involved and very present and very knowledgeable, but anybody in this room that has a strong opinion about how things should be, how we should be charting this course, should speak up.
If you don't know how, find an AC member. They're wonderful people. Very helpful, very approachable. And make your voices heard.
I don't think it's right that the AC plus one very active individual are the only people that are contributing.
I think we all deserve — the community deserves a lot more from us as individuals.
John Curran: Excellent point. You want to respond to that?
Cathy Aronson: I do.
John Curran: Go ahead.
Cathy Aronson: I can't speak to all of the details of these, but a lot of times the AC gets input from the community and then creates a proposal on their behalf. So some of the input to these policies that exist come from the community. So that is a thing that does happen.
John Curran: There are contributors out there who may not be the ones to take a lead on a proposal but have been instigators or suggesters, and that is worth noting.
Okay. I'm actually going to close the queue because we're running out of time.
So last one is rear microphone. Go ahead.
Kevin Blumberg: Kevin Blumberg. And this is not about policy.
WhoWas, we had a great set of talks yesterday at NANOG, and what came out of it was that some of the buyers were seeing major levels of fraud.
When you say 30 percent in a presentation, gave some really good examples of things to avoid and things to do. Use Whois and look up the block. Go to RIPE and get a history of the routing table.
But nobody brought up WhoWas during the presentation. Because if you actually look at the use case for WhoWas, you can't really use it as a buyer to start looking at potential blocks that you've been told you can bid on, as an example.
It's not explicitly stated, and there's some very explicit statements in there. I checked with staff earlier today, and they said, no, you really can't — you have to follow one of the very specific things. And I would strongly suggest, especially as this market grows and the fraud incident cases increase, that giving that phenomenal tool of the entire history of a block to the buyers, allowing sellers maybe to have a cryptographically signed PDF as of this date, or whatever it may be, but expanding on the Whois service to allow for the market to use it.
You can, once you've been approved to the WhoWas service, you can go back and pull the history of any block you want. They're all available.
Kevin Blumberg: It's Term of Use —
Kevin Blumberg: Thank you.
Public Policy Meeting, Day 1 - Closing Announcements and Adjournment
John Curran: Okay. That was the final question. We will have another open mic tomorrow. But right now I want to move ahead because I'm the only thing between you and the social, actually.
First, vote. If you have not voted, the elections are open. So go into ARIN Online and find your voting link, and off you go.
If you have any questions, the Election Help Desk is open in the foyer each day. Or you can drop a question to firstname.lastname@example.org.
I'd like to thank our sponsors, network and webcast sponsors, AT&T and Google.
John Curran: Okay. Tonight's social at the Perot Museum. We'll have buses leave at 6:45, 7:00, and 7:15, off the Ross Avenue entrance. Need to be there 10 minutes before the bus leaves. They're going to return starting at 8:30. The last one is at 11:00 PM. Please wear social or regular name badge to get in.
Don't forget the meeting survey. We now have the surveys underway. So you can access it there. You'll get an email if you're registered for the meeting. It's also on that link. R/ARIN 38 survey on Survey Monkey. If we get your response by the 28th of October, you will be entered into a lottery to win an Apple iPad Air 2.
Reminders. Breakfast is tomorrow at 8:00 AM. Same place as always. The meeting will start here at 9:00. We'll have lunch noon to 1:00, and then the Members Meeting is in the afternoon when we do the reports of the departments. And that's going to be 1:00 to 3:00. All your meeting materials are online.
And I look forward to seeing everyone here at the social or tomorrow. That's it. Thank you, everyone.
(Meeting adjourned at 5:00 PM)