Table of Contents
- Public Policy Meeting, Day 1 - Opening Announcements
- Internet Number Resource Status Report
- IETF Report
- Adopted IPv4 Waitlist Policy Recommendation
- Recommended Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 188.8.131.52.1
- Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
- Policy Implementation and Experience Report
- Recommended Draft Policy ARIN-2019-3: Update 4.10 – IPv6 Deployment Block
- History (and Future) of IPv6 Outreach at ARIN
- Election Overview
- Advisory Council, Board of Trustees, and NRO NC Candidate Speeches
- Board Candidate Forum
- Recommended Draft Policy ARIN-2019-8: Clarification of Section 4.10 for Multiple Discrete Networks
- Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A
- Recommended Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended
- Draft Policy ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool
- Public Policy Meeting, Day 1 - Open Microphone
- Public Policy Meeting, Day 1 - Closing Announcements and Adjournment
Public Policy Meeting, Day 1 - Opening Announcements
John Curran: Good morning. If people will come in and get seated, we'll get started. Welcome, everyone, to Austin. I'm John Curran, President and CEO of ARIN. Very happy to have everyone here this morning.
Some of you are enjoying your additional days in Austin. Some of you are here for the first time. Some of you are in the rapture of a Nats victory last night.
For those of you who follow baseball, the Nationals pulled off the World Series. Being outside in Chantilly, Virginia, ARIN has a few Nationals fans on the staff. The old Expos, yes. No, Nationals.
So, let's see. I want to make a couple of brief announcements, talk about what we're going to do today, and then we'll dive right in.
So, first, we have a number of folks in attendance today. We have our Board of Trustees. I'm not quite sure -- let's see, so Paul Andersen is not here, but the rest of the Board, I believe, is pretty much here. So we have Dan Alexander. Dan, where are you? A Board of Trustee member over there.
Paul Andersen, who could not be here today. Nancy Carter, who is on her way in. Myself, John Curran. Regenie Fräser, you're somewhere here hiding. Patrick, we just saw over there. Peter Harrison -- where's Peter? Stepped out.
And Bill Sandiford is our vice chair. Bill will actually be acting as the Chair of the meeting, so when we get to questions and polls of support, Bill will be handling that.
We have the Advisory Council. AC members, raise your hand. This is the elected body that actually does all the work. They're the ones that work on the policy proposals. They're the ones -- there's usually a couple of AC members who guide and shape the discussion of any given Policy Proposal.
And we have the Vice Chairs up here, or the Chair and Vice Chair -- Tina Morris, the Chair; and Leif Sawyer, the Vice Chair -- up at the head table.
We have our NRO Number Council. Our NRO Number Council folks, raise your hand. Yes. Okay, Kevin Blumberg, Louie Lee, and -- I don't know if Jason could be here, probably not -- are the NRO Number Council.
And the Number Council is responsible -- three from each of the five regions, 15 people total -- when we do a global policy, a policy for the allocation of number blocks from the IANA to the RIRs, it's the Number Council that coordinates and helps drive that process.
We have a number of the folks from the RIRs here. Raise your hand if you're from another RIR. The other RIRs come here. AFRINIC, APNIC, LACNIC, and RIPE have folks here.
And that's because, even though we have policy in the ARIN region, it's one registry. We have to have one global unique registry. What we do in the ARIN region affects other regions, and vice versa. Happy to have our RIPE colleagues here.
Now, management team. The management team of ARIN is here. I'm not going to go through it at length, but we're here. We come to the meetings. We listen to you. We help shape how we run the organization.
We also have our Fellows here. ARIN has a Fellowship Program to help get people involved in the process. So, from Canada we have Bram Abramson. Bram, are you here? Raise your hand. And his mentor is Chris. Each fellow has a mentor associated with them to help introduce them to the ARIN policy process.
From the Caribbean, Marcia Brandon and Betty Fausta. I just saw -- good to have you here, Marcia and Betty, from the Caribbean part of the ARIN region. Also Daniel and Lendon -- Daniel, Lendon, yes -- also from the Caribbean.
In the US, Scott Johnson, John Olson, and Joseph White. Fellows from the US section, from SolarNetOne, Webhiway, and Blue Cross/Blue Shield. This helps bring people into the policy process.
Even though what we do is not very contentious, it's good to have insights from as many people as possible involved. A lot of people don't worry about this. They leave it to you to do the address policy, but we always want to have a fresh stream of voices coming into the policy process.
So I'd like to welcome our newcomers, a number of newcomers -- what's the number of newcomers from yesterday? Can someone on the staff give it to us?
Susan Hamlin: Let's go with 62.
John Curran: 62, wonderful. They got to meet the staff and learn about ARIN. We're going to give out a gift card for the people who did the surveys. We have a survey for how we improve the introduction.
So we have a bunch of surveys. We're going to choose one at random and give that survey participant a gift card. I need someone to come up -- someone at random. Owen DeLong, come on up here. I have a random number generator for this purpose which is somewhat broken.
Very good. Thank you, sir. Okay. The newcomer who filled out their survey, John Olson. John, you'll receive a gift card. We'll give it to you afterwards. Thank you for filling these out.
We make sure we get feedback from the newcomers introduction because that way we get -- we can always improve it. It's a good way to make sure we do a useful introduction to how we get things done.
So moving right ahead, we have remote participants. So it looks like a relatively small room, but you have to also remember at any given time ARIN has remote participants participating in this process. So the process is webcast. They can actually hear the whole thing as it's going on.
There's a live transcript going on. Now, because there's a live transcript, when you're speaking, speak clearly, enunciate your words. Speak slower than I do.
I'm from Boston, and so for that regard I'm usually talking too fast for them. But please try to speak clearly so the transcript can be accurate.
We have all the meeting materials online. They're all available. You can download them, the same materials we give in the meeting that remote participants have. And there's a chat room which we use for questions from the mic and also for show of support.
Emergency resources. Hope not to have an emergency. If there is, "0" on the nearest phone. There's a care center right around the corner, a pharmacy right around the corner.
Okay, wireless SSID. Yeah, you should be able to find it. It's NANOG-ARIN. We do this coordinated when we do our coordinated meeting. Login information, NANOG NANOG, pretty hard. And there's also a non-secure legacy network if you want to use that.
Attendance. 10 attendees from Canada, 101 from the United States, 44 remote participants, 30 from outside the region. Five from the Caribbean.
I'd like to thank our sponsors. Round of applause for our sponsors.
So the Network Sponsor provides the connectivity that makes everything work. The Webcast Sponsor, Google -- Network Sponsor is AT&T -- the Webcast Sponsor, Google, helps us make sure that we can put the video online and do the real-time webcast.
And finally, the Meeting Sponsor is Addrex. They help underwrite the cost of the meeting. Big round of applause for our sponsors one more time.
Okay, Help Desk. Our Registration Services Department runs a Help Desk in the foyer. If you have a process you put in or you have a question about getting resources, they're out there.
We also have an Election Help Desk. Every year in September, or in October, we kick off an election for new AC members, new Board members, NRO NC. If you have questions about how to cast your ballot, who is the contact for your organization, the Help Desk is out there.
We have a User Testing Desk. If you tend to use ARIN Online a bit and you want to understand where we're going with it and possible upcoming interface changes, you can test drive it.
So go on out there, we have a User Interface Testing Desk, put on your high-speed goggles and get strapped in, and see what's coming up with ARIN Online. We take feedback from that process and use it to shape the upcoming releases.
Okay. Turn in your ticket during today's break and you'll get your ARIN t-shirt for ARIN 44.
Download the meeting app. We actually have the agenda, the speakers, the materials all online. There's a meeting app for ARIN, and you can download it from the App Store or Google Play.
So, rules and reminders. While this is a meeting, it's also part of a process. It's governed by our Policy Development Process. The Chair -- or, in this case, the Vice Chair -- will moderate the discussions when we talk about policy. So, when you come up to the microphone, he'll be the one recognizing you.
Make sure you identify yourself at the microphone so that everyone knows your affiliation. It's important. People deserve to know if you're speaking, who you're speaking on behalf of.
And there's courtesies in the program, a set of rules and reminders about how to have a polite, engaged discussion. We welcome input from absolutely everyone. We expect it to be courteous input. We expect people to focus on the subject matter and talk about the pros and cons and not make issues personal. We're all here to get a job done. So let's all be courteous to one another in advancing the policy.
There are Standards of Behavior that are in your discussion guide and online. They apply to this meeting. They apply to our online Mailing Lists.
If you don't feel that people are being courteous, if you feel that you're in an environment where you don't feel safe, please get ahold of myself, get ahold of a member of the ARIN Board or ARIN Council. All are available to you to avail yourself if you think there's a concern about the conduct of the meeting, your safety, or you feel that you're being treated in a way that's not representative of your rights.
So with that, I'm going to talk about the agenda this morning. So we have an Internet Number Resource Status Report, talking about the pool of IP addresses and where they are.
The Policy Implementation and Experience Report. We pull a policy or two each meeting and give feedback as to how it got implemented at ARIN, any issues or concerns that the community might want to think about. It's your policy. We just implement it. But we want to give you feedback now and then.
We have the IETF Report. ARIN has an IETF Reporter, someone we actually coordinate with and make sure that they have the travel support they need so they can go to IETF and give a high-level summary to this community. This is often a whirlwind of information. And we have that report this morning. It can be very informative. That will be good.
We're going to handle a number of policies. So we're going to handle -- we're going to report on the IPv4 Waitlist Policy. This is a policy that the Board suspended, and the AC made a recommendation on. And we resume the policy under the update from the AC. So we'll be talking about that.
We have a number of Recommended Draft Policies coming up. We have one on clarifying reassignment requirements in Section 184.108.40.206.1, and we have a Recommended Policy on clarifying IPv4 Request Requirements. Both of these are Recommended Drafts.
Because they're Recommended Drafts, it is possible that the Advisory Council will, after this meeting, recommend them for adoption and that the Board will actually take that recommendation, ratify it, and those policies will be incorporated in the policy manual.
When you see RDP, or Recommended Draft Policy, pay particular attention; it may be the last time you see this policy at a meeting before it actually is in effect. So, very important to think about.
Then we're going to handle -- after our break -- we're going to talk a little bit about IPv6 advocacy, talk about what ARIN has been doing just to make sure we all know what we've been doing to help promote v6, talk about what we might do going forward. And then we're going to do a discussion of another policy, which is the IPv6 deployment block.
So it's going to be a very busy time. We have a software development update as well to put in there.
Tonight we have a social. It's a little different. Tonight we have a social -- it's walking distance -- it's at Maggie Mae's. It's a very cool place, guitars, live music, food. Should be wonderful.
Tonight's Halloween, so if you happen to think about it, and you have some time today or you happened to slip something in your packed bag, costumes are encouraged. Bring your costume. We'll give prizes for most creative costumes and something interesting. Wear your social name badge so you can get in. It's a function just for the ARIN meeting.
So, with that, I'm going to -- we've already introduced the head table. I'm going to try again. Bill Sandiford, our Vice Chair; Tina, Chair of the AC; Leif, Vice Chair of the AC. Might be the second time I've gotten it right.
Let's start. First person I'll have up is John Sweeting. He'll be giving the Internet Number Status Report and the Policy Implementation and Experience Report.
Internet Number Resource Status Report
John Sweeting: All right. Good morning, everyone. Welcome to this ARIN meeting here in Austin. And, yeah, congratulations to all the Nat fans, of which I'm a secondary Nat fan. Of course, everyone knows my true allegiance is to the Yankees.
But a cool fact about it. The winning pitcher last night was from Central New York, just outside my hometown. He's from Cicero, North Syracuse. Patrick Corbin. So that's a cool thing.
We're going to go right into the Internet Number Resource Status Report. This is a report prepared by all five RIRs together out of the Registration Services Departments.
So this is a slide that you get to see every meeting, at every RIR meeting, and it's just basically a distribution of the 256 /8s that IANA held or distributed and may still hold some of them, the reserves.
You can see APNIC with 45 there. Paul Wilson, a little shoutout to you. How are you doing?
And then Central Registry has 92. ARIN, of course, has 36.
Okay, so at one point, somebody sent a suggestion to the RSCG saying, hey, we know we see -- you show this number of how the /8s were given out by IANA and the status of them, but you don't show where they are today. So we added this slide which shows the total IPv4 addresses managed by each RIR in terms of /8s.
As you can see, ARIN has 99.87, of which half of those are still legacy, not under agreement. And the other half is under agreement. And as you saw, there was 36 that were actually given straight from IANA to ARIN. So the other ones are /8s that were given out directly to organizations that ARIN has been tasked to manage.
This is the available IPv4 space in each RIR today, and by "available" it means space they actually have on hand to give out. You'll see that ARIN says 0.0, but yet you're seeing ARIN give out IPv4 space. Not frequently, but about once every quarter.
That space is space that has been revoked, returned, or was in some other status that we have since resolved and are able to distribute through the waitlist.
This is IPv4 space issued by the RIRs per year. As you can see, it is dwindling way down to where it's very hard to see it on the graphs. We expect that to continue until there's none to be reported. Some day, we hope.
Okay, that's it on the IPv4 space. So now we'll go into the IPv4 transfers, and this does not include M&A transfers from any of the RIRs.
This is the intra-RIR. So this is both sides -- source and recipient are both within the same RIR region. And this is the number of transfers per year. You can see that RIPE has a lot of transfers going on within their region. ARIN has quite a bit. APNIC has some. And as you see, AFRINIC and LACNIC have a few, too.
They started their approval, and doing transfers came a few years after the other RIRs. But they -- today all RIRs do intra-IPv4 transfers.
This is the same thing but by number of addresses transferred each year. As you can see, it doesn't necessarily equate that the number of transfers equals the number of resources that are transferred, as ARIN transfers a lot of addresses, but RIPE actually had the most per transfer by just the transfer itself. A lot of that is a lot of the legacy /16s that get transferred around throughout the region.
This is the inter-RIR transfers. So today ARIN, APNIC, and RIPE are the only three RIRs participating. However, LACNIC has passed their policy, and they're in the process of implementing it. And we expect sometime in the summer of 2020, maybe around June, that they will start doing inter-RIR transfers.
I think at that time we'll probably change this chart because the arrows will just get crazy if we throw LACNIC in there. But you can see, again, this is the number. And here, actually, ARIN has more numbers. We have a lot going out to RIPE, a lot going out to APNIC.
We'll get into -- this is going to be the number of addresses. And as you can see, it's a little unbalanced, but you would expect that. Remember, I showed you the /8s managed by the different RIRs. And I've told you that ARIN has, like, 50 legacy /8 space. A lot of that is right here, getting transferred on the inter-RIR market.
As you can see, we have sent almost 10 million out to RIPE and 17.8 million out to APNIC. And we've gotten half a million from RIPE and a little bit from APNIC, a little bit; they send us some our way to keep us happy. Not really, we don't care.
It's really interesting. Between APNIC and RIPE, it's pretty balanced. But neither one of them have that huge pool of legacy space that's sitting out there. That's it on transfers.
Now we'll go into the IPv6 space. This is just basically a representation of how much has been allocated to the RIRs. You can see that there was some space allocated to the RIRs before October 2006 when, I believe, the current global policy for how IANA hands out IPv6 space to the RIRs went into effect.
That policy basically says that each RIR gets a /12 every time they have to go back and ask for space. At this time no RIR has gone back and asked for another /12. Although there are a few, I understand RIPE's getting very close, and we're also getting very close -- and, Paul, are you guys getting -- no, not yet.
So, this basically shows how many prefixes each RIR allocates per year. It's basically the same chart we showed how many IPv4s, but you saw IPv4 was dwindling. IPv6 is actually -- it's not really growing hugely, but it's steady and it's growing somewhat.
And this is the total allocated IPv6 space measured in /32s from each RIR allocated out. No surprises there. RIPE has -- it leads the pack, APNIC in there, and ARIN in the middle.
Let's see. So this is the assignments. So this is to the end users. Again, it grew and it's pretty steady. And here you'll see, you'll notice LACNIC has given out quite a bit of /48 equivalent space, assigned it. That's because I believe they had a policy where every single customer or organization within LACNIC was given an IPv6 block. That's basically why they lead the pack on that.
I think in RIPE it has something to do with the way they have their LIRs and all that that they allocate a lot more space than they use for ends, than they give to end users. And I belive maybe APNIC is the same way because the -- you don't give a lot of space to end users, Paul, to assignments? ARIN does. We have a pretty good balance between end users and ISPs -- or allocations.
Okay, this is the slide that makes me dizzy, the lines there. So this is just members that were -- I don't know, I guess you call it the lines are IPv6-only members. And then the solid is members with IPv4 and IPv6. And just want to say on this that the RIRs, the term "member" does not mean the same thing.
AS numbers, again, this is a representation of how it's allocated out of the IANA pool. ARIN and RIPE had quite a bit of 16-bit ASNs, then APNIC, and then of course LACNIC and AFRINIC had very few.
This is ASNs that each RIR issued per year. The lines are 32-bit and the solids are 16-bit. And I have to look over here because this thing is jumping like crazy.
You can see ARIN still -- we still give out a fair bit of 16-bit, because the way we do it per policy is that as we just give it straight out -- we have an ASN pool. As you come in and request an ASN, you get approved. And the system assigns the lowest number that's currently in the pool.
And we clean up as the -- the ASNs that we get back, we clean them up the same way we clean up the space we get back. And once it meets all the requirements of being thrown back into the pool, it gets thrown back into the pool.
Every time we get 16-bit ASes back and clean them up, we throw them into the pool and they go out first. They're always going to go out first. We give out quite a bit of 16-bit.
Total ASNs assigned by each RIR, nothing real interesting there. You can see it pretty much jibes with all the other charts on the ASNs.
And that was the last slide. This is where you can see this presentation on the NRO site. And then you can also go to the IANA site to see the status IANA holds for them.
John Curran: Thank you. Any questions for John on the Number Resource Status Report? Okay. We're actually going to reorder the agenda and move to the IETF Report now. Thank you, John. We'll call you back up in a moment.
To make sure Cathy has enough time, we're bringing her up now.
Cathy Aronson: I've heard that before about the experience report being quick, and then it wasn't quick.
The last IETF was in Montréal, and I didn't take any photos in Montréal. So, sorry, this is from my neighborhood.
Yeah. It's a neener shot. Sorry, neener. I'm going to talk about the IETF. And for those of you who went to NANOG, there was a really nice overview of the IETF. Some of the management -- leadership, we call them -- were here to talk about the IETF.
This is a little bit more nitty-gritty, I think, but if you saw that, this all fits into that. These are Working Groups that are under the umbrella and the different areas that they talked about during their -- I didn't watch the video yet, but I did read the abstract, and it seems like it all is related in a really good way.
So this is from the last IETF, which was in July in Montréal. It's not meant to be in-depth, but there's a lot of information. If you're interested in something, you should be able to take my bullet items and go look it up. And that's really because I have 70 slides in, I don't know, 15 minutes or something. So good luck with that.
So this RFC, you probably aren't ever going to want to read and you don't really care what it's about, but it's really important. So for the last, what, since IETF 1, or RFC 1 was written in, what, like 1960 or something, the RFC format has been solely ASCII characters -- dashes, dots -- network diagrams made with pluses and minuses and dashes and slashes and asterisks instead of actually a drawing tool.
And this is the very first RFC that's published in the new RFC format, which is super exciting. If you go look at it, you'll find there are no diagrams in it. But the header formats are all still in ASCII characters, which totally crack me up. Anyway, it's a big move for the IETF. It's kind of a big deal, and I thought we should at least mention it.
So the IEPG is an operator forum that's been meeting at the IETF since -- in the '90s, maybe -- and most of the people at the IETF still don't know it exists. But we meet on the day before the IETF, and there are a lot of good discussions about operational things that are going on in the network and how perhaps we might fix them.
So some of the things they talked about this time, this was a hack that happened with -- they exploited a little kernel path in the Linux kernel to make a huge denial of service. So it's a pretty interesting read if you get a chance.
This is another -- oh, sorry. This is about DNS time-to-live values and how longer ones benefit you in certain ways, like, with denial of service attacks because if your timers are longer, then you're less vulnerable to the denial of service attacks.
The shorter ones are better if you're making operational changes. So it's a whole analysis of what you might set them at if you're setting up your DNS.
Let's see. This is a way to know if things in the DNS have changed. Sometimes if a hack happens, the change happens and then unhappens before anybody even notices. So this is a way that they're looking at keeping track of the information and when it changes so that you can know that things were quickly changed and there was something bad going on.
Sea Turtle. So Sea Turtle is another exploit that happened to a bunch of -- in the Middle East and organizations in the Middle East and North Africa. And there's a paper at the link, I think, there, if you want to read about it.
And I think this has -- yeah, so it affected 40 different organizations in 13 countries. So it was pretty prolific. And they're somewhat worried that maybe it will start happening in this region and not just in the Middle East. So it's something to keep an eye on.
So, routing in 2018. I know it's 2019, but Geoff Huston talked about routing in 2018 because the routing table in 2019 looks indistinguishable from the routing table in 2018, which is kind of funny. It's growing at the same rate. The same number of ASNs are being added, like exactly.
Even though we've run out of v4 address space, we're still adding the same number of prefixes every month and every year; they're just smaller.
So that's kind of strange. But, anyway, if you get a chance to look up his talk, it's always really entertaining. I think he's here, too. You can ask him questions.
So the technical plenary. I saw Steve Bellovin in the hall, and it had been so long since I had seen him, I couldn't remember how I knew him. It's like you haven't seen somebody in a really long time and you're like, what? Anyway.
They gave a really great talk about privacy and the Internet and whether notice and consent is the way it's always been, but there's no way to know who is gathering your information, and it's all encrypted.
So like I have a smart thermostat in my house, and I learned from this that the newer versions of my smart thermostat now have a camera in them. Why does my thermostat need a camera? I don't know.
So it's really a thought process of what we should be thinking about and how we should be changing things so that people's information get used in a way that they think is appropriate. So it's really good to check out.
So the transport area is everything to do with the transport protocols on the network. And I try to go to some of these overview Working Groups when I don't have v6 stuff to go to because they're kind of a survey of that whole area.
And we've talked some about transport area in my talks in the past because there's a movement underway to encrypt the transport layer, and that causes a lot of problems for a lot of enterprises and people who run networks because you can no longer see what's going on in your network.
So there's a number of things going on to try to -- I'll talk about -- to try to figure out what's going on when everything's encrypted. Let's see. So this is a way to determine loss on an encrypted transport layer. So it's a draft that's going around, loss signalling. Like I said, this is like the helicopter view.
Now we're on to security. The Security Area Directorate is also another one of these overarching groups of security and the IETF. So this is about LISP, which is the locator -- it's a different way of doing routing where you separate your location from your destination and then you route accordingly, and there's ways to determine a lot of information about people using LISP.
So this is a discussion of "is it okay to not have location and movement privacy, or is there a way we could do LISP and still have those sorts of privacies." It's amazing what they can tell about you just from what you do on the network. Kind of crazy.
And then this is about do we need an extended threat model. So historically we believed that the network may be compromised but the end systems aren't compromised, and is that still really the way of the world with all the exploits that are going on.
So they're looking for feedback on this draft. So if that interests you, I'm sure that the Working Group would appreciate for you to take a look.
So DNS Operations is a Working Group that's really all about the operations of the DNS and various DNS-y things like that. Let's see.
So we talked about ANAME before. ANAME is like CNAME; it can exist with other record types that CNAME can't. And that's getting further along in the process. If you're interested in that feedback, I think they're looking for feedback.
Considerations. If you're running a large, authoritative DNS, basically stuff about how to best configure your Anycast so that you have the most robust DNS infrastructure.
So, there are a couple of overarching issues on the Internet these days. Fragmentation is bad; we've talked about that before. Packets are getting bigger and bigger because we have more header information and various things.
And it's the same in the DNS. The DNS, the packets are getting bigger and bigger, and with v6 they're bigger and bigger. And there are a lot of problems with packet size and fragmentation. So this draft is talking about how to avoid fragmentation in the DNS.
And there's another draft that's trying to solve the CNAME/ANAME thing because we need multiple protocols for the same thing, which we'll talk a little bit about more in v6ops.
This is a way that you can know whether something that looks like a subdomain of a domain is actually valid, like, you know, food.example.com is really part of example.com and not somebody exploiting and spinning off a subdomain.
And then there's a bulk format for easy sharing of the DNS zone information that they're proposing.
So this is the -- I think Paul Vixie gave a talk at NANOG about DNS over http. I wish I could have been there for that. This is all about -- this is a BoF all about that sort of stuff, applications doing DNS on the Internet.
So they're writing a DNS over http BCP. I'm not going to talk about it too much, but here in the super small print are the list of things that they're looking at putting in there, how to manage it, what enterprises can do setting up the servers and all that sort of stuff.
If you're interested in that, I'm sure they would love having people with experience to write some of these sections or maybe add some that they haven't thought of.
So SIDR operations is this secure inter-domain routing. It used to be that we were working on the protocol side; now we're working more on how to operate it. And this is the group.
So this is a way that somebody who is advertising an ASN, an ASN that's advertising an ASN, you can know whether there's a valid announcer of it. So it's not just validating the prefix but actually validating that the upstream that's advertising it is a valid upstream. So that's a draft about that.
Let's see. Yeah, I'm going to just skip through that. Yes, this is an extended community that carries more information about the validated state of a prefix.
Let's see. And then this is a way that they're looking at to make the key roll easier so that you can say which keys are the valid keys to do the key roll. There's a lot of work being done on the key roll stuff and how often we do it and whether we do it or not and that sort of thing.
So v6 operations. v6 maintenance, I'll talk about later, is about the actual protocol and maintaining the protocol, and this is all about operations and interaction between v4 and v6 and pathologies that are happening operationally in the network.
This was an awesome talk. This fellow manages a large wireless network on the African continent. And he's living the dream, as I like to say. So back in the NSFNET days, we had all these Acceptable Use Policies and we had to route all the traffic based on, you know, the US didn't let Russian prefixes in and this and that.
And on the African continent, there's all these different countries, and they all have rules about what traffic can go across them and how the routing has to work; and not only that, but on top of that, we've talked before about if you have five different standards for a particular protocol, like a tunneling protocol, then you don't really have a standard because this gizmo can implement one and this gizmo can implement another.
And this poor guy, his customers all come with their own gear, and they all have v6 transition mechanisms that don't interoperate. They're all standard, but they don't interoperate. So this guy's house can't do the transition mechanism that he picked.
Anyway, it was awesome to listen to him, and it was just so -- it's really a lesson in we really need to have singular standards for things and not a menu of standards because he's just in this -- you know, like, he doesn't know any given day if the new customer is going to be able to connect to his network and whether he's going to be able to futz the traffic around so that, you know, he pays attention to everybody's Acceptable Use Policy in all these different countries. It's really quite an engineering feat.
Anyway, I love it when they have real people come and talk about their networks because it's pretty exciting. So I talked about all that.
So this is a v4/v6 translation. There's some topologies where if you're v6 only, you still might do a translation. Even though the network is v6, why not just do v6? And sometimes when you're v4 only, you end up translating twice because it takes a while for it to figure out what you're really doing.
So there's a lot of work being done to try to eliminate those extra steps. So if I'm v6 only, I just use v6 and I go on with my day. And this is a documentation about that, a document about that.
So this is another problem on the network where there's some expectations that a connection, a new connection -- the connections on the network are bidirectional. And if a new neighbor comes up and it's not in your cache, you decide that you are not going to use the traffic -- you're not going to accept it because it's not something that's already in your cache.
And Jen has been doing a lot of work on these, just really interesting problems with duplicate address detection and routing advertisements and stuff in v6 to try to sort all these things out.
Yes, so there's a security considerations document for IPv6 that's being worked on since 2012, and it isn't finalized yet. But they're working on finalizing it and getting something out there because we really do need to pay attention to these things.
And there's some ISIS work being done with how do you design a network that's v4 and v6 dual stack or maybe it's just v4 or just v6 and combining with ISIS?
We talked about this draft before. This is a sort of an overview of all the different prefixes that you might use to number your point-to-point links on your network and why. Jordi has been working on this for a while. I think I've talked about it a few times at this talk.
And Jordi's been working on this, too. This is, "what is v6 only?" Is it really that you're really only v6, or maybe you're still encapsulating v4? It's a definition of what "v6 only" means. And in this case, if you're still tunneling v4 but your native infrastructure is v6, then you're v6 only.
Let's see. I'm not going to talk much about this, but they've started doing this track, this technology deep dive thing. One of them was about routers, and this one was about network interface cards. It's not really my thing, but if you're really interested in network interface cards and how they're designed, have at it. Awesome.
So the Advanced Networking Research Workshop. So in the spring and then in the summer -- I think it's in the spring -- we have just the workshop where people come and present all these advanced research-y things they're doing.
And in the fall we get the presentations of the winners who have published papers that get accepted and they get a prize for whatever their research is.
And so these -- it's in parallel with IETF. So I only end up going if I have some spare time in my day, which seems strange. But anyway, this is research that's being done on stateless auto -- address auto configuration, using software defined networks. And I think it's a research paper. So if you wanted to read it, just Google it.
There's always something at the IETF that shocks me, and this, pretty shocking. So there's like a database at the IANA that has everybody's time zone in it, and, like, if you -- when we change Daylight Saving Time, they put it in some flat file and everybody uses that to, like, coordinate their time on the Internet. Really?
No, it just surprised me. So for 26 years it's changed 2200 times. So it has all that, like, esoteric, you know, like, "I'm a half an hour different than you" kind of nonsense, and it's in a file at the IANA. I was shocked.
Let's see. So this is about inferring things from the network and when you have an encrypted transport layer, can you infer things about the network that you need to know without decrypting. So, this is techniques to do that.
Can you determine if there's an attack going on if everything's encrypted? And remarkably you actually can infer a lot about the network even though it's encrypted.
So v6 maintenance is all about the IPv6 protocol itself and not so much the operational aspects of the protocol.
So, like I said before, we have this whole routing extension header thing, and the packets don't -- like Geoff was saying in his talk that 30 percent of the extension headers get dropped but we keep adding them.
We have a segment -- they're looking at doing segment routing with the header, and that draft is in -- I guess it's just out of Last Call.
Let's see. And the ICMPv6 errors also have a lot of things for broken extension headers in them, and that's in that draft.
So Path MTU, so the maximum transmission unit in the network, you're supposed to be able to discover that. There's been a protocol forever that doesn't work. And so because we have all these problems with these big packets and fragmenting these big packets, there's a movement to try to figure out how we put that in the network and actually discover the MTU and make it work so we don't have the fragmentation and we don't have the problem of the packets being dropped by firewalls and various things.
And so this is a hop-by-hop option to share the MTU across the network. And like I said, Geoff says that 30 percent of the extension header packets fail, which is pretty high and kind of scary that we keep adding extension headers. But anyway. Is that some sort of insanity thing? I don't know.
So this is about neighbor discovery on wireless networks. There's some problems and the duplicate address translation doesn't always work because it takes too long. And there aren't a lot of address conflicts because the address space isn't ginormous, but it could be that you're all just using this one part of this huge prefix, which is probably what happens more than you think.
So they're trying to fix some of these pathologies in the protocol so that it's not as chatty, it works better and the success is better.
So this is a way -- again, fragments are bad, packets are too big. It's the overarching theme. And this is a way to make fragmentation better. So if the header is really big, maybe we still want the first packet to include the entire header so that we don't have as much problem when we're trying to assemble it.
The other thing, I'm going to take a moment, a peeve of mine, is that why is the MTU 1500 bytes? Because somebody said so. But it's easily changeable. Why aren't we doing it? Anyway. My soapbox. I'm off of it now. Because almost all modern equipment will let you configure it across the network, and yet we don't.
This allows you to know what your NAT64 prefix is. And they're moving this esoteric RFC to Historic, maybe, of jumbograms, which are these ginormous packets that are optional anyway. So the argument was who cares if it's Historic or not because they're ginormous and you don't have to use them. I don't know.
Let's see. This is just some diagnostic tools for segment routing in IPv6, ping and trace route and other tools.
So I went to the Network Management Research Group, because I could, and I had a lot of giggles -- I'm sorry, I did -- because intent-based networks is kind of the thing now. So, for a while it was autonomic networks, but they all apparently run themselves; no need for us -- they all run themselves. And they're based on your intent.
So I was just having a really good time thinking what I would intend my network to do and then how this gizmo would make config commands out of that. I don't know. It just makes me giggle somehow.
But if you're interested, there's a link. I could intend my network to do a lot of stuff, you guys. I think so. Wouldn't it be great, though?
Let's see. And then you could classify your intents. Like maybe you're in a bad mood -- I'm sorry.
But more seriously, like, interface or -- but a model of intent. Just had a good time with it. And there's more intents. And I'm really not sure the emperor has clothes, but nonetheless.
I guess I didn't say that at the beginning. I often include things that I type randomly while I'm taking notes in these meetings, and that was one of them. I'm sorry.
And there's a management framework for my intents, which is super cool.
Okay, Source Packet Routing is another Working Group that I went to. The charter is there. This was -- I only include this because of the example in the draft because this is not going to go anywhere because it's using a code point that isn't allowed in any other RFC.
But they used a /32 per router loopback in IPv6, and that's like a whole ISP allocation because it was easy to subnet. But one of the women got up and said she thought briefly they had mixed up v4 and v6 because in v4, a /32 is an address and in v6, it's like a ton of addresses. Anyway, it was pretty funny. Gotta have some fun at the IETF.
This is a way to carry some node and ring IDs around in DHCP that's being worked on, because otherwise there's not an easy way to assign them.
How to operate segment routing in IPv6. This is about that. More segment routing drafts for your perusal.
Okay, so this, again, one of the things I went to that was just idle curiosity. So this is all about the requirements for the IETF network itself. And I think we all, in all of these meetings, have this sort of thing that we discuss: Do we really need the things we're paying for? Could we really actually use the hotel network? Do we really need a lot of this stuff?
I know I didn't need it when they turned off all the v4 in the Working Group I was in and I could no longer use my computer. Just saying, didn't need that.
But a couple of the things that are really cool about it, they have a box that they send out. I think it's on the next slide. They have a box that they send out. It's called The Scout. And they put it on the network, and it sends them back all kinds of info about the hotel network so that they can better design the network. And it does all the stuff so the geolocation of the IETF block isn't in Singapore anymore, it's in Montréal, and that sort of thing.
But one of the hotels when they sent the scout out, one of the hotels had the access points in the elevators. So can you imagine that? Right.
All of a sudden, you have really good signal. Then you have really bad signal. Then you have really good signal. Then you have a really bad. The hotel was like 40 floors. It would be really interesting. Anyway, they had to fix that because that wouldn't scale.
Anyway, the IETF is really trying to figure out, like, now that they're a separate organization and they're in charge of their own budget and not just an activity of ISOC, they're really looking at what are we paying for, what do we really need to be paying for, what do the people attending the meeting really need and that sort of thing.
But access points in the elevator, take a note of that. Awesome.
So the last two Working Groups that I've included here I did because we're meeting with NANOG and they have to do with routing protocols. So I thought it would be helpful.
So IDR is the Inter-Domain Routing Group, which is basically all about BGP, every kind of BGP. So this is the update on the BGP Linked State. So, BGP is a distance vector protocol, and they really wanted to have some linked state functionality but not be as chatty in a data center, like as OSPF would be. So they're trying to do this hybrid that's BGP and Link State.
And they're looking for feedback of folks. There's working code that you can check out.
So let's see. Again, more MTU stuff because the packets are too big, and fragmenting is bad. They're looking at BGP Path MTU because, I guess, BGP packets are getting too big too. So sending around the MTU information in BGP, it's an overarching issue.
This is BGP doing VPN stuff for v6-enabled networks. So maybe you're not running MPLS but you want to have some MPLS functionality, just trying to put that into BGP. Everything either goes in DNS or BGP. Just add more stuff in there.
And the next draft is a way for inter-domain to send colors back and forth, like different kinds of traffic so that different ISPs know, oh, this is that kind of traffic; I should treat it this way. So it's like a community thing.
Okay. And then the other group I included because of NANOG is GROW, the Global Routing Operations Working Group. And sometimes the agenda is fairly full, and sometimes it's not. This is a community that gives you the ability to detect route leak and mitigate them. And there's some monitoring of your RIB, a protocol to monitor your BGP RIB and some other drafts for your perusal.
I think I might be -- yeah, so if you're going to go to the IETF and you want somebody to hang out with or show you around, I'm usually there at least until June. I'm renewed through June.
And there's some good reading. There's a video about how not to be offended by the geeks that aren't real polite and various other things here.
Like I said, if it's your first IETF, there's a great video. If you're a woman and it's your first IETF, we have a whole sisters group of women, we meet for lunch. It's awesome. And then of course the Net-grrls. If you're interested in joining any of these, talk to me.
Anyway, that would be -- looks like Mark has a question, maybe. And this is going to be me in another couple of weeks.
John Curran: Okay. Mark.
Mark McFadden: My name is Mark McFadden, Internet Policy Advisors. Three quick things. First of all, I apologize for the first one. As a Milwaukee Brewers fan, I was very glad that we were able to arrange that Josh Hader would blow up and give the Nats the Wild Card Game.
Second thing, and this is directed to John and the Board: I find these reports exceptional and really helpful. And even when I don't come, I still stream them. So it's feedback that you didn't ask for, but it's --
John Curran: It's very timely. One of the things that's come up frequently with the Board discussion -- this is a very well-rated session that we always have. But the question is: We don't right now have a formal feedback mechanism for the community to decide which content you want other than policy discussions. And so we've thought about a program committee.
But then the other issue is we only have about two hours to three hours of slack in the whole agenda. So we're trying to figure out what's the mechanism for that feedback and how do we sort it.
But I assure you, whenever we get that straightened out, we'll remind them that this IETF Report is well-rated.
For Cathy, we actually formally anointed her the IETF Reporter through the end of this year, and then recently we continued it through June. There's no intention to end the role, but the question is how often we go out and solicit, because maybe someone else wants to do it or maybe she -- there's some mental wear and tear doing this, I imagine, and she might want to share the load.
So from that regard, we are going to continue the IETF Report. We just don't know whether we'll solicit for a call for reporters and/or how we compare this to other things that might go in the schedule. I do appreciate it.
Mark McFadden: And just in the interest of giving you that formal feedback. And the third thing, I'm glad you had one slide about the transport area, but one of the things that's very interesting and a trend that's going on I think in the IETF is that the research groups are getting more interesting.
One of the things that I observed, and I'm going to give you an example of one of the research groups that I think has both identifier and operational interests -- one of the things that's happening is we're starting to see research that talks about whether protocols really have their intended effect.
So one of the things that we're doing right now is putting a lot of privacy, a lot of encryption into the network. But the question is: If you step back, is that actually doing what it's intended to do? Does that actually work?
And there's a lot of really interesting research that's starting to show that if you take a step back and actually look at the implementations, the protocols that are relatively new, that have taken place since the Snowden revelations, that perhaps they don't actually do what we intended them to do.
And it isn't really a question for Cathy, but one of the things I think the community should look at, if you're interested in such things, is that there is a group called the Privacy Enhancements and Assessments Research Group. There are two pieces of brilliant research that took place in Montréal that were presented there that have to do with obfuscating DNS queries, and it shows things like DNS over TLS and DNS over http perhaps don't do in the wild what they're intended to do.
So thanks for the report again. I think one of the things that's happening, a real trend here, is that the research group is starting to do interesting work for the operations and identifier community.
Cathy Aronson: Thanks, Mark.
John Curran: Next speaker.
Scott Johnson: I'm Scott Johnson, SolarNetOne. This may not seem directly related to ARIN or NANOG business, but due to the way that I've had to deploy my AS and route my packets, it's kind of critical to me.
RFC 8221, Cryptographic Algorithm Implementation Requirements and User Guidance, is dated October 2017, and this gives guidance for ESP and AH packets encryption algorithm recommendations. Is there any action in the work groups there to update these recommendations? Because this obsoletes suite B, but it in itself is starting to become obsolete.
Cathy Aronson: I'd have to look. I'm not -- off the top of my head, I don't think I've seen it being updated.
John Curran: You should take that up after the session, see if you can find out. I'm not aware of anything either. It would be in the 6MAN group.
But the IETF often has key documents expire because they're good enough. And either someone doesn't bother to actually get them to RFC state, so the draft, the ID expires. Or it's assumed it's been overtaken by something else but actually hasn't because the work that was launched didn't get to a draft state.
So we kind of end up with a gap. So it's worth looking at. And then if it turns out that there really is a draft that's expired that people are using.
Cathy Aronson: But that's an RFC, right?
John Curran: Is it an RFC or ID?
Scott Johnson: RFC, 8221.
John Curran: Oh, it shouldn't expire, then.
Cathy Aronson: He was just asking if it's going to be updated.
Scott Johnson: Yeah, it was not expired; however, it was authored over two years ago. And we're talking about cryptographic algorithms, which is quickly moving --
John Curran: I see. Might have been overtaken by events. Worth getting together. I haven't heard of anything going on in 6MAN in that area either.
Scott Johnson: Thank you very much.
Martin Levy: Martin Levy, Cloudflare. This has kind of already been said, but it's a plus-one on this report, both here and at other fora, because this is a brilliant meeting of information that exists within the IETF versus the operations versus the policy environment, and these do not overlap as much as people think or in fact should.
This is a general call to anybody in the room: You should go to an IETF meeting, if you haven't, because there's a lot more to learn than just a quick review like this. That's point number one.
Point number two, that you just mentioned, I wasn't going to say this, but, yes, some of the best stuff out there are in drafts that have expired, including mine.
And the third part is, just to let you know, Robert Metcalfe is a professor here at the University of Texas in Austin, and so down the road is the answer to your 1500-byte question.
Cathy Aronson: I know, right. I believe I presented your draft on increasing the MTU through the exchange points at one point at a random IETF.
Martin Levy: All good efforts go to -- well, whatever.
John Curran: Front.
Owen DeLong: Owen DeLong, ARIN AC. Yes, this report is very useful, and we should keep it going. And I'm very thankful that Cathy does such a wonderful job year after year doing it.
Going back to intent-based networking, I think that this might have potential if they can fully implement the DWIM interface -- Do What I Mean.
Cathy Aronson: And not what I say, right?
John Curran: Center, rear mic.
Lee Howard: Lee Howard, IPv4.Global. My understanding about the 1500 bytes, I actually made an effort to increase that also, and I was told you have to go to IEEE to change the sizes --
Cathy Aronson: And they said no --
Lee Howard: And they said no because somebody somewhere still has 10-megabit-per-second Ethernet.
John Curran: Yep, very hard to get hold of old things. Any other questions for Cathy?
Thank you, Cathy.
Adopted IPv4 Waitlist Policy Recommendation
John Curran: So we try to start the policies at the same time in the meeting that they're actually published because some people participate remotely and want to make sure that they don't miss the start of a given policy. That's why, once we get into a schedule policy block like the one that started at 10 AM, we stop doing other presentations and we promptly start doing policy presentations.
This is why I deferred John's presentation, because I didn't think Cathy would be able to fit it all in at the same time.
So we're now going to go ahead with policy and this morning's policy block. The first one is a presentation about adopted IPv4 Waitlist Policy Recommendation, and the presenter is me because this is a little bit unusual. This is not something that went through the full policy process. This went through a section of the Policy Development Process that handles expedited and extra and emergency actions. So I'm going to talk about the recent change to the IPv4 waitlist policy, and then we'll take questions on it.
So, on February 7, 2019, the ARIN Board suspended the waitlist issuance from the policy, the policy that allows people to qualify, be put on a waitlist, and when address space is available, obtain a block. We took the issuance part, the last part of that policy, and said, nope, it's in suspension.
The reason that occurred -- you can go find it in the archive -- is because we had credible knowledge that the waitlist policy, which at that time allowed any request that we didn't have the space for to be put on hold until we did, was being used by parties to obtain very large blocks under fraudulent terms that were very hard to stop.
And once those blocks were obtained, someone who gets a very large block -- a /16, /17, /18 -- has high financial value and prevents dozens of community members who have smaller requests.
So because the waitlist policy was being used in this manner and we wanted to make sure that we didn't damage the community in the process, we put the policy issuance on hold. We would not issue -- and we actually went to the AC and said, "Here's the problem."
The AC came back and said, "Let's think about a change to the waitlist policy." And that ended up being given to us as a first draft on the 29th of April. And it was the Advisory Council recommendation regarding NRPM 4.18, Unmet Requests. It was a Staff and Legal Review. It was published to PPML for discussion.
We incorporated the updates. It was reviewed and adopted by the ARIN Board, and it was put into production in July. And we resumed. Under this modified policy, we resumed the waitlist issuance.
Basically, the suspension was done because of misuse of number resources. The Policy Development Process allows us to strike completely or suspend policy if we believe that there's a material issue, harm to the community.
The AC recommendation -- the update when it was adopted calls for putting a limit that the maximum aggregate that can be put on the list is a /22; and only that if organizations hold less than /20 or less of IPv4 address space; and that upon receiving address space, you won't be eligible for transfer for a period of 60 months.
If you just waited for address space and you receive it, then that address space that you receive, we expect you'll be using for years.
And so we applied that policy and then opened the waitlist and began issuance. We went to everyone on it who met the policy and told them you can now get a block of /22 or smaller and adjusted all the entries.
The AC recommendation includes provisions that once you received the address space, you can't apply for more for 90 days; that we can waive if there's an unusual change in circumstances; and that everyone is advised, if you're going on to the waitlist, that there's actually a transfer policy and therefore there's an active marketplace you can go to.
So the other aspect of the AC recommendation is that the position is based when the request was approved and you only get one approved requirement.
And that finally the last part of the AC recommendation is that we'll provide, on a first-approved basis, address blocks available and anything -- once you've been approved, you're removed from the waitlist.
So the change is predominantly adding the limits of a /22 and no more than total space of /20 held by the organization.
When we did the legal review, we commented that we understand the policy. And so it would be a cap even if someone would qualify for more and the policy was updated.
The legal counsel -- there was a strong support for this because of obviously when you have a situation of fraud against the organization, having a limit limits the amount of damage that could be done by someone who interprets that fraud.
The staff updated the policy -- AC updated the policy to clarify some staff comments, and it was actually adopted by the Board, as I noted, on July 10th.
So even though it was an abbreviated process, because in an emergency that's what the emergency PDP calls for, it still was developed by the AC, went to the community, went to public comment in the community, and we ended up not having a suspended policy for very long.
You folks originally adopted the waitlist policy, saying, "Issue space." We actually, the Board of Trustees actually, stopped your policy so that it could be amended in this manner and then we started it as fast as possible.
The emergency PDP isn't often used, but we will use it if necessary to protect the interests of the organization. So with that having all been said, we didn't really have a time for a discussion at the community. That wasn't really an opportunity.
We'd like to have a discussion now. Do you agree with that policy? Do people have concerns about the changes that were made? Also, now that we've made those changes to the waiting list policy, are there now subsequent changes or anything further that the community thinks is appropriate in that area of the PDP?
So, we made an emergency change. It's been implemented. Microphones are open to discuss the waiting list policy.
I'm now going to ask the Vice Chair to come up to moderate the queues.
Bill Sandiford: Back microphone.
Mike Burns: Hi, Mike Burns from IPTrading. I do support generally the changes and utilization of the emergency Policy Development Process here in response to the fraud. But one of the issues I have is that by including the limit of a /20 for holders to come and access the waiting list, we are angling towards a new entrant policy without any discussion of that.
So the other RIRs have specifically discussed policies designed to encourage new entrants to have access to reserved IPv4 pools. We've never done that here. And in the past, in the context of discussions about removing needs tests and setting certain block sizes that would qualify for a transfer without a needs test, objections were raised that this goes against the interests of larger members.
And I think it's fair for us to discuss, if we want a new entrance policy, if we want to elevate new entrants over old members, it's something we should talk about. And that's my comment.
John Curran: If I could ask you a question before you -- given that we've sort of backed into a policy, would you propose, based on your thoughts of new entrants and the barriers that are posed one way or another by having the /20 as a total size limit, do you believe that the current policy is appropriate, or would you refine it somehow with further change? Is there a particular change you'd propose at this time?
Mike Burns: I'm undecided. I think it's something that we should discuss. It's different. We haven't discriminated really beyond dues between large members or old members and small members and new members. And now we're doing that kind of unilaterally without a normal Policy Development Process.
As for my opinion, I don't like any reserved or free pools. I don't think that they're consistent with a trading market existing at the same time. And they're a magnet for fraud and for abuse.
And my understanding of the waiting list policy when it was first being developed was that this was going to be an interim stop-gap measure to deal with IANA returns primarily.
My understanding was that there would be little incentive for revocations and returns to take place given the value of the addresses, which always is larger than the back dues. And I just anticipated it would be unlikely that people would voluntarily return their addresses when they know they could sell them for money.
So I always assumed this was going to be a temporary thing and that it would eventually taper off. But in any event, it's turned out not to be the case. And with the influx of Amir's addresses, that really gave a lot of extra life time to the waiting list. And reducing the maximum allocation size to a /22 also extends the waiting list.
So, in general, if we're going to prioritize new members, give them access that existing members don't have, I would like to hear arguments for and against that before I come to a decision.
John Curran: Okay, thank you.
Bill Sandiford: Front and center microphone.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. So I think the balance struck in the current waitlist policy is appropriate, and I know there are a couple of policies working their way through that we're going to discuss when that makes some -- proposes some further changes, one of which is a clarification and another a constraint, another one that would do away with the waitlist.
I would suggest that we actually give the revised policy as currently implemented some time to work its way through and see what the policy experience is until the next meeting before we try to tinker more with this substantively.
If there are actual clarifications that need to be made because something isn't clear in the policy, and one of the policy elements of one proposed policy has such a clarification, that's fine. But in terms of either releasing the constraints or making them more stringent, I just think it's premature. We need to give it some time to work its way through, unless, of course, people want to do away with the waitlist entirely, which is a totally different discussion. Thanks.
Bill Sandiford: Thank you. Far microphone.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. First off, the comment I stood up to make was a comment that Chris also made. So I'll not make that comment because it would be just repeated.
But to address an earlier comment, I think my memory of the mindset behind putting in the /20 limitation is the idea of -- is the idea that an organization that already has a substantial amount of address space is far more likely to be better positioned to obtain additional space over the -- via the transfer market as opposed to the waiting list.
So, in my opinion, I think it's fair to -- whether or not you want to call it a new entrants policy, whatever you want to call it, my personal opinion is that it is fair to say that the waiting -- address space obtained from the waiting list should be earmarked for smaller organizations and organizations without the resources to obtain their space via the transfer market.
Bill Sandiford: Front and center.
Owen DeLong: Owen DeLong, ARIN AC. I'll first echo what Chris and Chris said. I think that Mr. Burns, in his comments, kind of conflated small entities and new entrants in a way that isn't necessarily entirely accurate. I don't think they're one and the same, as he kind of seemed to express.
The reality is it would be great if we could do something that didn't discriminate large versus small in IPv4 policy here. But we can't. There's no possible way to serve large users adequately in the current environment.
There is not enough address space available. In case nobody noticed, we're basically out of v4. If you want address space available to serve your new large organization or even your existing large organization, hey, there's lots of v6, and it would be really good if people used it. It would be far better for all of us if we could get over this v4 addiction and move on to v6.
But what we're doing here with this policy is the art of the possible. It is possible for us to serve smaller organizations to some extent with the resources we have available. It is not possible to serve larger organizations to the same extent. Sorry.
So I think we've struck a good balance. If people think that a different balance would be better, I certainly would like to hear from them about what that balance would be and what it would look like.
I don't favor eliminating the waiting list. I think it's serving a constituency of the ARIN community quite well, and I think that it will continue to do so as best we can.
But, you know, there's a limit to what we can do within the constraints that are available. And I think we're doing the best we can with that, not trying to discriminate.
Bill Sandiford: Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I'm extremely supportive of the fact that EPDP was utilized in this case. I want to make sure that the EPDP is used, because of its power and the way it's done, specifically for the issue that is there.
And I really want to echo what Mike Burns said, the /20 was a complete overreach. It does not deal -- it was not needed to deal with the fraudulent problem. It should have been left out. It should have been done separately. We have now gone effectively through a rapid process and added on what is effectively a new entrant policy now without community discussion.
Dealing with the fraud was absolutely appropriate, and I felt that there was a right balance that was given to the rest of the text.
So my only recommendation at this point is strip out that one line with the /20, it's not relevant to dealing with the problem, and let the community start a new policy discussion on new entrant policies or whatever the case may be.
But I am deeply concerned with that addition. It changes 10, 15 years of expectation about soft landing versus hard landing, et cetera.
As a small company, I'm excluded now. And I don't believe that it is up for the Advisory Council in this particular case to be deciding who is small. Deal with the fraud, which is what the EPDP was for.
Bill Sandiford: Thank you. Closing the queues now. If you have anything further to add, please join the queues.
John Curran: Kevin, I just wanted to respond. To the extent you believe the policy would be better without that constraint of /20, there's a way to submit policy proposals and a number of AC members here who can help you with that if you wish to make a proposal to that.
Kevin Blumberg: John, I believe it should be the other way around. Using the EPDP, that should not have been in there to deal with this issue. The AC and the community, if they felt that that should be there, should have started a policy after that and gone through the long tail of a proper policy process.
John Curran: Understood, but now that we are with the policy as it is, if you believe it should be changed, you should submit one.
Kevin Blumberg: I'm answering your questions to the community, if I feel this --
John Curran: Understood.
Bill Sandiford: Far microphone.
Joe Provo: Joe Provo, Google, ARIN AC. I want to echo -- I don't want to echo in the microphone -- I want to echo my colleagues, Mr. Tacit and Mr. Woodfield, regarding the original reasons I stepped up to the microphone, but I do want to point out to the extreme strict nature that has some bones of contention, we -- I agitated for that. I'll take some brickbats for that if people think that's terrible.
We all agreed to it, but the intent was to actually restart the process and then come back to the community and get things moving. And some of these numbers, some of these values were based on the data that we had.
That's the one point that I haven't heard yet, that we actually had data that this would functionally restart things and not be a significant blocker for a lot of folks that were actually in queue.
Bill Sandiford: Thank you. Far microphone.
Kevin Morgan: Kevin Morgan, Stratus Networks. Kevin before me said almost exactly what I was going to say. So I don't need to be repetitive. I think that there's definitely better ways to deal with the fraud than put the /20 limitation in there and that a change this major needs a longer vet by the entire community and how many people it affected to rip that, put that restriction on there, which effectively removes people from a list that they were on.
Bill Sandiford: Thank you. Far microphone again.
Robert Seastrom: Rob Seastrom, Packet, also on the ARIN AC. I'd like to respond specifically to Kevin. Our concern was addressing the fraud. There was stuff put in there that is easier to roll back than to roll forward, things like the five-year hold time. That's something that you can easily say, well, we had a community consultation, and actually the community really, really thinks that two years and eight months is the optimal number. So we're going to roll it back.
And nobody screams that they were hurt by this, by pulling it in. Likewise, doing a restriction, where we didn't really have one before, is something that could be unwound with minimal damage.
So I supported it at the time. I support having some sort of a restriction now. And I encourage Kevin to bring us policy proposals. I'll even help write one if you think that the community needs to unwind that or push it to a different prefix length.
Bill Sandiford: Briefly we'll allow Kevin to respond now.
Kevin Blumberg: I want to clarify. My concern was this was done as part of the EPDP process. It did not go through a full meeting. And the litmus test that is used for that process should have been far more stringent.
We all know that once we start a new policy process, it's a long, involved process. We have added in a significant restriction that have not been convinced was to deal with the fraud issue into it. And that is my concern.
I am more concerned about how we use the EPDP and how we overreach on the EPDP than I am about making a new policy and winding back some things. I don't believe the sentence has anything to do with the problem that the EPDP was called out to use.
Robert Seastrom: And the counter to that is we did in fact get a proposal that only changed the prefix length, only put a limit in and did nothing else, and that there's -- at least a section of the community thinks that merely doing that would have been sufficient to remove the fraud incentive by making the transaction size so much smaller. Thank you.
Mike Burns: Can I just say one thing? There was a proposal put in place by my organization for just that: Restrict the maximum allocation to a /22. And I have to agree with Kevin.
The lauding on of the /22 limit had nothing to do with that fraud, and it was an example of policy development that should have had a debate. And that's it.
Bill Sandiford: Thank you. Any remote participants, Leif?
Tina Morris: I wanted to make -- I don't use this very often.
Bill Sandiford: State your name for the record, please.
Tina Morris: Tina Morris, Amazon and Advisory Council Chair. The /22 limit, we know for a fact, wouldn't eliminate fraud. We've seen this happen in RIPE. We took those experiences and brought that to this policy. It was very intentional.
Mike Burns: The problem in RIPE had to do with new entrants getting free addresses. It's not the same thing as a waiting list having to demonstrate addresses.
Bill Sandiford: John.
John Curran: Question for the speaker. So the question is, if the AC was unable to converge on a recommendation, then the waitlist policy would remain suspended indefinitely?
Mike Burns: Yeah, I would prefer that. I would rather have it be.
John Curran: You would have preferred that. That's what I wanted to know. Okay, thank you.
For the community, I note I'm doing two things here. One, I'm trying to understand feedback on what happened, both from where we are with policy and whether you folks want to make more proposals to the AC, but also for the PDP process, because I maintain this errata sheet, which is an amusing document, and it's possible that having -- as we've exercised this emergency PDP, that a future version might be more constrained or put circumstances on. That's why I want to understand what outcome you desire. Thank you.
Bill Sandiford: All right. If there's none remote, then we'll call it closed, and I'll pass it back to you.
We'd like to remind the remote participants that if you have comments or questions to add, please send them through the process. We do have a moderator here onstage that can relay your comments into the record.
Recommended Draft Policy ARIN-2018-6: Clarify Reassignment Requirements in 220.127.116.11.1
John Curran: Thank you. Very good. Very helpful discussion. Okay. We find ourselves now at -- it's 10:35. We still have time to do some more policy. So I'm going to ask Alyssa Moore to come up -- actually, I'll do the introduction first.
I'm going to do Recommended Draft Policy 2018-6: Clarify Reassignment Requirements in 18.104.22.168.1.
Okay. The shepherds for this policy are Alyssa Moore and Alison Wood. It was proposed as ARIN Policy Proposal 258. It was made a Draft Policy by the AC in November of 2018. Draft policies are when the AC realizes, looking at the proposal, that indeed there's a problem statement and that there's an actual issue to be worked on.
If you submit your Christmas list to the AC, they'll not adopt it. If you submit something that's actually an operational suggestion, not having to do with number policy, again, it won't be adopted as a Draft Policy.
But they realize it was a problem statement here regarding number policy. They adopted it as Draft Policy, at which point they assign shepherds and they begin to get input from the community to facilitate making a good policy.
After several rounds, it ended up being revised and was recommended for adoption in July. It was presented at ARIN 43. The latest version was updated November 20th of 2018.
The Draft Policy clarifies reassignment requirements. The staff understanding is that the policy text makes a clear delineation in which reassignments are required to have customer Point of Contact and which ones do not have to have it. So reassigned detail needs to have a customer Point of Contact information and customer simple reassigned does not.
And the language clarifies that. It's furthermore made clear that there's a requirement to SWIP /29 or more. That remains unchanged. That is as is in the current policy.
The staff believes the text is clear and easily understood and can be implemented as written. ARIN Counsel has reviewed it. It has no material legal issues.
The resource impact is minimal. We can actually implement it. If it turns out that the community supports it and the AC sends it to the Board and they ratify it, it would be three months after ratification.
We'd update our staff training, internal guidelines, the documentation on the website, and we'd do customer outreach to inform them of this change.
So I'll now have Alyssa come up to do the AC presentation of the policy.
Alyssa Moore: Good morning and happy Halloween. I'm happy that I'm not up here wearing a costume. There was a proposal that the AC do a group costume. I'm quite happy not to be immortalized on YouTube presenting numbers policy all dressed up. But this evening.
So as John said, this was first presented in Barbados. It's been to one meeting. Since that time we've advanced it to Recommended Draft as the AC. So this is potentially the last time that you're seeing this at a meeting. So keep that in mind.
So this is about, as John said, clarifying when it's necessary to do a simple versus a detailed reassignment. We were finding that there were certain organizations who were doing detailed reassignments for all of their downstream reassignments when it would have sufficed to do a simple one, and so we are intending to make that clearer and simpler in the language.
Actually, before I go into the rest, I just want to do a bit of background. I did this in Barbados as well around what reassignment versus reallocation versus simple versus detailed means.
So, first, an allocation from ARIN means that the recipient of that block of numbers can further subdelegate or redelegate to downstream customers. So it's an allocation.
An assignment is intended to be used solely by the end user. You get an assignment from ARIN. The buck stops there. You use it in your own network.
And then -- so it follows that a reassignment is then used by that further downstream end network where reallocation can be further suballocated to other customers.
So we're talking about reassignments. So here is the redline. This is pretty clear. First of all, we're striking out "in the Whois directory," because Whois, first of all, is kind of going the way of the dodo with RDAP. So cleaning up a bit of that language, taking the opportunity there.
So "shall be registered via SWIP or a valid directory services system which meets the standards set forth in Section 3.2." So 3.2 defines what is necessary if you're a network operator and you are reassigning or reallocating addresses. So refer to that. It has to be a valid use of that. So that's clarity.
This, I'm just going to go through this. The new language would say: "Reassignment registrations must include each customer name except where specifically exempted by this policy. Reassignment registrations shall only include Point of Contact information if it's requested by the customer" -- so if a customer specifically wants to be called out with the detailed fields, information fields, then of course you can do that as a detailed reassignment -- "if requested by the customer; or the reassigned block is intended to be routed and announced outside of the provider's network."
Obviously, in that case, you'll want the abuse contact details and more detailed information.
And then because we have cleaned up this language and we've pulled out reallocations and dropped them down underneath: Reallocation registrations must contain the customer's organization name and appropriate Point of Contact information.
So here's a little screen shot of what it looks like to do a simple reassignment. So you're in ARIN Online. Select the little Simple Reassignment bullet, and here are the details you'd be asked to put in. It would just be the organization's name and then their city.
So the thinking behind this is that customers that you would give a simple reassignment to don't necessarily have the IT capacity to be able to field things like being contacted about abuse on the network or even know what ARIN or an RIR is.
And the idea is their upstream would be responsible for that kind of network management. So in those cases you would do simple reassignment.
We went through the staff and legal. John did that. I'm not going to do that again. It was clean, pretty straightforward.
The discussion on the Mailing List at the last meeting centered around -- the opposition was that this would serve to obscure bad actors, so you would only have the organization's name, and if they were being bad guys, then it would be more difficult to dig down into who that was.
And the reason that this was advanced is because there was a majority of support on the list done at the last meeting.
So, like I said, the majority of the customers with a /29 or shorter wouldn't understand what you were contacting them about anyways so go to their upstream.
Questions for discussion today: Is this appropriate contact information for simple reassignments? Do you agree this is a good course of action? And is it a step towards clarity in the language? And that's it.
John Curran: At this point, the Vice Chair will moderate the discussion of the queues. And, Alyssa, you should stay up for any questions that might come.
Bill Sandiford: Thank you, Alyssa, for the proposal. Remind remote participants to get their comments in and remind people to state whether they're for or against the proposal.
Start with the front center mic.
Cathy Aronson: Cathy Aronson. I'm probably for the proposal. Could you go back one slide? Somebody was talking, wherever I was yesterday, about the language we choose to talk about the size of the prefix. So /29 or shorter to me means that a bit shorter in prefix-y land is actually larger in size because it's a shorter --
Anyway, you're saying /29 or smaller, I would assume, so we need to perhaps use that language because it's not entirely clear.
Bill Sandiford: Rear microphone.
Mike Burns: Mike Burns from IPTrading. Could you go back a couple of slides? There was some language about requiring reassignment for customers who would be advertising their address outside the network of the underlying provider there.
Bill Sandiford: This one?
Mike Burns: Yes. Do I understand that? So the reassignment has to include the POC information if the reassigned block is intended to be routed and announced outside the provider's network. That's my understanding. And to me that's an implicit understanding that blocks are in fact assigned and allocated and routed and advertised outside of the underlying address holder's network.
And I just want people to bear that in mind as we discuss the utilization of non-connected networks in another proposal.
So, these things do happen. This is evidence that this happens, I think. And I support this proposal, would do a good job in recording relevant information for those holders who are announcing a network outside of their provider's network.
Bill Sandiford: Front microphone.
Alison Wood: Alison Wood, State of Oregon, ARIN AC. I support this policy because I think there was a bit of intimidation in reassignment reallocation, especially for the small players. And I believe this will clarify things in the future and also improve the community as a whole because we will have more accurate information on the entrants.
Bill Sandiford: Thank you. John?
John Curran: I just want to go back to a previous speaker. I have the same phobia about shorter, longer, larger, smaller when it comes to prefix sizes and address blocks. As it turns out, the policy statement in the proposed text is clear, though, because it's each IPv4 reassignment or reallocation containing a /29 or more addresses shall be.
So the policy text is clear. It was just the slide that used nomenclature.
Alyssa Moore: It was my bad. I should have typed smaller.
Bill Sandiford: Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written. I, like Mike Burns, noticed the significant change from a "shall" to a "must" when it comes to the connected networks.
I look at it a little differently. Multi-homed networks would then be required to have detailed assignments. It's not just about a non-connected. It's if you are advertising out and you have your own infrastructure and you have permission to use those blocks, you are now absolutely required.
And I think that is a fair change. I hope networks actually do implement it that way, and I think in many cases historically they have.
The one question I have related to this policy is off the first page when you made the change to us getting rid of Whois. Use the word "valid." And I guess it's a question for staff, or for down the road: Is "valid" valid technology choices? Or more importantly, in my mind, is "valid" that the systems are up and operational? And if they're not considered valid, what does noncompliance actually mean?
I'm just trying to understand that because I know we've had this discussion about RWhois servers and their lack of visibility and what the word "valid" in this particular case means.
John Curran: Could you give me the statement -- policy statement reference to "valid"?
Kevin Blumberg: If you can go back to the first or second slide, that's what I was referring to, redline -- I think it's the next one. There we go, "valid directory services."
John Curran: Thanks. So right now that's not a defined term in NRPM. So it's something that staff would end up creating language for. We would literally put on the website "valid directory service system is X."
At this time, that would be SWIP or in RWhois unless you guys want to have it be something else. I'd like the RDAP as well, I guess.
Alyssa Moore: John, I can respond to intent there. That was changed actually since the last meeting due to feedback that we should point towards Section 3.2. And so "valid" was just to say it complies with Section 3.2. That's what the intent is of the language there. But I understand your --
Kevin Blumberg: Like I said, I absolutely support this as written. I would love to see that page which then details it from the staff perspective, and I would go so far as to say valid must include the uptime and the availability of the data or it's not really valid.
Bill Sandiford: Front and center microphone.
Scott Johnson: Scott Johnson, SolarNetOne. I'm in support of this proposal in spirit. However, as a network operator, I'm unclear as to how I should proceed under a certain set of circumstances which I will detail.
So I have a customer who comes to me and I assign a -- or reassign a /29 for their purposes. I SWIP it. I make a POC for them at their request. Okay. Then three months down the road they don't pay their bill. A month later I shut them off because they haven't paid their bill.
What do I do with the POC? What do I do with a SWIPed entry? Am I responsible to modify, update, or otherwise delete that? And if I do so, or if I'm required to do so, how is that data retained and where, for forensic purposes in the future, in case they use that portion of the network to do something nefarious, and then it would come back to me later?
John Curran: I can address part of that. Part of it is if indeed you end up with a POC in the database that's completely unreferenced by any -- has no resource associated with it, then we now have an operational policy that's causing us to remove often a points of contact. So it will get swept up at that point.
Scott Johnson: And I don't have to take action?
John Curran: You don't have to take action. You should take action. You're not required to. If we said you were required to, then we'd be being disingenuous to all the people who have left all the POCs in for the last 20 years, which are now currently being swept up in the orphan POC.
So try not to create more orphans, but we'll hunt them down and kill them when we get the chance.
Bill Sandiford: Last call to join the queues. And we'll go to the rear center microphone.
Joe Provo: Joe Provo, Google, ARIN AC. I support the policy as written. I would just like to ask to have the second redline brought up to --
Bill Sandiford: Tell me when, Joe.
Joe Provo: That one. We're talking about intended to be announced outside. Nowhere does that say unconnected.
It is strictly regarding, at the time of the writing, thinking about multi-homing. Should the LIR policy come forward, obviously, it has other implications.
Bill Sandiford: Thank you. Front and center.
Chris Tacit: Thank you. I have two comments, one for myself -- Chris Tacit, Tacit Law, ARIN AC. I support this policy. I think in the larger context of trying to encourage a directory database accuracy, it's important to try and eliminate any information that we really don't need from the database and make life easier for people. So that encourages people also not making errors or just filling things in with junk.
And now I have a remote participant, Anthony Delacruz, who has the opposite view: Speaking for CenturyLink, we believe that, for the majority of our customers, the detailed is the way to go. It passes the abuse responsibility to the actual end user and sets them up to be able to configure feedback loops that require a legit, verifiable abuse contact.
We find the extra contact info with email and phone number have aided numerous times law enforcement activities.
Our systems are configured by default to set detailed on most all submissions we make, and we inform them, via the sales team, we collect and will publish this. We would not support this policy.
Bill Sandiford: Thank you. Front and center microphone again.
Owen DeLong: Owen DeLong, ARIN AC. I'll start with the last comment and work backwards. I don't think anything in this proposal prevents CenturyLink from continuing to use detailed wherever they want. It just provides better options for people who wish to not do so. So I'm not sure about their opposition in that context, and I'd invite the commenter to reconsider.
I do think that the word "valid" adds nothing but confusion in the previously discussed redline and that the sentence without that particular word stands just as well and provides less confusion.
SWIP or a directory services system, which meets the standards set forth in Section 3.2, is a fine sentence that doesn't send people looking for a definition of what is or isn't valid. It spells out quite clearly that the standards are set forth in a particular section. So I would encourage us to make that small one-word change.
That's it. I support the policy.
Bill Sandiford: Thank you. Far microphone.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. First off, support the policy as written. Second, agree with Owen's comments regarding removal of the word "valid" from the redline. I think that's a perfectly valid comment.
Completely unintentional, too.
Third, I wanted to address Scott's comments, questions about creating POC records for his customers.
And at the risk of expanding the scope of this discussion, I wanted to point out that there's another policy -- I jumped up before checking whether or not it's in recommended or recommended draft state or not -- that would restrict the creation of POC records to the organization itself.
So it may be the case, soon, that you as an ISP will no longer be creating POC records for your customers for detailed reassignments. Just be aware that may be something that, if we adopt that policy, will be coming down the line.
John Sweeting: (Indiscernible.)
Chris Woodfield: Exactly.
Bill Sandiford: Front center microphone.
John Sweeting: John Sweeting, ARIN staff. Yes, Chris, it's exactly right. It's actually already a passed policy that's being implemented as we speak. It will be deployed most likely in our March deployment.
So as of March, no ISPs will be able to create POCs and Org IDs for their customers. That will have to be done by the customer.
Bill Sandiford: Any follow-ups on that?
Chris, any follow-up remote participants?
Chris Tacit: There is one, Mark Kosters, ARIN staff: "Sadly, it is not v6-enabled."
What is that? Oh, this is -- sorry, this relates -- this isn't a comment for the -- thanks, Bill. "This is a comment regarding the IPv6 transcripts were not working on the remote participation."
Bill Sandiford: All right. At this time, we'll move forward to seeing a count of support. Get counters ready. Counters ready? Good.
At this point I'll ask those in favor of the policy to raise their hand high and hold it there until otherwise told to lower. Keep holding. Keep holding. Thank you.
And those who are against the policy as written, please raise your hand and hold it.
Number two today.
All right. We'll give a second for those who are remote, perhaps, get their comments in. I know there's a little bit of a delay there.
John Curran: I'd like to take a moment to thank Alyssa for her presentation.
Bill Sandiford: And we'll wait for the counting to be concluded. Any stand-up routines to break the silence, John? No.
Thank you. All right. Total in-person and remote participants, 126. Those in favor, 35. Those against, one.
Thank you for your feedback. It will be forwarded to the AC for their review and consideration.
John Curran: Okay. At this time we are now a little behind schedule, and it's time for a break. And people hit me if I don't give you your breaks because you have cookies and refreshment and stuff like that.
So we're going to take a break. And when we come back, we'll move directly into the second policy that we were going to discuss, which is 2019-1.
So, folks, you're on break, right outside the doors. I'll see you back here in 30 minutes, and we'll pick it up at 11:30 with RDP 2019-1. Thank you.
(Break from 11:01 AM to 11:30 AM.)
Recommended Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
John Curran: If folks would come in and be seated, we'll get started. If you folks that I'm looking at would come in and be seated, we'll get started.
Let's get started. We're going to resume our policy block. And we're going to pick up right where we were with Recommended Draft Policy ARIN 2019-1: Clarify Section 4 IPv4 Request Requirements.
Amy Potter is going to do the AC presentation, and I'm going to do the staff introduction now.
So the shepherds on the proposal are Amy Potter and Kat Hunter. It was ARIN Policy Proposal 260 in January 30th of this year. It became a Draft Policy 26 February this year. It was recommended for adoption in July this year. It was presented at ARIN 43. Was updated, latest version is 25 July 2019, in your Discussion Guide.
So the policy will change 4.1.8 and effectively outline a clear intent that organizations may only apply for IPv4 addresses if they have not received IPv4 addresses within three months prior to submitting the application.
It also creates a clear expectation that organizations applying cannot have transferred IPv4 addresses to another party within 36 months prior to the application.
The text is clear and can be implemented. No material issue. It will assist with our antifraud activities. It will require updating guidelines and internal procedures and is fairly straightforward.
At this point I'll ask Amy Potter to come up and do the AC presentation.
Amy Potter: This Policy Proposal came about as a response to some of the issues that we discussed earlier with abuse that was taking place on ARIN's waiting list for IPv4 address assignments and allocations directly from ARIN.
This was not included in the changes that were already implemented that John discussed a couple of presentations ago. This is a refinement of what we have now.
So there are two goals of this Policy Proposal. One of them is just to address some ambiguities that exist in the current language of the previous draft to clear up the requirements for the hold period.
The second goal of this is to prevent organizations that have transferred their own space to another organization within 36 months prior to applying for space on the waitlist. So essentially it prevents organizations from selling their own space and then trying to replace that for free from the waitlist.
I'll give you a second to read the current language. It's also in your Discussion Guides.
The revised language, you can check out the text in bold, says that organizations may not apply for IPv4 address resources under this section if they have received an allocation, assignment or transfer of IPv4 address resources less than three months prior or if the organization has transferred space to another party under Section 8 less than 36 months ago.
The previous version of this Policy Proposal had included a 12-month window during which an organization could not apply for the waitlist if they had transferred space to another party. The community gave us some feedback at a previous meeting and on PPML suggesting that they thought that that hold period was not long enough and ask that we extended it to 36 months, which is what we're doing here.
So our questions for you guys today are: This policy was intended to prevent an organization from transferring space under Section 8 and then immediately applying for space under Section 4 waitlist policy.
Do you feel that this policy continues to support that effort? Likewise, do you continue to support this policy as is? Do you feel that the changes that were already made to address abuse were enough? Do you think this is an improvement to that?
Really, we would just like your feedback. Thank you.
John Curran: We'll have Vice Chair Bill Sandiford come up to moderate the discussion at the queues. Microphones remain open. Amy, remain to answer any questions.
Bill Sandiford: Far right microphone.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC, and the initial author of this Policy Proposal.
Just a quick correction that this policy was authored actually prior to the waitlist suspension and the emergency PDP that resulted from that. It was originally written to address problems that were unrelated to that emergency action.
The language did have to be updated to encompass the changes made as a result of the emergency PDP, but the intent of the proposal remained unchanged.
Obviously, I'm in support of the policy. Can we go back to the language, though? I want to make one comment that might justify some additional clarification -- is the words "allocation, assignment, or transfer."
Is it possible that this could be interpreted that allocation, assignment does not necessarily mean an allocation or assignment from ARIN? Could that language be interpreted to mean if you've received assignment from like a SWIP from your ISP? Which is not the intent.
John Curran: I'm looking to Mr. Sweeting. To my knowledge, do we check for SWIP?
John Sweeting: No, because it says allocation, assignment, not reallocation.
John Curran: Reallocation or reassignment. Thought so. This would not be interpreted that way. Since you raised it, I'm going to also say it would not be interpreted regarding an allocation or assignment from another RIR.
Chris Woodfield: Interesting. Interesting point. Thank you.
Amy Potter: One thing to keep in mind also, Chris, is that we have a definition section earlier in NRPM that defines assignment, reassignment allocation and reallocation, and those definitions would apply to the text that follows here.
Bill Sandiford: Thank you. Chris.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I'm in favor of the clarification to make it clear that this only applies to the IPv4 address resources, but I'm not in favor of the additional 36-month constraint.
As I noted earlier, I think we should give the existing revised policy that was passed some time to percolate to see if we need to do anything more to it.
Bill Sandiford: Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. Can you go back to the policy text? I don't think having a discussion bubble is much use.
So we've used a couple of interesting words, "another party." I'm assuming that this is related to an Org ID. Many companies have multiple Org IDs. How does this impact where an Org ID transfers through M&A to another Org ID? What limitations does that put on them? Does the primary Org ID that did the original transfer have the limitation and the subsidiary Org ID that received the space have a similar limitation?
There seems to be a lot of gaming that could be done with this.
John Curran: I'm actually going to now guess, and then Mr. Sweeting is going to correct me. Okay?
My estimate would be that short of a whole merger and acquisition, which I'm not sure we would count for any of this, each Org ID is managed individually. So space from one to the other would be considered -- something that would be qualify.
Is that correct, John? Or would an inter-Org ID transfer not qualify?
John Sweeting: An inter-RIR transfer of resources would be included in this.
But any --
John Curran: You said inter-RIR. Did you mean inter-Org ID? An organization, a company has four Org IDs and moves space between them.
John Sweeting: I'm going to guess on this, too, and look at Lisa. We go by Org ID.
John Curran: We go by Org ID.
John Sweeting: Correct.
John Curran: So, this would encumber Orgs -- Orgs that reorganize space would be receiving transfers and would be prohibited.
Kevin Blumberg: Right. So, I have a concern that what we're trying to fix might actually create more problems in that.
This is -- again, there are different scenarios. One is to protect against abuse and fraud and all of that. But at the same time we've always been very careful not to create situations where legitimate business dealings that have to go on are encumbered.
And I'm just concerned that, based on the wording of this, we could potentially be in a situation where these Orgs who are doing legitimate M&A scenarios find that they are locked out in a way that they weren't expecting to be. The clarity here is not evident.
John Sweeting: M&A would --
John Curran: Would not qualify. Yeah, we don't consider a full M&A.
A company has three different organizations -- their wire line, their wireless, and their blimps. And they move space from one to the other.
Okay. That is a transfer space, but it's not an M&A activity. An M&A is one division buys another or they're bought by a third party. We would not consider an M&A activity in this.
But moving space between the entities would potentially disqualify one of the entities to then go and apply for address space.
Kevin Blumberg: Ignoring the word "full M&A" for a minute, Org A moves to Org A.B, one division of their company with some of the IPs. That would be done as an 8.2 transfer, correct?
John Sweeting: Correct. And it would not qualify under this. It would not be considered. It's a reorganization.
John Curran: But what they're being disqualified from is requesting new address space, which isn't a typical, normal function in today's world as we don't have a bunch of space left.
Bill Sandiford: Front and center.
Andrew Dul: Andrew Dul, ARIN AC. One thing I just noticed is we're referencing in the text 4.1.6, and I think that's an error and should be 4.1.8 because 4.1.6 is about aggregation. And this is an error in the current text as well.
Bill Sandiford: While John is looking it up, I'll remind remote participants to please register their comments. There's a little bit of a time delay in the live stream, so we don't want you to be missed. Please register your comments.
John Curran: Yes, it would appear to be overtaken by events. I'm not sure how it ended up being 4.1.6. I imagine that needs to be an editorial change to 4.1.8.
Bill Sandiford: Far microphone. Please approach the queues now if you have anything to add. They look a little thin.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC, policy author. To address Kevin's comment, I would point to the language following the change which has been in this section, which is pre-existing in the section -- I'm sorry, go back to the text -- whereas there's an escape hatch here.
ARIN does have the power to waive this restriction given certain special circumstances. So, I mean, it's not a guarantee, but it does seem that reasonable activity could be interpreted to be something that -- of the type that he's describing, that specific use case, if I was reading that request for a waiver, I would most likely grant it. I'm not ARIN staff, but that's at least my personal opinion.
Bill Sandiford: Thank you, Chris. Chris, checking in for any non-Mark Kosters remote comments. Thank you. Seeing no one else at the microphone, we'll thank Amy for her presentation, and we'll move forward with the counting.
All those in favor of the proposal, please raise your hand and raise it high.
And those opposed, please raise your hand and hold it up for the counters. All right. Counters are busy counting, tabulating the results.
John Curran: We're just killing time up here.
Bill Sandiford: I wish I had the Jeopardy! theme to cue.
John Curran: We can sing, dance.
Bill Sandiford: Nobody wants that, John.
John Curran: No one wants that. Tell a joke.
Bill Sandiford: Go ahead.
John Curran: How do you repair a broken jack-o'-lantern? Use a pumpkin patch.
Bill Sandiford: In other news, ARIN meeting hits new lows.
I see the counter approaching, The counter extraordinaire.
All right. Total participants in person or remote, 114. We lost like 20 at the break, John.
In favor, 17. Against, one. Thank you for your feedback. And it will be passed to the AC for their consideration.
John Curran: Okay. So having considered our presentations for the morning, we're now going to move into -- let's see, what do we have for time? We're doing well. A little bit of time before lunch.
Let's pick up where we left off with John Sweeting giving the Policy Implementation and Experience Report.
Policy Implementation and Experience Report
John Sweeting: All right. Good morning again. I'm going to jump right into this. Maybe we're not going to jump right into it.
I need to make a correction to my first presentation today. I had stated that no RIR had gone back for a second /12. I was incorrect. I forgot RIPE did go back in July and got their second /12, so they now have an /11.
And ARIN is actually in the process of putting together our request for our next /12. Just an update on that.
Somebody was paying more attention to my slides than I was, right, Patrick? Where is he? Tigger caught it, okay.
All right, here we go.
This is the Policy Experience Report that John had mentioned earlier today where we try to give you input on policies that have been enacted and also to point out places in the NRPM where possibly a policy change could be used.
That's kind of what this slide says. So I'm going to move right on with that. The first one we'll talk about is 4.1.8, the ARIN Waitlist that was reapproved and put back into action in July. This is actually the 4.1.8 text, which I think everyone is familiar with. So, we'll skip past that.
I just have some stats here on what happened since the implementation observation. There were 247 requests on the waitlist when distribution was suspended. There was 340 requests on the waitlist when it resumed. So if you remember it was the issuance for the waitlist that was suspended.
We were still approving people and putting them on the waitlist in accordance with the policy as it was at that time. There's been 287 requests filled since the resumption, with the shortest wait time at approximately four months.
There's actually 134 requests on the waitlist as of today. I just checked it. This was when the slide was made. And at that time there had been 60 requests added since the resumption; so it stayed consistent of our historical rate of approximately one a day getting approved and being added to the waitlist.
I have some further numbers that I got since John's discussion. We have approximately -- this is to the new entrants question that was raised -- currently ARIN has approximately 10,000 organizations under RSA, but they have less than a /20.
So that 10,000 organizations could apply and be approved if they had the right need. We also have approximately 10,000 that have IPv6 and/or an AS number but have no IPv4. So that's another pool of current ARIN organizations that would be allowed to apply and be approved under the new rules, under the new policy.
One more statistic. The date after we got the new policy enacted, we had to go through and of course re-groom the list to meet those policies.
We actually had to remove 37 organizations from the list due to them having more than a /20 aggregate of IPv4. Of those 37, 25 of them had more than a /18.
So that's it on the waitlist. The next one I'm going to bring up, I actually just saw a new proposal that came in, and for some reason it takes care of this. But it's only a proposal, so I'll still go through this.
So, right now, 4.2.2 reads that all ISP organizations, without direct assignments or allocations from ARIN qualify for an initial allocation up to a /21 subject to ARIN's minimum allocation size.
Well, that contradicts the 4.1.8 ARIN waitlist which says we can only issue up to /22. So there's a little contradiction there that can you actually get up to a /21. No, you can really only get a /22 because it can only come from the waitlist.
So the options are leave as is, staff believes that /22 is the maximum -- the /22 maximum reflects policy intent today, so that's how we're doing it. Or you can update text to harmonize the policy at /22.
So I'm happy to see that somebody has taken the initiative to put that proposal in already without even seeing my presentation. That's it. Any questions?
John Curran: Far microphone.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. Were there any waitlist requests that were removed because the request was for greater than a /22's worth of space?
John Sweeting: Yes.
Chris Woodfield: Do you know how many?
John Sweeting: No.
Chris Woodfield: Were organizations given an opportunity to modify their waitlist request if it was larger than a /22?
John Sweeting: Yes. Everybody that was approval that was still under -- that didn't have more than a /22 were allowed to stay on -- /22 or smaller. It wasn't very many. There were a few that said, no, a /22 is not going to really do it for me. I'm going to use this -- we let them use their waitlist standing as preapproval for a transfer. And I can get that number for you, though, Chris.
Chris Woodfield: Thank you.
John Curran: Any other questions for John? Okay. Thank you, John.
Recommended Draft Policy ARIN-2019-3: Update 4.10 – IPv6 Deployment Block
John Curran: We have one more policy to consider this morning before lunch, and it's Recommended Draft Policy ARIN 2019-3: Update 4.10 - the IPv6 Deployment Block. I'm going to do the introduction to this, and then I'm going to have Alicia come up and do the AC presentation.
So Alicia Trotman and Owen DeLong are the Advisory Council shepherds working on this. The history: It was submitted as a Policy Proposal 262 in February of this year. That became a Draft Policy almost immediately and was recommended in August of this year.
Recommended status I haven't talked about. So after you have a Draft Policy, if indeed we have a clear problem statement, we can have a Draft Policy. In order to be Recommended, we not only need to have a clear problem statement, but we also need to have a policy text and we have to know that the policy meets the criteria, the proposed policy text and problem statement meets the necessary criteria for advancement.
And this means it has to be fair and equitable. It has to be something that's legal. It has to actually apply to the NRPM correctly. And all that's in the PDP.
At that point, when the AC says, okay, we actually believe this conforms to a good Policy Proposal, has all the necessary requirements, they'll make it Recommended. At which point a couple of things happen. It's assured of coming to a Members Meeting, and as I've said before, you may never see it again. It may actually go from a Members Meeting to the Board of Trustees for adoption.
This is a Recommended Draft Policy. It was presented at ARIN 43. The latest version is the 20th November version. And the summary is that right now the minimum and maximum from the reserve block is /24. They may only receive one /24 every six months, and it cannot have any other allocation or assignment that can otherwise meet their needs.
The staff understanding is that no organization receive more than a /21 from this pool and that the utilization requirements are such that the policy -- you must continue to use the existing block under the terms you've got it and must be 80 percent utilized if you're going to ask for an additional one. This Policy Proposal clarifies these requirements.
It's clear and understood there's no material issues. And it's minimal resource impact because it's literally changing the requirements that are there in a more clear form. We need to update staff training and internal procedures, documentation on the website.
At this point I'm going to ask Alicia to come up and give the AC presentation.
Alicia Trotman: After that introduction, there's really not much else to say. That pretty much covers it. So the initial problem statement started with the fact that the ARIN staff had implementation issues with the current text.
The minimum allocation for the ARIN staff was a /24, but the current text, the minimum allocation was a /28. Also, the RPKI landscape also had issues with the /28, and it was more practical. It's not very practical to have a /28 in the current text.
Continue the problem statement. As you can see, minimum block size will now be a /24.
I want to get to the summary of it all. The summary, the three major changes. One, the minimum block size will be a /24 and the limit would be a /21. Secondly, it removes requirements for return and renumbering. And, thirdly, where there was a placement in there that referred to another section, it's now currently in their utilization requirements which is 80 percent. That is not directly in the text.
This was presented in ARIN 43 in Barbados. There was robust discussion, mainly around the minimum size. But we decided to keep the text as is. It's a /24 minimum. However, on PPML there was one comment that said they're in agreement with the current text.
On the 15th of August 2019, it moved from a Draft Policy into Recommended Draft Policy. And as John said, this may be the last time that you would see it. It would go to final call.
The comments from the staff was clearly understood. There were no red flags, no major issues. The resource impact would be minimal. And pretty much, that is it.
The question to the community is: Are we still in agreement with this change in text of this policy?
John Curran: The Vice Chair will come up and moderate discussion from the floor. Alicia, you should stay up to assist if any questions come up.
Bill Sandiford: All right. Thank you. Front and center microphone.
Aaron Hughes: Good afternoon, Aaron Hughes, 6connect. Just as a friendly reminder of why the /28 came to exist, I think I was the one who suggested it many years ago, and that was around the idea that for new v6-only networks, they still need 32-bit unique identifiers for routers, router IDs, et cetera, and arbitrarily picked 16 host as a small network receiving the v6-only allocation.
So it wasn't ever intended to be routed. It wasn't intended to have reverse DNS. It was simply for 32-bit unique identifiers. There are cases where that would be just wasting space if you're putting in a v6-only network.
Still in support of it. Just wanted to remind people why it was there.
Bill Sandiford: Thank you. Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I support it. Kinda funny, I was the author of the proposal that basically did the same thing a couple years ago where it was abandoned. But times change.
And I think actually this policy, 4.10, should be the new entrant policy at this point. It meets all those criteria. And this is sort of the final thing that does it. You get a small amount of space. The caveat is you need to do v6 with it.
This sure looks like the new entrant policy moving forward. And I hope we can expand that /10 and take some of the waiting list space before it gets into there and put it into 4.10.
But for this policy, I support it as written.
Bill Sandiford: Thank you. Rear microphone.
Lee Howard: Lee Howard, IPv4.Global. I have two questions before I can figure out whether I support or oppose. The first is what does -- in the examples given, what does NAT-PT have to do with IPv6 deployment?
John Curran: So, in the text there's a -- it says if you need this in order to assist your IPv6 deployment, and has illustrative examples. We don't exactly pin people down. If they can show a technology and how you having a v4 block assists them in that, we go along with it.
I'm not wedded to any particular examples in the text, and while I could envision a circumstance of using NAT-PT for that, that would be a pretty bizarre scenario.
So if the community wants to have better examples listed or no examples, that's fine. We actually treat each one on a case-by-case basis. We ask someone, show us your architecture, tell us where you're going to use the v4 addresses, and show us how it supports v6.
Lee Howard: My second question was going to be about whether key dual-stack servers meant resolvers or auth servers, but I think you just answered the questions to say these are examples.
So I think that I'm happy with the rest of the proposed policy as it stands. I'm unhappy with the examples. Thanks.
Bill Sandiford: Noting the queues are empty, I would invite you to approach them now if you have anything further to add. We'll check in on remote participants.
Chris? Nothing from any remote participants? Going once, twice.
All right. Thank you for your presentation.
And we'll now move on to the show of support.
So are my counters ready? One, two. They're there.
All those in favor of the proposal, please raise your hand high.
All right. Those opposed, please indicate so now.
Give a moment for any delayed remote participants.
John Curran: Why did the ghost float into the bar?
From the Floor: Why?
Bill Sandiford: Tell us, John, why?
John Curran: For the booze.
(Laughter and boos.)
Bill Sandiford: The rapidly approaching gentleman to the far microphone.
Martin Levy: Point of order, Mr. Chairman, could you put some control on your -- on the esteemed gentleman to which is given mic time?
Bill Sandiford: I'll do my best.
We've gained five people. Total in person and remote participants 120 participants. Those in favor, 29; those against, one.
Thank you for your feedback. It will be passed to the AC for their consideration.
John Curran: We have a little bit of time, and one more presentation that we had slated for this morning was a presentation about the IPv6 outreach. We've had some people say: What is ARIN doing to promote IPv6? We thought we'd summarize that and put it in front of you.
So, I'm going to ask Richard to get up and give the summary of our IPv6 outreach to the community and get your feedback.
History (and Future) of IPv6 Outreach at ARIN
Richard Jimmerson: Thank you, John. My name is Richard Jimmerson. I'm going to talk a bit about IPv6 over the decades at ARIN. We started in the 1990s. We're getting ready to go into our fourth decade of IPv6 promotion inside this community. That's pretty staggering.
What's coming in the 2020s, next year. Yes, it will happen. You've got to see the slides at the end.
So of course we started in the mid-1990s. There are people in this room that were involved in the IPng project back in the mid-1990s when we were talking about IPv4 running out. People heard in the mid-1990s that IPv4 would be gone very soon.
And that really worked against us, about 20 or 15 years later, when we were telling them, no, really it is running out. And they said: Yeah, I've heard that before. I don't want to hear it again.
But in 1999, the IETF had created IPv6 and delegated an eighth of the entire IPv6 address space to IANA for further issuance to the three -- the then three Regional Internet Registries.
ARIN received its first block, and we pretty quickly made our first IPv6 allocation to ESnet using an allocation framework that had been recommended by the IETF, because at the time the policy hadn't put together or the community hadn't put together policies on how we would issue that space. So the IETF gave some recommendations on how we would do that. You remember them: TLA, sub-TLA, NLA, SLA.
Then we got into the 2000s. ARIN began its outreach right in 2000 at these meetings. 2001, the IAB and IESG published a recommendation on IPv6 allocations, and then the policy community actually started doing policy work.
So basically the IETF came and said: These are our updated recommendations on how you should issue this space. And they invited the policy communities in each Regional Internet Registry to start having discussions with each other about how they think that that should change in each of the regions. And we began that work.
2003, the Board began implementing fee waivers for IPv6. And that happened throughout the years.
Also in the mid-2000s, the ARIN staff, ARIN AC began conducting outreach, including trade shows and industry conferences. And I'll talk more about that in a few minutes.
The Board passed resolutions advising the Internet community on migration to IPv6. We opened an IPv6 wiki. We started talking on social media about the need to pay attention to IPv4 depletion and to adopt IPv6.
And the organization actually sent certified postal letters from ARIN to every member executive with notice of IPv4 depletion and the need to adopt IPv6.
Just in case they weren't seeing it, in the footer on every ticket response that we send out from ARIN that said this was coming and this was happening. And this was a big due diligence effort inside the organization. We did not want to reach depletion inside the ARIN region and have organizations come to us and say, "We had no idea that this was happening."
So we wanted to create a state where that was not possible. And we didn't get any of those emails, by the way, when we did finally deplete the IPv4 address space in 2015.
Early in the 2010s, we launched TeamARIN. We had a speakers' bureau, outreach calendar. We had a community-use slide deck that people could download. And we would actually ship people a care package of stickers and handouts and those types of things if they wanted to promote IPv6 inside their own community groups or inside their own organizations.
In 2011, the IANA exhausted the global IPv4 free pool. They had no more /8s or Class As to hand out to the Regional Internet Registries. We each had our final block of IPv4 address space from the IANA.
And we started doing contests and other outreach. ARIN and the other Regional Internet Registries participated in World IPv6 Day and the year after that World IPv6 Launch. The Internet Society used their convening powers to bring people together and do these two great events early in the 2010s that made a big impact on deployment inside the community.
In 2014 we kicked off new campaigns for IPv6-enabling web content because before that we were really concentrating on vendors who were putting IPv6 support into their hardware products and also on Internet service providers.
Again, in 2015, ARIN did run out of their IPv4 free pool, and we started the waiting list for unmet requests.
In 2016, we started building a list of hosting and DNS providers that supported v6 and v6 trainers and consultants. We started publishing case studies a few years ago, in 2017, and we continued to do that today. And we've gotten a lot of community support on those.
And earlier this year, for the first time, ARIN created a grant program. And one of the ways that you could be considered for a grant is if you were -- you could get funding for information outreach related to IPv6 deployment. And one of our grant recipients was specifically doing that for IPv6.
Some examples of the types of things that we've done throughout the years: Still in a lot of booths, went to a lot of events, and talked to a lot of people. I think there are probably people in this room that volunteered their own personal time to come with ARIN to these events.
There are probably people right here who could raise their hand if I asked the question: How many of you gave up four days of your life going to a CES, not to just stand on a booth, but to walk booth to booth from all -- for all the other vendors with a clipboard in your hand wherever you had to go, and you spent 12 hours walking, four days straight, just talking until you couldn't talk anymore to vendors pleading with them to put IPv6 support into their products?
How many people here actually did that, if you could raise your hand? Some of you are still in the room.
From the Floor: Bill Sandiford --
Richard Jimmerson: Yes, he did, actually. I remember talking with Bill Sandiford the first day they came to do one of these events. He couldn't believe we were actually doing it. And then he proceeded with actually walking 12-hour days to booths four days in a row. It was amazing.
And there are others of you in the room that were working with ARIN, but you were running your own independent efforts to promote IPv6 adoption in the community. I can see a few of you in the room right now.
But all of these things here involved all of you in the room, and some of us who aren't still here today at the meeting, getting these things done to support the effort.
And of course, the ARIN Board over the years has made sure that the ARIN organization itself has ate its own dog food in relation to IPv6.
So what are some of the impacts? Now, all of this work that we did together as a community, we played a part in these impacts that you see here. But there are so many other people who have done the same thing. 59.5 percent of ARIN members have IPv6 allocations today. 26 percent of our end user customer organizations have IPv6 assignments today.
Over 6,800 total IPv6 blocks have been allocated or assigned. We've got over 51,000 /32 equivalents allocated. And we have 3.2 million /48 equivalents assigned and there are 172,000 total IPv6 reassignments and reallocations that have been made.
172 reassignments have been made. If you're going go through the trouble of getting an IPv6 block directly from ARIN, that's great. Doesn't mean you're deploying it the next day. Might not even be the next year, just needs to be in the next couple of years.
But if you're going to go through the trouble of actually creating reassignments in the database, that means you're doing something with that IPv6 address space. We have over 172,000 of those, and 61 percent of those were created just since the beginning of 2018.
There seems to be a lot more activity than usual. If you look at the snapshots of some of the data that other organizations are providing, right now today this meeting is inside the United States, so we feature the United States.
Google says 36 percent of all the traffic that goes to their services comes over the v6 network. Globally, 28 percent.
Facebook says it's 56.5 percent from the US, and 25 percent globally. And Akamai says it's 48 percent in the US and 22 percent globally. And they keep this updated on a regular rotation at each of those websites there if you want to check that out.
If you raised your hands earlier or did anything to support the effort over the years, I want to tell you it could not happen without your volunteer time. You guys support this organization. You have staff members that went out and facilitated this.
We were getting paid very specifically for doing that. You guys that raised your hands in the audience, you didn't. You actually volunteered your own time to do this, and we really do appreciate it. And I think you guys do deserve a round of applause for everything you did over the years.
Now, I don't think that we're going to go do reverse exhibiting at CES again. I don't think that will happen again. And there might not be time-intensive things like that needed again going into the future. But we still need your help because IPv6 isn't all the way there yet.
We know that. There's still more that people need to hear. The ARIN organization itself plans to sustain the current level of outreach with our IPv6 case studies and some other work that we're doing in the area.
We're adding IPv6 training programs. The ARIN Board of Trustees has asked the ARIN organization to stand up training this year, and we're aggressively working on that.
And we'd like to hear more from you if you think even more than that is needed. And so what we're asking is if you have any ideas about what you'd like to see at ARIN going forward to further promote IPv6 adoption or deployment, please send us an email at email@example.com. And thank you very much.
John Curran: Any questions for Richard or regarding our IPv6 outreach? Okay.
Richard Jimmerson: We've got Paul Wilson coming up to the mic.
John Curran: The esteemed Paul Wilson.
Paul Wilson: Thank you. It's the esteemed Paul Wilson from APNIC, for the record.
It's an interesting perspective to talk about going into the fourth decade, but it does sound like we might have been carrying on about IPv6 for 40 years, which isn't right.
So I just thought, for the record, it's worth saying we've been doing this for 20 years. But as you know, Richard, what we spent the first decade doing was countering of a whole lot of crap that was going on about the imminent exhaustion of IPv4 and the urgent need to get IPv6 started and the fact that it would cure world hunger and all sorts of stuff.
And so we spent our time pointing out that nothing really big was going to happen until IPv4 ran out, and that that was going to be happening around the middle of the 2010s, I think. I think we got it pretty right.
Richard Jimmerson: We did.
Paul Wilson: And we spent our time preparing our communities and making sure they understood that the time to move was not yet, but when they wanted to move, they would need to move with some knowledge that we could help to provide them.
And the end result of that process was actually that we started to see this, like, pretty -- very substantial IPv6 deployment happening at about the time that we always said.
So, I just wanted to sort of point out it hasn't been quite the 40-year hard slog that you mentioned or that your words might have been interpreted as, and in fact a lot of what we did in the first decade was damage control against a whole stack of crazy talk about the need for IPv6.
Richard Jimmerson: Indeed.
John Curran: I was going to say, Paul, the RIR portion of it has predominantly been the last decade. Truly that's the case. And while the IETF and the vendor communities, all the operating systems and equipment, started it earlier. And certainly it took a bit of time to get the software in all the right places. The role of the RIR has been in the last year.
On the other hand, it's also true that if we're not aggressive, we're not sure how many decades we will be at this. So the question is, how much more should we be doing and how do we go about doing it, because for some people there's a real barrier of having to maintain both v6 and v4. There's a cost, and we're not sure we want -- does the community want that cost? And if it doesn't want that cost, how does it want ARIN to help get us to the other side?
Paul Wilson: I can't say what the ARIN community wants you to do, but the APNIC community for the last 20 years has had -- well, up until about probably five years ago has had IPv6 at the top of the list for what they asked APNIC to help with.
So we all worked together on that. And, Richard, your presentation is a really interesting perspective on what's happened over that 20-year time. As it happens, for our community, v6 has gone to the second on the list after security. So that's the -- but it's still well up there and we've got some detail about what they want us to do too. Look forward to continuing to work with you guys on it.
Richard Jimmerson: Excellent. Far mic.
Kevin Blumberg: Kevin Blumberg, The Wire. Appreciated the memory lane. Something I don't know if you remember from CES was keeping the daily tally of number of people that invented the Internet that would come to the booth.
Richard Jimmerson: Yes, I do remember that. We'd have people come to the booth and tell ARIN that we're newcomers because they had admitted portions of the Internet. And in some cases it literally was, like, Vint Cerf or something coming to the booth.
But in other cases it was just interesting, all the people that came out of the woodwork that wanted to let us know about those things. But it was a good thing. We were looking for people to talk to.
Kevin Blumberg: That was the humor, but from the training perspective, there are a lot of organizations that can help with how to configure your routers. There's a lot of organizations that can help with the technical side of IPv6.
What I am amazed by and constantly see, which is the one thing that ARIN is best suited for, is how to properly network out with IPv6 -- not the physical touching of the routers and the NetBlocks and all of that, but actually coming up with workable plans that an organization doesn't find themselves two years after deployment having to start over again and ripping out their hair at that.
And I would just suggest that the areas of expertise that ARIN has, to focus on that with training. There's a lot of stuff. If an organization wants to go down this route, they will get the help on the other things.
But we have to get out of the mentality of scarcity. And that, in this room, is undoing decades of learning. And that's the same in industry.
John Curran: Okay. Thank you. Thank you, Richard, for that great presentation.
Okay. We're going to move into lunch now. And we have a number of training -- number of topics at the lunch table. When you go to lunch, it's down in Lone Star Salon D. If you see a topic you are interested -- like PDP and PPML participation, waitlist elimination, RIR assignments for non-connected networks, training at ARIN -- gravitate to those tables, people of similar mind.
So the meeting room, is it locked, unlocked, secure? We'll have people here? We won't? Take your materials with you. Okay.
We'll see everyone back here promptly at 1:30. You have about one hour for lunch. Look forward to seeing you back. Thank you.
(Lunch break taken at 12:22 PM.)
John Curran: Okay. If folks will come in and be seated, we'll get started. I'd like to welcome everyone back. If you have a chance, remember to go out and turn your ticket in to get your shirt, your ARIN 44 shirt. Very important to do.
And remember tonight we have a social at Maggie Mae's. Walking distance. So bring your badge.
If you are bringing a guest to the social, go to the registration desk and buy your guest ticket. If you've paid for a guest ticket, go pick up your guest ticket. Again, everyone who is attending from ARIN, you're all set. But if you have a guest, you have to get yourself a ticket for the guest at the registration desk.
Our afternoon agenda consists of an Election Overview, and then we're going to have candidate speeches from the candidates up for election.
And then we're going to have a Board Candidate Forum, something a little different. We're going to pose questions to the Board candidates. These are questions that were submitted and prioritized by the community, and you get to hear them each speak on their thoughts on that question.
We're then going to pick up after that with the policy. Policy, we have -- making sure I'm in the right order here -- yeah, okay. So don't actually have policies until after the break, but we'll have policies in the afternoon. 2019-8, 2019-10, 2019-15 and 2019-17 are all up for consideration in the afternoon policy block.
We'll then have an open microphone, and then we'll have our close. So, Election Overview, candidate speeches, the candidate forum, a break, and then a policy block after the break.
So at the head table is me for the candidate forum. And we'll actually now have Wendy come up and give an overview of the election process.
Wendy Leedy: Thank you, John. Okay, good afternoon, everyone. Thank you very much for joining us. As John mentioned, my name is Wendy Leedy. I'm the Member Engagement Specialist for ARIN. And I'm pleased to be here with you today.
Part of what will take place over the next several minutes is I'm going to quickly walk you through how ARIN elections take place. But before I begin, though, I'd like to take a moment to acknowledge ARIN's members and to thank each and every one of you for being a part of our process and our community, especially during election season.
I would also like to thank those who have volunteered and those in our community who regularly participate, and a special thank you to the 2019 Nomination Committee.
Now, let's get talking about ARIN elections. Each October, eligible General Members in Good Standing have the opportunity to vote in ARIN elections. Beginning today at 3:00 PM Central -- which you will see on a slide here in a moment, it says 4:00 PM Eastern time -- the ARIN elections will open to all eligible ARIN member organizations' designated Voting Contacts, who on behalf of their organization, will cast a ballot to elect a representative to ARIN's Board of Trustees, Advisory Council, and a representative to the NRO Number Council.
Now I'm going to highlight key voting details. To be eligible to participate in this year's elections, an organization must be a general member in good standing. This includes no outstanding invoices as of this year's voter eligibility deadline, which was September the 16th.
An organization must also have designated an individual as a voting contact who has an ARIN Online account. This year, 4,769 eligible Voting Contacts representing over 5,160 ARIN organizations will have an opportunity to elect two members to the ARIN Board of Trustees, five representatives to the ARIN Advisory Council, and one candidate to the NRO Number Council.
As I mentioned a minute ago, voting will open at 3:00 PM Central, which is also 4:00 PM Eastern Time, on today, Thursday, October the 31st.
Voting will close promptly at 6:00 PM Eastern time next Friday, November the 8th.
Voting details. You will have the opportunity to vote from the convenience of your office or home computer and on your mobile device.
As you will see, the steps necessary for casting your organization's online ballot are quite simple.
There are four simple and quick steps that you need to take. First, visit www.ARIN.net. Then you will need to log into your ARIN Online computer. And then you'll click -- if you're an eligible designated Voting Contact prior to the September 16th deadline, you will click on the "Vote Now" link that appears on your dashboard, and then you will cast your ballot. In just a moment I will actually show you what the screens look like.
I also want to take just a moment to talk about key election dates. Beginning in July, July 15th, specifically, through August the 22nd, we had our call for nominations. The call for ARIN Board of Trustees nominations was extended and reopened August the 30th and then concluded on September the 4th. The deadline to, again, establish voter eligibility was September the 16th.
Our initial slate of candidates was announced in addition to a call for petition and the statements of support opening on September the 23rd. The intent to petition deadline was September the 30th.
As of this year, we did not have anyone who expressed an interest in petitioning. And so the final slate of candidates was announced on October the 9th. We technically had until the 21st of October, but due to the lack of petitioners this year, we were able to release the final slate earlier.
The NRO Number Council election opened for NANOG and ARIN meeting representatives this Monday, on October 28th. If you're a meeting attendee and not necessarily an eligible voting contact, you should have received an email with a unique link to cast your ballot. You still have time to do so. And the voting for that particular election will close at 6:00 PM on Friday, November the 8th.
Voting for eligible ARIN Voting Contacts opens this afternoon 3:00 PM Central time, and elected representatives will be announced the week of November 11th.
As I mentioned, it's quite easy to cast your ballot. Step one, you're just going to go online to ARIN's home page. In the upper right-hand side, there is a login key. Make sure you click on that.
It will then take you to your ARIN Online registration page where you will enter your username and password. From there, again, if you are a designated eligible voting contact, you will see at the top of your dashboard the message that says "Cast Your Ballot," that the elections are open, and you'll want to click on the "Vote Now" button.
At that point, once you do so, it will take you into our election software. You will see a transparency agreement. You should click the "I agree" in order to participate in the elections. If for any reason you click "I disagree," then you will, unfortunately, be ineligible to participate in this year's elections. But please take a few minutes to read the transparency agreement to ensure that you are in compliance with what is being stated.
The voting process. So just a tip, a Voting Contact for only one eligible ARIN member organization will see a vote number or a vote weight of 1. That is typical for the majority of our eligible voting contacts. A voting contact for more than one eligible ARIN member organization will have a vote weight or a vote number greater than one on the screen that you see here with the arrow.
Reducing your vote weight is optional. Again, if you only have a vote weight of 1, that will not change. You will want to go ahead and select your candidate and submit your vote.
Vote weight options. For vote weight options greater than 1, you can leave your vote weight or vote number as is if you wish to cast the same ballot in the same election multiple times. Otherwise, if you change your vote weight, it will afford you the opportunity and take you back to the ballot where you can change the number and cast the same ballot or multiple ballots based on what your preference is.
And this is talking a little bit about vote weights greater than 1. Again, change that number and submit your votes. Again, if you change it and you still have votes left, it's going to turn around and take you back to the election that you're currently in, whether it's Board of Trustees, the Advisory Council, and you can change your votes and then recast your ballot.
For the voting process, as I mentioned, just pay special attention. If you have a vote weight greater or vote number greater than 1, make sure you select your candidates and then click the submit votes.
From there, once you do so, our election software is set up that you will need to confirm your selection. So please take a few minutes to make sure that the candidates that you selected are the ones that you wish to support.
If so, you will click the "Confirm" to cast your ballot or you will click the "Back" to revise it.
Once you go through this process, what's important to remember is once you have submitted your ballot, it cannot be changed under any circumstances. So please make sure you take a few minutes to ensure those that you have selected are the representatives in which you wish to support.
The voting process reminders. Complete these steps again for the ARIN Advisory Council and for the NRO Number Council.
This next slide really just provides you with an overview of how the ballot looks. Each ballot addresses whether it's the Advisory Council, the Board of Trustees or the NRO Number Council.
Once you have cast your ballot, you will receive a vote confirmation email. It will provide you with the information of who you voted, if you have more than a vote weight of 1, what the number is. And you will want to retain this.
You will receive multiple vote email confirmations for each election that you participate in. So that's going to be for the Advisory Council, the Board of Trustees and the NRO NC if you participate in all three.
You will also receive another email that just thanks you for participating in the ARIN elections. And, again, we'll have more information as it relates to your vote for your records should you have any questions.
Some reminders for ARIN elections. Remember that the ARIN elections 2019 Voter Guide is available in PDF form. It's a wonderful resource if you're looking to learn more about the candidates that are running for each of the positions that are open. Please take a few minutes to review that.
New this year, this was the first year in several years we did not mail a hard copy of the Voter Guide. We are being conscientious of the environment, so please take a few minutes to check out the PDF online. You can find it on the election headquarters webpage.
If you're interested in reading and making statements of support, please take a couple of minutes, visit the ARIN elections home page. There you can read what other individuals have said regarding the support that they put behind the representatives they believe that are best to fill the positions that are open.
And you also have an option to submit your statement of support for a particular candidate. You don't have to be an eligible Voting Contact. You can be a family member, friend, colleague; but please take a few minutes to review that information.
And most importantly, please take time today, if you're the eligible Voting Contact, to log on to your ARIN Online account, click the "Vote Now" link, and cast your ballot. You have from today, 3:00 PM Central time, 'til 6:00 PM Friday, November the 8th, to cast your online ballot. And polls will close sharply at 6:00 PM.
In conclusion, one last statement I wanted to point out: If you're an eligible Voting Contact, next week you can anticipate to receive a call from an ARIN representative who will be reaching out to not only thank you for your participation and support of the community, but kindly reminding you to cast your ballot if you haven't done so.
Thank you very much for your time. We look forward to your participation. And thank you for being a part of our community.
John Curran: Thank you. Any questions for Wendy?
Louie Lee: Hi, Louie Lee, Google Fiber. Thank you, Wendy. If I happen to be the eligible Voting Contact and I attended NANOG, then my vote only counts once, right?
Wendy Leedy: That's correct.
Louie Lee: And if I'm not the eligible Voting Contact, I can still vote separate from the eligible Voting Contact?
Wendy Leedy: That's correct. Thank you for that clarification.
John Curran: Thank you, Wendy.
Advisory Council, Board of Trustees, and NRO NC Candidate Speeches
John Curran: Okay. Next up we're going to hear from the candidates. So we're going to go through the candidates for the NRO Number Council, then the candidates for the ARIN Advisory Council, and the candidates for the ARIN Board of Trustees.
Most cases we have them here. If we don't have them here, I'll either read their bio or they've been offered a chance to provide a video. We'll provide the video if they offered a video instead.
So starting right out, I believe first I have the NRO Number Council. And so I'm going to invite each candidate up for the NRO Number Council.
First up is Mr. Aaron Hughes of 6connect. Aaron, if you want to come up and talk a bit about why you're running for the NRO Number Council.
Aaron Hughes: Hello, good afternoon. My name is Aaron Hughes. For those who don't know me, I'm the President and CEO of 6connect. I've spent quite a few years serving on nonprofit organizations, mostly on boards and in many cases chairman of the board.
As part of my service in the ARIN region serving on the Board for two terms, six years, I started spending a great deal more time in all of the RIR meetings. So I currently spend time with all five RIRs, understand all five Policy Development Processes, and certainly have been part of global policy development over the course of the years.
When I came to understand that Jason Schiller wasn't going to be running, I realized there were some very big shoes to fill and thought it was appropriate for someone like myself, with my experience, to step up and fill those shoes. And thankfully I have rather large feet.
So, I'm here to say that I'm more than happy to serve in this community. I'm certainly intimately familiar with MoUs and SLAs, happy to continue the process and step into Jason's shoes. So I'm here to ask for your vote. Thank you.
John Curran: Next up for the NRO Number Council, I'd like to have Martin Hannigan. I believe Martin had to sneak out. So I will read his bio, as we don't have a video.
Martin Hannigan is the Founder and Chief Executive Officer of Deep Edge. He's had long-term involvement with ICANN, the RIRs and the NRO/ASO AC. He served in the community, in the ARIN region as NANOG Mailing List Chair, NANOG member, ICANN NRO NC, ASO AC, representative from the ARIN region from 2006 to 2010. CaribNOG participant. ICANN Security, Stability and Resilience Review Team member.
He was on the ARIN Advisory Council from 2011 to 2012, ICANN GNSO Registries Stakeholders Group member, Toronto IX vice president and director, Open-IX founder and director, founder of the New England Peering Forum. His LinkedIn profile is at the bottom of the page.
And the third candidate is Dave Täht. David, come up and say a few words about why you're running for the NRO NC.
Dave Täht: Thank you, everybody. I'm Dave Täht. I'm running for the NRO. A bit about me. I run a little company that does WiFi -- anybody here use WiFi? -- software development, R&D, home routers, and middle boxes primarily.
I just came here from the third world -- California.
I just spent five days without power. Comcast went down immediately. My T-Mobile backup failed after half a day. And the only thing that stayed up was Verizon. Needless to say, my IPv6 connectivity did not survive the first minute of the outage.
I've been working for many years to make the Internet faster and more reliable and resilient. And I would have liked it if last week's experience had been less stressful. I'm primarily a technologist.
Running for the NRO was my first excursion ever into a policy-making body. I do sit on the board of the Commons Conservancy, and I've worked in Nicaragua and a few other places, trying to make better software to work better along the edge.
Anyway, perhaps the thing I'm best known for is for helping fix the bufferbloat problem. How many people here have heard of bufferbloat? How many people here have actually fixed it on their networks? We have a long ways to go there. But most of you are running the software and algorithms that we developed at this point.
Our core bufferbloat-beating algorithm is called FQ-CoDel (RFC8290). It's on iOS, OSX, Linux, et cetera, as the default, and in many home routers today. Except it's mostly in the wrong Billion routers. Still trying to get that deployed along the edge.
But today is the first time in a long time I'm not here to talk about bufferbloat. The principal reason why I came here today was to talk about something called the IPv4 Unicast Extensions project, which John Gilmore and myself and a few other people have been working on for about a year.
We're trying to add back 240 million new IPv4 addresses to the Internet, and we've made a lot of progress in the free and open source world to making that happen.
And there are a few policy implications were this project ever to succeed. So I thought I'd come here and talk about that a little bit and then conclude by going to my last part.
Before I'm pilloried for the idea of extending IPv4, I'm still very much involved in the IPv6 processes with multiple RFCs, et cetera. And I've contributed to and included things like IETF Homenet -- anyone ever heard of that? That's part of the problem -- and sourced address dependent routing.
So I thought getting here today and seeing what the real problems were in the RIRs and the ARIN community and trying to understand what the policies and deployment problems actually were and to try and attempt to use my technological expertise to see what I could do to resolve them was a good idea.
And overall I'm trying to get involved with the NRO and ARIN. I'd really like to help develop a more reliable, more resilient Internet. Thanks for your vote.
John Curran: Thank you, Dave.
Okay. So that's the NRO Number Council candidates. Now I'd like to move on, talk about the ARIN Advisory Council candidates.
First up is Tina Morris. Tina, come up and say a few words about yourself.
Tina Morris: Hi, I'm Tina Morris. I work for Amazon Web Services. I run IP address strategy for Amazon and affiliated parts of the company and subsidiaries.
Rather than going through my whole CV, I thought I'd just focus on what's changed since my last election speech. My team at Amazon basically runs internal RIR. We have a few resources, and they need a lot of care and feeding. So I do this as a full-time job, focus on number strategy, v4. V6 deployment is actually a huge part of my job, but it doesn't get the press that the v4 does.
In this role, I also deal with the transfer market quite a bit. And I do number policy in all the regions. So I understand the processes that we see there.
The truth is I don't really enjoy policy. I find it frustrating and all that. But it's incredibly important to our community, and I see the value of keeping the IP address resources and the ASNs open for everybody, whether you're a big company or a small company, and I want to continue to do that work.
I think my unique perspective is helpful to that room, to the 15 people who are collaborating to build policy.
I've been coming to ARIN since 2009. It's my sixth year on the Advisory Council, my second year as the chair of the Advisory Council.
I've also been serving on the NANOG Board for two years as vice chair. I really struggled with the decision to run for a third term. I believe in term limits and transition and bringing new faces on to the AC.
So I decided to do one more final term, with the idea I have a few more improvements I'd really like to make. I'd like to work on succession planning, mentoring and, frankly, helping the wonderful people I serve with collaborate better and keep a strong, unified Advisory Council so they can do their good work. Thanks.
John Curran: Thank you, Tina. Next up, Joe Provo.
Joe Provo: Hi, I'm Joe. This is the end of my first term, and I'm not going -- my first three-year term -- I'm not going to regurgitate what I put in the slide here or what we have in the questionnaire.
I will point out that since I answered the questionnaire, internal reorganizations mean that I will be in charge of a subset of numbers management at my company as it relates to the corporate network. So very small compared to the overall thing. And that work is in transition. Just full transparency.
I build networks. I like to build things. To Tina's point, policy work is not fast. You can build networks much faster than you can develop policies.
But that's good. Community engagement to build consensus takes time. And I'd like to think I've been doing that consistently, routinely seeking out feedback on the mailing lists, face to face, and by private mail.
But the time it takes to build consensus isn't an excuse to procrastinate. To wit, when our colleague Mr. Dul pointed out the typographic error this morning when we were talking about a policy, before he sat down I had already submitted a correction policy because simple things like that should just move swiftly.
I've been shepherd and co-shepherd on several policies, including some more editorial cleanup and simplification. And I still see several opportunities for further simplification, such that our overall community, not just the people who are invested enough to come here and wade through the language, can be more involved in the process.
I have strong opinions and will represent them when in deliberations, but I can compartmentalize well. My opinion sometimes runs counter to the will of the community, but I'm up here to represent the will of the community, so when there's an instance where they're counter, I support the will of the community. There's several examples of that in the voting record available in the AC minutes, like ASN transfers, for instance.
I don't really have anything else. That, I think, sums it up. I would be honored to continue to be able to serve and have your vote.
John Curran: Next candidate for the Advisory Council, Alyssa Moore.
Alyssa Moore: Hello again today. I'm completing my first term on the Advisory Council. And I know that everyone in this room is a special brand of nerd, and that's part of why I love being here.
But my particular special brand of nerd is all things Internet governance. And my first love in Internet governance is Internet numbers, and that's kind of what got me started on my Internet governance career path.
When I was first elected to the AC, I worked at a nonprofit network operator, the research and education network operator in Alberta, Canada: Cybera.
Since that time, I've moved to a new position. I'm now the senior policy and advocacy advisor for the Canadian Internet Registration Authority, also known as CIRA, and we run the .ca top-level domain.
In my work there, I'm primarily responsible for our engagement at ICANN. So I get to experience the full gamut of both names and numbers policy through my day job and my volunteer work here at ARIN, which is awesome. I love it. And I think it also makes me a bit unique in this space that I do have that broad experience.
I'm also responsible for things like advocacy and positioning my organization as a champion and an expert in a stable, secure, interoperable, trusted Internet. And I do a lot of government relations in the day job as well.
So in my first term on the AC, I have learned a ton. And I'm so grateful to so many in this room for being just fantastic mentors. And I've also had the opportunity to serve as a mentor to fellows, which I find to be super rewarding, given that I started here as a Fellow as well.
I've had the opportunity to work on a number of policies as a shepherd, but my primary interest is in those that work towards improving registry accuracy and, similar to what Joe mentioned, increasing clarity of the language for folks who have to use the NRPM but aren't necessarily engaged in the nitty-gritty of what we do here.
So, with that, I will just ask for your vote for a second term. I would dearly appreciate it. Thank you.
John Curran: Next candidate for the ARIN Advisory Council is Owen DeLong. Owen, come up and say a few words about why you're running.
Owen DeLong: Likewise, I'm not going to regurgitate this slide. I've been on the Advisory Council now for 12 years. I'm hoping to get another three serving this community. I think I've been a good advocate for the community, and I enjoy interacting with all of you and hearing what you want and what you feel needs to be fixed in policy. And I hope you'll allow me to continue working on that. I ask you for your vote.
John Curran: Next candidate for the ARIN Advisory Council, Steve Wallace.
Steve Wallace: Greetings, everyone. My name is Steve Wallace. I work at Indiana University and Internet2. My entire adult career has been with Internet2 and Indiana University.
I am supporting networking for the research in education community. For the last six months, I've focused on outreach efforts, mostly Internet2 outreach efforts, to improve the adoption of RPKI and IRR within this community. I want to thank Google for producing a deadline to help motivate people in that direction.
I have a superpower, but it's a superpower that many people in this room and I'm sure all the candidates have as well, which is I enjoy reading things like the NRPM.
I enjoy understanding technical documents and policy documents and trying to clarify them and improve them and add to them when there's good stuff to add.
And just as evidence of this, at 6:00 AM this morning, I was reading, and this is just a riveting document, the Draft NIST Special Publication 800-189. It's actually a really good document. A recent draft emerged, has to do with routing security.
So if I'm elected, I'll do my best. The role of the AC member aligns with my interests and passions, and I would appreciate your vote. Thank you.
John Curran: Okay, next up for the candidate for ARIN Advisory Council, come on up, Alison Wood.
Alison Wood: Hello, everyone. I'm so honored to be standing before you today. I'm running for my second term on the ARIN Advisory Council.
Over the past three years, I've had the privilege of working with many of you. I've worked on shepherding your policies to the community. We've shared ideas. We've collaborated. And we're advancing the community for a greater and more effective Internet registry.
I've served as a mentor, an advisor, a table talker -- especially today we had a great table talk discussion -- and I've been on several committees within ARIN. And I'm very proud of the accomplishments that we have made together.
My day job, I have been a router jockey or network engineer for the State of Oregon for about 21 years. We have a very consolidated network, and we serve about 40,000 direct end users. We act as an ISP for the State of Oregon -- all state agencies, municipalities, K-12, higher ed.
I'm also working on different IXPs and peering within Oregon, and I'm working very hard to promote Internet exchange and peering in the state of Oregon.
My company, like yours, is directly affected by the policies that we develop within the community. I understand the need to continually mature the NRPM. And like you, I respect the need for the council to represent the best interests of the community.
My experience as a network engineer and as a public servant allowed me to bring a unique perspective to my role on the council and an understanding of how to help policy, so the community as a whole, and I also have a solid understanding of the technical ideas behind the policies that are presented by the community.
I'm deeply committed to the community and continuing to further the progress of your ideas, which I heard a lot of today, your policies, your fellows, and your Internet.
I will continue to work hard to listen, to be your voice in the Policy Development Process, and help in any and all ways that I can.
Today I'm asking for your vote so that I can continue to be your voice to champion the best interests of the community and to continue to improve the policies for all of us. So thank you very much.
John Curran: Next up is Anita Nikolich, who is not here. I'll read her bio.
She's with the Illinois Institute of Technology. Three years as a Security Engineer at SAIC. Three years as Security Operations Director at Intermedia Communications. Six years as Global Telecommunications Director at CSC. Five years as Executive Director, Infrastructure, at the University of Chicago. Five years' experience in cybersecurity. Breadth of experience as both a provider and a customer of network services.
Background is a combination of federal government, research, education, scientific community, the security community and private industry. Serves on the Advisory Board of the RPKI pilot project for the California State Research Education Network.
A member of the Working Group on cybersecurity for the NSF-funded Midwest Big Data Hub. An organizer of the AI Village at DEF CON. Previously served on the Engineering Technology Advisory Committee for the Illinois Century Network, the Technical Advisory Committee for the Midwest Research and Education Cooperative Network, and the Cisco Higher Ed Technical Advisory Board at Cisco.
Next candidate is Jeffrey Anderson. Jeffrey is here. Come on up and say a few words about why you're running for the ARIN Advisory Council.
Jeffrey Anderson: Good afternoon. My name is Jeff Anderson. I'm with Implex.Net in Minneapolis. And it's been a pleasure to work with the folks at ARIN over the many, many years I've been a network engineer.
This is a precious resource that we have, and good policy and good strategy is what makes it work for companies of all different sizes.
So I come to you from the medium-sized company that gets to work with a lot of the large companies and a lot of the small companies. So I'm here today to add a more unique perspective, I think, on where we're going and how we're going to get there.
You can see from my bio, I do a lot of work in the life-safety world, specifically with networks that span the globe, with a lot of those having to do with the maritime area.
I wanted to thank you for your consideration, and please take time to vote.
John Curran: Thank you.
And let's see, last one is Matthew Wilder, Telus Communication. He could not be here, but we have a video. Coming up.
Matthew Wilder (via video): Hi. I'm Matthew Wilder, and I'd like to serve you on the Advisory Council. I'm disappointed that I was not able to join you in person at ARIN 44, but nevertheless I would like to take the opportunity to tell you a little bit about myself, including why I want to serve you on the Advisory Council and what qualifies me for the role.
I'm a senior engineer at Telus Communications, a service provider in Canada, with responsibilities including IP address management.
I've participated in the ARIN community along with IETF and NANOG for over a decade. My interest in serving on the Advisory Council is motivated by an interest in the long-term vitality of the ARIN community.
When I think of the future of ARIN, I consider the ability of new and existing organizations to get and use the IP addresses they need in order to participate in today's connected world. This is the democracy of the web, and it starts here with our community.
I'm keenly interested in our industry's adoption of IPv6, which holds the keys to our future innovation. I was able to lead my company's enablement of IPv6 for our customers and in so doing helped put Canada on the map as far as IPv6 adoption goes.
I've shared our company's experiences regarding IPv6 recently with ARIN and CaribNOG and previously through other industry forums.
Serving on the Advisory Council would be a continuation of my contribution to the ARIN community. Most recently I've had the pleasure of serving on the ARIN Community Grant Program Committee along with a wonderful slate of committee members.
I was incredibly grateful for the opportunity to review applications and select worthy recipients whose projects promise to benefit our community.
I've been able to bring my employer's capabilities to benefit ARIN and the extended community by providing network sponsorship to each of the ARIN meetings held in Canada over the past decade along with NANOG and IETF as well.
Thank you for considering me as your candidate for the Advisory Council. I look forward to serving you.
John Curran: Thank you.
And that concludes our ARIN Advisory Council candidates. Now we're going to move on to the Board of Trustees. So ARIN Board of Trustees. I'd like to bring candidate Patrick Gilmore up to say a few words about why he's running.
Patrick Gilmore: Hi, everybody. My name is Patrick. I just finished my first term, or about to finish my first term, on the ARIN Board.
Three years ago I stood up here and told you all about the other Board experience I had. I'm not going to tell you that again. You can watch the video or you can read my bio.
I said I think it would help me do better on the ARIN Board, and I honestly believe, having been there for a few years, that it did help me. I also believe that it helped ARIN, but you should probably talk to the other Board members that are all in this room and see if I'm right because I'm probably not the best judge of that.
I also believe that my experience in operational security, policy forums around the world have allowed me to bring a wide and somewhat different perspective to the ARIN Board.
Just as an example, no other Board member has architected globally deployed CDN. No other Board member or candidate has run multiple large Internet exchanges, just as some examples. And these are things that number policy needs to keep in mind when you create something that's going to work for the entire Internet.
Finally, and I think this is actually one of the most important things, I've been really, really lucky in my career. I've had jobs that allowed me to travel the entire planet Earth and meet people in all positions, from junior NOC techs to C-level managers in small and large companies, in lots and lots of different countries.
I've had to not just meet with them in conferences, but I've had to work with them and convince them to do things for my companies or have them convince me to do things for their companies. And gaining their perspectives, learning what they think about and why they do the things they do is really important, again, to global number policy.
If you think about it, this is what we do here. This is very important to the Internet as a whole.
So given the challenges that ARIN's facing, from RPKI to v6 deployment to the waitlist, and just the things that we are facing in the near future, having a broad, wide perspective and knowing how everyone thinks, not just here in the United States, not just at ISPs, but all over, in all types of jobs and countries is very important, in my opinion.
In closing, I'd like to thank all of you because I look around this room and, as somebody recently mentioned to me, mostly the same people come back here. It's 50, 100 people, and they all come back here.
And it's really impressive that you guys and gals are invested in this process, because I do believe it's important to the Internet and, as a result, the world.
And it's nice of you to come here, share what you think and believe with me, and I hope that I have faithfully represented or at least explained to you why I wasn't going to represent those views up at the Board level.
I humbly ask for your vote. If you have any questions, you can email me, meet me afterwards, give me a call, whatever you need. Thank you very much.
John Curran: Next candidate for the ARIN Board of Trustees, Catherine Middleton. Catherine, are you here? Come on up, say a few words about why you're running for the ARIN Board of Trustees.
Catherine Middleton: Great, thank you very much for the opportunity to speak to the ARIN community today.
I'm Catherine Middleton, and I'm delighted that the nominating committee chose to put my name forward as a candidate for the Board of Trustees.
This is my first time at an ARIN meeting, and I appreciate the warm welcome and the outreach to newcomers. There is a lot to take in, especially at a technical level. But I'd like to direct my comments to strategic issues, where my expertise lies and where the Board of Trustees provides its input and guidance.
On our lanyards hanging around our necks is a question: "IPv6: are you ready?" And it's a really big question. To me, it's a question about how an organization like ARIN can manage a change of mindset.
In moving from IPv4 to IPv6, the Internet community is shifting from a world where numbering resources are scarce to one where they're abundant. At the moment, ARIN and the other RIRs are managing the old and the new world simultaneously.
Seems to me that there's a lot of time and energy focused on things like the IPv4 waitlist and on transferring addresses from one organization to another, and the principle of conservation is central to the organization, as outlined in the NRPM.
These are core concerns now, but what does a future of essentially unlimited numbering resources offer? When will this future arrive? What new business models might it bring? Are there new services to offer, new types of number holders to welcome into the ARIN community?
What can the organization and community do when the resources currently focused on managing the IPv4 space can be freed up? What are the opportunities at this point in the transition?
The Board of Trustees has a role in encouraging ARIN to think carefully about these questions and think about how it can best offer value to its members and broader communities in both the old and the new environments as we work collectively to define and realize an IPv6-centric future.
In addition to providing strategic guidance, Board of Trustees members have fiduciary duties to act with care and in the best interests of the organization. The Board provides financial oversight and ensures risk management.
These are duties that I'm very familiar with through my past service on the boards of CANARIE, Canada's national research and education network, where I was board chair in Compute Ontario. Statements of support on the ARIN election website attest to my strong contributions to the governance of these organizations.
Through my day job as a business school professor and Internet policy researcher, I've developed strong capacity to assess strategic initiatives and provide specific and constructive feedback. I'll bring high-level strategic thinking and detail-oriented, careful analysis of finances and Board decisions at ARIN, drawing on my formal training as a corporate director, to fulfill the duties of a Board of Trustees member.
In closing, I ask for your vote, as I have the time, energy, knowledge and governance experience needed to be a successful member of the Board of Trustees.
I'm a good listener and a fast learner, offer an independent voice and am confident I can make a strong and immediate contribution to ARIN as of January 2020.
Thanks for listening, and I encourage all your organizations to participate in this election.
John Curran: The third candidate for the ARIN Board of Trustees is Jacob Glick. We do not have Jacob here. He's unable to be here, but we have a video. We can cue up Jacob.
Jacob Glick (via video): Hi, everybody. My name is Jacob Glick, and I want to thank you for joining me here. I wish I could be with you in person, but it is Halloween, and I have three adorable children, and so I'm spending it trick-or-treating with them instead of with you.
I'm here because I've been nominated to serve on ARIN's Board of Trustees, and I want to ask you for your support. I want to ask your support for three reasons -- because of my professional experience, my Board experience, and my vision for ARIN.
In terms of my professional experience, I've served at the C level of one of Canada's largest telecommunications companies and one of Canada's largest ISPs, and in that context I saw firsthand how Canadians value their Internet access, and the data says as much as they value access to water and electricity.
And I saw firsthand the billions and billions of dollars that the company that I worked at, Rogers, invested in Internet infrastructure and the billions and billions more that all of these companies are investing across Canada and North America, large and small companies, to make sure that there's the absolute best infrastructure for Canadians.
When I was at Google, on a national and an international basis, I worked to fight for the open Internet, to fight for net neutrality, to fight for the multi-stakeholder model. And I've done it my whole career, and I'll continue to do that.
And now at a startup, I see how Internet access can be transformative in building new businesses and new companies. So I've seen it at all levels in my professional career and done my best to advocate for the open Internet and the multi-stakeholder model at every stop in my career.
As a Board member, I have served on the Board of the Canadian Wireless Telecommunications Association; on the Board of MediaSmarts, which is Canada's most important child safety and media literacy NGO; and on one of Canada's leading digital rights advocacy groups.
And in all of those contexts, I believe the role of the Board member is to help management develop a strategy and to align with management on that strategy to serve the goals of the organization. But it's ultimately up to management to execute on that strategy, and that's the role that I would play if I was elected to the ARIN Board of Trustees.
I wouldn't try to substitute my own judgment for that of management. I would try to work with management to develop a plan and ultimately help them deliver on that plan.
That's the important distinction between being in management and being on the board, and that's the approach that I would take if I was elected to ARIN's Board of Trustees.
And with respect to ARIN, I think there's both huge opportunities and huge threats that a strategic plan for ARIN needs to address. In terms of opportunities, 5G and IoT means that more devices than ever will be connected to the network, which means that more IP addresses will be needed and the management of those will be more complex than ever, which is a huge and exciting opportunity for an organization like ARIN.
But in terms of threats, make no mistake that there are international organizations and countries that do not believe in the multi-stakeholder Internet and in the open Internet and are looking to find ways to fracture that model, and ARIN needs to continue to advocate for the multi-stakeholder model and against that kind of fracturing.
And ultimately it will be the success on both of those fronts, the opportunities and the threats, on which ARIN is judged, and I would propose that an operational plan built on those strategies is what I would assist ARIN's management with and ultimately be responsible for and accountable to you for on the execution of.
So I hope I can depend on your support in the upcoming election, both because of my professional experience, my board experience and my vision for ARIN. And thanks very much, and I hope you have a great rest of your meeting.
John Curran: Next candidate for the ARIN Board of Trustees, Bill Sandiford.
Say a few words about why you're running.
Bill Sandiford: Hello, everybody. My name is Bill Sandiford. I reside just outside of Toronto, Canada, and I stand before you asking for your vote in the upcoming election to be returned to the Board of Trustees.
A little bit about myself. I started out in this crazy world by running an ISP that I founded in 1996 and successfully ran for 18 years until it was successfully acquired in 2014.
Since that time, I spent some time in the not-for-profit sector, was educated on being a director for NFP boards, in particular, and have been doing that in a couple different forums.
I have spent time on other industry boards, including trade associations and a top-level domain registry, as well as a large Internet exchange provider and community organizations at home.
I'm seeking to be returned to the ARIN Board because I believe that, although we've accomplished a lot over the last number of years, there's still a lot to be done. We have made headways in areas around diversity and corporate governance, but there are still more to be done in those areas, particularly as it relates to our election processes, the nomination committee, how it operates.
And there's, quite simply said, a lot of work to be done in those areas; therefore, I'm here again asking for your vote so that I can be returned to the Board of Trustees for another term so that we can finish the hard work that's been started and so desperately needs to be finished.
I thank you for your time and consideration and ask you kindly for your vote. Thank you.
John Curran: The final candidate for the ARIN Board of Trustees, Bram Abramson.
Say a few words about why you're running.
Bram Abramson: Good afternoon. Thanks for welcoming me here as a Fellow and also for considering my candidacy.
Hello to everyone in the room and who's tuning in remotely, and allow me to say (speaking French). So that's a good afternoon to those who come from the francophone areas of ARIN in Canada and the Caribbean.
The current Board's instructions to the nominating committee talk about how, you know, among the things they're looking for are folks who can provide strategic leadership and oversight with skills in areas like risk management and experience and understanding of the areas of law related to ARIN's business.
So I believe that that's a good request and that I can provide those skills. I'm here to volunteer those skills and ask you to use one of your votes to support me in that. And my pitch to you is, in doing so, you will bring forward a fresh voice with the right mix of experience.
As you'll see from my bio, I first got into networking as a kid with an IBM XT clone and 1200-baud modem that became a FidoNet bulletin board with a bunch of batch files.
I found a passion years later. The Internet was becoming quite popular thanks to the web. I made my way from Montréal to Washington D.C. to measure phone traffic, and I found myself building a research program on Internet infrastructure from wall maps of submarine cables and transporter Internet routes to a very detailed diagram we published of the emerging Internet governance stack that was then taking place, including a new organization called ARIN.
A lot of what I did then and since then is part of what I think gives me the right mix of skills and sensibilities to contribute to ARIN by assisting the Board.
Working at the Canadian telecom regulator early in my career taught me about going on roadshows, consulting widely with stakeholders, understanding how solutions need to work across the board and where the art of compromise and sober second thoughts fits in.
My role running legal and regulatory for an ISP just after the Edward Snowden disclosures thrust me into the hot fire of privacy rights and law enforcement, and I ended up doing a lot of work to systematize and balance these as a privacy advocate.
But I also spent a lot of time advocating for small- and mid-sized organizations, pointing out some of the big, fancy solutions that policy makers think would be a good idea are great in theory but don't scale.
These are issues which very much involve ARIN, on which staff works hard and for which I hope my hands-on experience and thinking would serve the Board well.
Finally, my broad work in private practice as a consultant on complying with data privacy, on making telecom policy and on dealing with regulations both in terms of their intent and their burden I think gives me a wide lens on the kind of work that ARIN does.
I've advised on-board governance and fiduciary duty as a former financial analyst, policy maker and lawyer with the experience in multiple areas. I can compare and contrast in ways which I believe will help me ask the right questions on the Board of Trustees.
If you support me for trustee, you'll get someone with a long history in network and governance; experience in advising on and providing fiduciary oversight; and the background in financial, legal, and risk analysis.
So I'm calling that a fresh voice with the right mix and ask you to support it. Thank you.
John Curran: Very good. That concludes our introduction of all the candidates.
Board Candidate Forum
John Curran: And now we're going to do something a little different. So we've had, in the past, comments that say: We'd like to get to know the candidates a little better. And I'm, like, well, we could give them 10-minute speeches, 20-minute speeches, we could make the day that. We actually decided, just for the Board of Trustees, we're going to do a candidate forum.
And this is a little pre-canned because this is our first foray. We're going to actually ask each of the candidates a question and have each respond. I'm going to moderate the session.
We have -- for the one candidate who can't be here, Jacob, we actually have his responses already taped by video.
You are actually the ones who supplied the questions. We polled the community for the questions and for the order of questions as priority because we had far more questions than time allows.
So we'll take about 30 minutes and do this. It's to allow you to get a better understanding of the Board of Trustees and why they might be of interest to the community.
We announced the questions. We sourced them from the community. We announced them back to you and let you prioritize -- you can see everyone's questions. I grabbed the short list based on that priority.
We'll take three or four of them, which we've prepared depending on how the time goes, and there's not going to be a Q&A.
So each candidate has about two minutes to respond to each question; I'll pose it to each one of them, then we'll move on to the next question. There's no Q&A, but we're going from here to break. And so unless a candidate's really sneaky, I think you'll be able to find them out there. So you can always find them one-on-one if you have to follow up.
If a candidate doesn't want to answer a question, maybe it's a question they haven't thought about or they don't think the answer really fits in two minutes, they don't need to answer a question. We'll see how it goes.
And then we'll take it, as always -- we'll think about how we do this in the future. But the first foray, this is what we're going to proceed with.
So at this time I will ask all the candidates to come up here. They have seats assigned.
Welcome to our first candidate forum. I'll ask each of you, and of course I'll remote Jacob, I'm going to ask each of you a question.
The first question is the one before us, which is: What do you think ARIN can do to improve the general Internet's routing security policy?
And I'll open it up immediately. If one of you wants to go first and kick off the forum, I'll turn it over to one of you. Who wants to go first?
Bill, go right ahead.
Bill Sandiford: First, I want to say congratulations to everyone for making it through the NomCom process, and I'm really honored to be a candidate with such an esteemed crop of individuals. So, welcome.
All right. So with regard to this particular question and ARIN improving the general Internet's routing security policy, my view is that ARIN should share, along with its other industry partners -- RIRs, ICANN, et cetera -- a leading role in improving the Internet's routing security.
There are a variety of ways this can be done, but mostly through advocacy and outreach as well as education around initiatives like MANRS, mutually agreed-upon norms for routing and security, and particularly where it relates to BGP stack and RPKI.
So, to summarize, I think our role is to lead with others in an advocacy and outreach initiative.
John Curran: Excellent. I'll turn it over now to our remote video. You're going to hear from Jacob Glick on the question how we can improve the Internet's routing security policy.
Jacob Glick (via video): What can ARIN do to improve the Internet's routing security policy? You know, for me, I think that the key is for any organization, especially a venerable one like ARIN, to be open to new and innovative developments that increase security. So that includes exploring new technologies, piloting them, really being a champion for security across the web, but, importantly, not letting security be a Trojan horse for the vulcanization or the shutting down of the open web.
John Curran: Okay. Another Board member would like to go next? Go right ahead.
Bram Abramson: So this morning we heard and very much enjoyed, I think, Cathy Aronson's presentation on what's happening at the most recent IETF, among which was a slide on SIDR ops which promotes deployment of things like RPKI and BGPSec.
Point being there's kind of a wider world out there of this stuff, and the question of where ARIN fits in, I think, is an important and tricky one.
Let me start with some ideas and then retreat back to activities. Things like ARIN on the Road have a lot of potential to go even further, focus down, call it "routing security on the road" and actually reach out to ISPs when doing it and say: Let's talk specifically about deploying some of that stuff.
Meeting with non-adopters. Adding routing security as a heading in the RIR Comparative Policy Overview, simply, so to have that discipline of kind of checking in each time on what everyone is doing.
Publishing deployment numbers to see how we're doing, all of which are hopefully fairly light-touch activities, because ARIN's resources are limited.
ARIN already does much in the area of routing security -- IRR, RPKI, as well as things like DNSSEC and RDNS. And I guess, in my view, the primary job is to tighten, improve, and increase deployment of existing activities, much of which has been going on, much of which has already been the subject of a lot of work.
I think the next step will surely be to look at what the results have been from the IRR forklift upgrade from the change to the agreement around RPKI and see how we did.
John Curran: Okay, thank you, Bram. Would either of the other candidates like to -- Patrick or Catherine? Catherine.
Catherine Middleton: We'll do all the Canadians at once.
So I'm new to the organization. I think in some ways this is a general question, but I think it could also refer to quite a specific instance, an issue that's happening at the moment.
So I was looking around for some information to help me understand this better, and one of the things I came across was an article in The Register that you've probably seen published a couple days ago with the headline: "Critical Internet Org accused of undercutting security over legal fears; America's Regional Internet Registry slammed by critics, snubbed by ISPs."
I don't know how accurate this story is, but the story's out there. And from a governance perspective, I'm thinking about this from the perspective of somebody on the Board of Trustees or potentially wishing to be on the Board of Trustees.
I think it matters that the story is there. I think it matters that the story reflects there's a lack of consensus. There's a huge amount to this issue, and as a novice I'm really going out on a limb, sort of jumping in.
But I think really what's important here is looking for the commonalities, trying to figure out how collectively the organization, ARIN as an organization, and the community it serves can figure out a way to solve this problem; that there is recognition that RPKI is really important, there's a current set of roadblocks, and thinking about how perhaps meeting in the middle, how the concerns can be addressed ultimately.
John Curran: Patrick, do you want to opine on what ARIN should do to improve general Internet's routing security policy?
Patrick Gilmore: I'm going to start with a couple things that you might not think about. The first one is you say what can ARIN do, and I think the first question actually is should ARIN do anything.
Most of you have been -- some have been around for a long time, but I don't know if you remember, ARIN originally didn't even guarantee your blocks were routable. In fact, I'm not sure we still do. So the idea ARIN takes an operational role is kind of new.
But I think it's an okay pivot for ARIN to do. I think that routing security is very important. And I think that if we can help, that's fine for us to do.
The second thing that is not clear by the question is you're asking a bunch of Board candidates what we do on a policy issue, and the Board doesn't dictate policy. This should be something that goes through the standard PDP, and the community should have a voice in this.
But because the question was answered, I'm happy to give you my opinion because I'm a member of the community and I'm allowed to say these things, but I wanted to be clear that if somebody came to the Board and said, "Put this policy in," my first reaction would be, Has it gone through the PDP? Did the AC comment on it? Et cetera, et cetera.
So, given that, like everybody else here, I think the IRR and RPKI are good starts. But they are just starts. I don't think RPKI is a silver bullet, but it's a necessary baby step. There is no silver bullet. So do a defense in-depth strategy and start with several different things.
But they, more importantly, are an example of how ARIN can help. We have no ability to affect any router on the DFC. ARIN doesn't have any operational capabilities. All we can do is, as a "for instance," publish a list of things or people that are ASNs that have done bad stuff and hope that the operators use that list to create better security on their own stuff.
So I think thinking up things like that are good and tightening what we have. Just as an example, we have an IRR, but let's all be honest with each other; the IRR is not the greatest thing that ever existed. It's not verified. There's lots of trash in it. We didn't do any work with it.
RPKI is a better example, where you have to actually verify who you are before you can say you own a block.
So I'd like to see us do those things, but I'd like to see it come from the community. And I'm happy to participate in those discussions, but as a Board member I'm not going to force anything through that hasn't been through the standard process.
John Curran: Thank you, Patrick. We're going to move on to our next question now. Our next question is: Why do you want to serve on the Board of Trustees? A question you've all somewhat answered when you gave your bio.
I want to focus on the second part: What's your motivation to give up so much personal time?
Patrick, go ahead.
Patrick Gilmore: Like I said in my speech, I've been incredibly lucky to be able to participate in lots of things. I've had jobs that let me get on nonprofit boards for Internet infrastructure and policy organizations and I didn't have to give up vacation time or anything like that.
I was also really, really lucky in that I had a bunch of friends and colleagues who helped support me so that I could learn how to do it right and make a real impact.
And my role at ARIN is honestly kind of a culmination of all that experience. I feel like I can contribute to the community. I feel like I'm making a positive impact on the Internet. And I honestly believe the work we do is important to the growth of the Internet, and by extension, as silly or perhaps as arrogant as it sounds, the Internet has made life better for literally billions of people.
I want you all to stop and think about this. Everyone here in this room and rooms that are at other IRRs and NOGs, et cetera, you all have made the entire world closer. You've made it communicate better. You've made people freer. You've made it cheaper, easier, and better for me to talk to family and friends all around the planet. And this is, like, world-changing and honestly touches me in ways that I really think is important to humanity.
So my question is: Why wouldn't I want to be associated with something like that? Why wouldn't I want to help make that better? And that's why I want to do this.
John Curran: Excellent, Patrick. Anybody else want to speak? What's your motivation to give up so much personal time?
Bram Abramson: That's funny, when I was at NISP, I used to sit on these sort of industry technical fora, and it was way worse. We used to have to try to work out very detailed specifications for all kinds of stuff.
And usually I was one of the only lawyers on the call. I think there was one or two others, and I'm trying to craft this stuff. And a few times people said, "Bram, what's the point? Why are you doing this?" The point was they wanted to have people from our side who were willing to show up. And it was kind of fun.
So, why wouldn't I do it again? And when I made notes for this, I kind of jotted down three things. One is -- it kind of relates to that, I guess. I'm a bit of a tech policy nerd. And I found that in the past, thinking about those things broadly, being in different domains of tech policy has really helped me contribute to finding solutions that borrow from one domain and contribute to another, and I'd love to be able to do that and help steward forward an organization that has hit on some remarkable ways of doing things and has been pretty resilient as the Internet grows and scales and becomes critical to governments and businesses and is still pretty open and pretty not so fragmented, which is still kind of an amazing thing.
John Curran: Excellent. Catherine or Bill, are you excited about going next?
Go ahead, Catherine.
Catherine Middleton: Thanks. I think it was Alyssa Moore who said we're all special kinds of nerds here. And I feel that this is a community I can contribute to.
I have just come off two other boards, so I have some time. I'm a professor, and that means I spend a lot of time inside a university. I talk to students. I talk to industry. I'm outward looking in policy environments.
But I am really looking for opportunities to become more engaged and to find a community where I can continue the sort of work that I've been doing over the past 20-plus years, which is trying to make the Internet a better place.
The focus I've had in the past has been -- and continue to have is really around digital inclusion, around access to the Internet.
I've been at the Canadian regulator with some of the people at this table. And it's really about contributing to a community, continuing to provide community service and coming to this organization in part because the nominating committee invited me to be here and because I've got governance skills that ARIN is looking for.
John Curran: Excellent. I know Jacob is anxious to go. I was going to bring him up now. Let's hear from Jacob.
Jacob Glick (via video): I've let my name stand as a nominee for ARIN's Board of Trustees because I genuinely believe in the open multi-stakeholder Internet. I've spent my entire professional career working for it and the betterment of it.
So I want to continue to be able to do that, not just professionally but in my extracurricular activities. And so I really I hope that I can get your support in that effort. It's something that I've spent my whole career caring about and thinking about.
John Curran: Bill, did you want to comment why you're interested in spending so much time in such an activity?
Bill Sandiford: Sure. I realized as soon as Patrick spoke or started to speak that this was probably the question that I should have volunteered to go first on, and yet I'm the last. And the reason why that is is I think that a lot of us in this room are very similar in the types of things that we like to do and what we like to spend our time on and dedicate our time to.
And that's one of the biggest reasons why I've enjoyed this community for the past 10 years and would like to continue to do so. It's contributing to great causes that affect a great number of people all around the world with people who I, quite frankly, enjoy spending my time with.
I had the same words written down in my notes as Patrick, like: Who wouldn't want to do this, if these are the types of things and types of people that you want to spend your time with?
I'm proud of the advancements and the hard work that this organization has done for the past ten years while I've been involved, some on the AC and some on the Board.
But there's still a lot that needs to get done, particularly in some of the areas that we've already discussed in terms of the reform of the governance of our organization, an election and NomCom system that many of you believe is completely broken, and other initiatives as it relates to routing security that we spoke about, IRR and issues around RPKI.
So I have the time to dedicate to ARIN's mission and these causes. The people who I do it with are amazing people who I enjoy spending time with. And who wouldn't want to be in these shoes?
John Curran: Excellent. Thank you.
I'd like to move on to our next question, which is: What actions, if any, are appropriate for ARIN to take on behalf of an IP resource holder whose addresses are announced by an ASN that has no authorization or authority to do so? The announcement may be accidental or intentional.
Why don't we hear from Jacob first this time on what actions are appropriate for ARIN to take on behalf of an IP resource holder whose addresses are announced by an ASN that has no authorization or authority to do so.
Jacob Glick (via video): The question about what ARIN should do if addresses are announced inappropriately I think is fundamentally a question that management ought to have a point of view on and that management should develop policies on through the Policy Development Process that ultimately are ratified by the Board.
I don't think actually you want Board members who are predisposed to have a particular point of view on very specific policy areas like this that are really the rightful domain of the community and the Policy Development Process.
But if you want my point of view in general on dispute resolution policies, I think they have to be fair, I think they have to be unbiased, and I think they have to be swift.
So that's something that we learned when I was at CIRA 15 years ago, was that when we revised the CDRP, one of the things that we revised it around is making sure that disputes could be resolved in a swift way.
That's really important here because resources can't be announced improperly for any extended period of time. That can't be acceptable. So there has to be a very, very swift way for ARIN to take action, both in the short term that's ultimately through a fair adjudicative process that has long-term ramifications. But what that means precisely, as I say, I think is really up to ARIN's community through the proper Policy Development Process.
John Curran: We've heard from Jacob. Another Board member -- candidate, sorry, you're not Board members yet -- another Board candidate like to opine? Yes, Catherine.
Catherine Middleton: I'll go because I have a quite similar answer, I think, to Jacob's.
I think the technical question is not a question for the Board of Trustees, but I think what the Board of Trustees needs to understand is the risk inherent in the action that's taken.
There needs to be an assurance that the action or the choice not to act at a given time or the timing of the action, the management needs to be very clear as to the reasons that it makes the decisions that it does.
The Board needs to understand and assess the potential risks that goes along with that. I think as well there are precedents to consider, best practices in other regions. And there's strong advice, as Jacob said, from the community, I think particularly from the technical and legal expertise within the organization.
So from my perspective, I think the answer here is not what my own opinion is, my answer is really how does the organization as a whole ensure that it comes up with the best response to this particular situation.
John Curran: I see you ready to go, Bill.
Bill Sandiford: I'm going to flip it and go the other way. I would say that, first and foremost, I obviously believe that actions and standpoints that ARIN takes on things should be vetted by the community and we should be carrying out our mission in a way that's direct by the community. That goes without saying with regards to any of the answers to any of the questions.
On this particular one, my view, as if I was participating in the committee on this, is that I think that our community has very widely varied views on how far ARIN should go in this regard. Some might believe that ARIN shouldn't be involved at all in this type of thing. Others might believe that ARIN should have a heavy hand in this regard.
Personally, I don't think that it's our mission or it's our time or place to be out there policing the Internet. However, I do believe that, once again, regardless of whether or not an announcement of this nature is accidental or intentional, that ARIN should take a lead role in terms of education and advocacy to help its committee members and stakeholders configure the networks in such ways that these types of announcements don't happen, or have less of an impact when they do happen, and can direct their community members and stakeholders/customers to resources that can assist them when something like this happens.
But I just can't see where we have the time and resources or where it's our mission to be actively policing the Internet for accidental or intentional routing announcements.
John Curran: Thank you. Anyone down at the far end of the candidate pool? Yes, Patrick, go ahead.
Patrick Gilmore: Like the first question, the first thing I did is: What, if any, are appropriate actions? Well, today the appropriate action is nothing. We don't have a policy to do this.
But maybe we should have one. Just like everybody else said, it should go through the PDP, et cetera.
But I'm going to disagree slightly with some of them. The Board should not enact policy and shouldn't force policy down the community's throat, but part of the Board's role is to ensure that the corporation is financially sound, is following the law and several other things.
This policy or policies in this vein have a huge, huge risk of creating problems for ARIN as a corporation. You could do something that could get you sued. You could do something that could hurt the Internet. You could do one of those things. And that's one of the things that the Board is supposed to consider before rubber stamping something that went through the PDP, even if it went through properly.
So I think that there are things that we can as ARIN do, but they are light touch. Like I said in answer to the first question, we have no operational role; we can't do anything.
I personally, as a member of the community, not as a member of the Board, am not sure that I'm in favor of, for instance, revoking all the IP space if you accidentally announce something that you shouldn't have and things like that, that leaves us doing things like RPKI and the IRR and trying to show the community the correct way to do things and letting them do the filtering or whatever else it is.
But mostly I want to be clear that while policy should start with the community and come through the AC and the normal PDP, this is the type of thing I think the Board should take a very, very close look at before allowing to become an actual role because of the risk to the corporation. And I feel that's my role as a Board member.
John Curran: Thank you, Patrick.
Bram, I saw you nodding. You want to opine on the same question?
Bram Abramson: Yeah, I'm sure we've got a pretty good range now. I think, literally, my notes, some of them are word for word -- the rule of the Board is to act in ARIN's best interests and fulfill its fiduciary duty, not to substitute its policy thinking for the members or the PDP.
So the question again is, fine, so what would I be looking for as a member of the Board if this sort of thing happened?
And I think Patrick has it right in the sense that you go back to the mission of the organization and you go back to the articles and the bylaws and you say, What's the role of ARIN? You have to be careful about not going outside of those in a way that causes real risk.
ARIN has had great success in doing things that are related to standard setting or standard adopting, really, following the lead of actual standard-setting organizations, working with IRR or with RPKI.
If anything, it's an interesting question in terms of what kind of transparency, what kind of informational tools could ARIN consider engaging in, given the resources, to be able to sort of ensure that when this sort of thing happens, it's easily detectible, to ensure that it's brought to the attention of the community who will act outside of the ARIN context, I suppose, to do something about it.
And it also means maybe -- it's a provocative question, as you've seen from the answers. And things like table-talk exercises, where you actually cooperate with other organizations and say, Look, let's say this happens tomorrow, who is calling whom and what are you going to say, is not a bad way of thinking it through as members of the community in terms of inputting into the Policy Development Process.
John Curran: Thank you.
We actually are done now with the first three questions. We have prepared a fourth question, but we're also just under 200 seconds from break.
So the question is whether or not I take into your coffee and cookie time so you can get a little more information from the Board members.
If you don't want to hear them for the next five or ten minutes, break is outside. You can go. I'm going to continue the forum, though, for one more question.
Patrick Gilmore: Wait, so we don't get cookies?
Bill Sandiford: You promised cookies.
Patrick Gilmore: No one told me.
John Curran: I'll make sure you get a cookie, Patrick.
Our last question that we have prepared is: What is your vision on ARIN's role in the global RPKI and view on RPKI trust anchors? I guess we'll start out with Jacob because we know he's ready.
Jacob Glick (via video): The last question is about RPKIs. And I'm not going to lie to you, if you want somebody who is a global expert on RPKIs, you should not vote for me, because that is not me.
So I can tell you that what I think about this technology in general is that anything that increases the security of ultimately Internet users by increasing the reliability and security of routing is a good thing. And if there are specific issues related to it, again, I think those are really not properly the domain of the Board in itself, but rather things that ought to be addressed through the appropriate processes within the community and the Policy Development Process, and then ultimately for ARIN's leadership to shepherd through those processes and to bring to the Board for ratification, not for the Board to have preconceived ideas on how those kinds of policies should be dealt with.
John Curran: Okay, we've heard from Jacob. Board member Patrick, go ahead.
Patrick Gilmore: So, personally, I believe all of the RIRs have a vital role to play in RPKI. We have a unique position where we can tell who owns what block, and that's kind of vital to RPKI. So I think ARIN has a role to play, and I think it's important that we do that.
Personally, again, not as a Board member, personally, I would love if the TAL was just put out there for free. That would be best, in my opinion, from the operator standpoint.
Some of you know a guy named Job Snijders. We're actually on another board together, and we're good friends. And I can't tell you the number of hours he has explained to me why it's stupid what ARIN is doing.
Unfortunately, based on my last answer, you probably noticed that I really do care about the risks associated with doing something to the corporation. Is this an existential threat to ARIN? While we're vital to RPKI, if we get sued out of existence, we can't do RPKI or anything else.
So when legal counsel tells the Board this is an existential threat to the organization, it is possible for the Board to go, "Well, we don't care; we'll do it anyway. That's absolutely within our purview."
But it's not something that we take lightly. I think the recently updated RPA was a good step, but it was a small step. And I'm going to push and we're going to research and see how we can make it closer to completely free.
But I do not think that's going to happen tomorrow, because I really do believe we have to protect ARIN first as a corporation and then we can do the best we can to provide the services that the community needs. It's not the other way around. We don't just do everything and then go, oh, well, if the corporation goes away, too bad. That's how I feel about it.
John Curran: Anybody else like to opine? Bram?
Bram Abramson: Look, clearly ARIN has a critical role to play, and RPKI is one of the five regional registries. But it's also sort of an interesting example that really points out some of the tensions and some of the skill sets you need in all this.
One role is to ensure that ARIN facilitates global implementation of RPKI in cooperation with its partners and a standards-based manner and so on. And that's something that's a step towards improving, running security and other -- one of other questions we had, it's clearly at top of mind.
So facilitate global implementation at the same time. Another role is to ensure that it has its eyes open, it understands its risk and that it's understanding its stakeholders, including members of the community understand their risk. And that's also important.
And there's a third one, which is it's got to balance implementing everything it does in a way that's friendly to small players and doesn't require an army of developers or an army of lawyers to implement.
I'd say this is, as an example, both good and bad because each of these things have been done in good ways and sometimes in not so good ways. And it's a tough thing to do. One of the challenges has been whether the right balance has been struck in doing all these things. Part of the very vigorous debate has been about saying maybe the right balance has not been struck; let's shift things a little bit and so on.
I've spent my career as a lawyer advocating for plain language drafting and user experience design. And all that fun stuff is part of -- I guess many younger lawyers are not doing. So all I can say is this is a familiar problem.
John Curran: Thank you. Catherine, Bill, either of you?
Bill Sandiford: I'll try and be a little quicker acknowledging that Catherine and I are all that are holding you from coffee and Original Sea Salt vegetable chips.
I read this question, and I viewed it a little bit differently. I looked at this question and said, "Wow, there's Job's question." And in the vein of John today, I'll throw my own little bad joke in, and I'm going to say, the question is: What is your vision on ARIN's role? And I'm going to say, ARIN plays a key role in the global RPKI.
Okay. I won't elongate the answer much longer other than to say, simply put, I think that we need to find a way to make our TAL more readily available without some of the barriers that exist today, while effectively managing the risks to the organization.
John Curran: Thank you. Catherine?
Catherine Middleton: I really agree with what's been said by everyone else. There's very clearly risk here. There's very clearly a demand within the community. There's a gap between the two. You can't just ignore that gap.
It seems like a solution for this is absolutely essential, and I think this is an organization and a community that has the wherewithal to figure out what that solution should be. And if I can help contribute to that in any way, then here I am.
John Curran: Thank you. We've heard from our candidates on all four questions of the candidate forum. I'd like a round of applause for the candidates, including Jacob, our remote.
Elections will open shortly -- actually now, right? Elections are now open. So, if you have not started voting, go forth and start doing that.
We're going to take a break now. We're going to be back here at 3:30, and I look forward to seeing everyone at that time. So we're on break until 3:30. Thank you, candidates.
(Break from 3:05 PM to 3:30 PM.)
Recommended Draft Policy ARIN-2019-8: Clarification of Section 4.10 for Multiple Discrete Networks
John Curran: If folks will come in and be seated, we'll get started. Welcome back from break. I hope you enjoyed your fruit and healthy snacks. We're going to start right in with the policy block for the afternoon.
The first one up is Recommended Draft Policy 2019-8: Clarification of Section 4.10 for Multiple Discrete Networks.
I'll do the introduction, and we'll have Owen DeLong come up and give the presentation for the AC.
So Advisory Council shepherds: Owen DeLong and David Farmer.
History: It started out as a proposal this year, in April. It was adopted moved to Draft Policy and was recommended and became a Recommended Draft Policy in August of this year.
This is the first time it's coming before an ARIN meeting. The latest version is the 21 May version that's in your Discussion Guide.
This policy retains a requirement that an organization with a single network may request a /24 from the reserve pool for 4.10 dedicated IPv4 block to facilitate IPv4 deployment -- I have a different slide than I thought. Okay.
I'm looking here. Okay. Sorry, just double-checking. I had a different text earlier. May request a /24 from the reserve pool 4.10 to -- provided they have not received a direct allocation or direct assignment from the pool in the preceding six months.
It adds: An organization may request a /24 from the dedicated pool to facilitate IPv6 deployment for each discrete network provided the discrete network has not received a direct allocation or direct assignment from the pool in the preceding six months. An organization may not receive more than one /21 equivalent from the reserve pool for a 4.10 dedicated IP block during any six-month period. This is for multiple discrete networks.
Staff comments: We note that any organization would be limited to a total of a /21 equivalent from the pool and that the waiting period for getting these blocks would be assessed for each discrete network and that the /21 equivalent would include all space received, even if it was at issue for people who already have space.
If you already have an assignment for one or more of your discrete networks, that would be counting towards a /21 total maximum.
So we don't have material legal issues here. Resource implementation: Available. We could do the implementation within three months by updating training documentation and customer outreach.
And I'm now going to have Owen come up and do the AC presentation.
Owen DeLong: So this is a Recommended Draft Policy. That means that if we get support here, it probably goes to Last Call and then possibly even becomes policy.
In a nutshell, the current working 4.10 wording doesn't take the needs of multiple discrete network organizations into account. Organizations that have such networks probably need some additional accommodation in order to move forward. And we're making an attempt here to do so.
The proposed solution allows them to apply for transition blocks for each discrete network. But we also recognize that we don't want to open this to widespread abuse by simply creating lots of discrete networks. So we limit it to a total of eight /24s. Generally favorable on PPML. Four in favor, one expression of opposition.
The opposition stated: IPv6 connectivity is required. Sites can use IPv6 to tunnel to the central NAT point. However, that statement seems to inherently assume that this address space is being used only for NAT, and there are many other purposes and needs for transition, IPv4 space, that that kind of tunneling wouldn't necessarily cover.
We're looking for additional support. Do you support or oppose as written? If you're opposed, are there changes you'd prefer? If so, what changes? And should we move this to Last Call?
With that, I'll turn it back over to the Board.
John Curran: Come on up, Bill. Our Vice Chair, Bill, will moderate the discussion from the queues. Owen should stay here in case we have any questions. Microphones are open. Remote microphones are open.
Bill Sandiford: Thank you very much. Thank you for your presentation, Owen. We'll start with the rear center microphone. Please state your name and affiliation and whether or not you're in support of the proposal.
Kevin Loch: Kevin Loch with QTS. I support this. The alternative is for organizations simply to create multiple Org IDs which adds additional burden on the ARIN staff, makes things messy or harder to track down. May make it harder to track down who actually owns it, if the names of the other Orgs are then necessarily specific to a site rather than a more national or global organization.
Just makes sense. This is also consistent with the way IPv4 space was issued out of the general pool in the past.
Bill Sandiford: Thank you. Far microphone. And also an invitation to those that are remote participants to get their questions in, noting that there is a little bit of a delay from when you see us to when we get the questions in the room.
Kevin Blumberg: Kevin Blumberg, The Wire. I support the proposal. I believe in our last meeting when this was discussed, one of the questions that was asked was how many Org IDs have multiple discrete networks?
And I believe the number was a couple hundred. It wasn't in the thousands. It was a couple hundred.
John Curran: We can find that out.
Kevin Blumberg: Really the only question becomes, if you extrapolate out the couple hundred Orgs times eight /24s, et cetera, is the 4.10 pool sufficient to maintain that? I don't think it affects it today.
But I think that the community, as we expand the use of 4.10 or we're more liberal with the use of 4.10, should consider that it is going to run down and it is going to empty out. And that is my only concern.
But, again, based on the numbers I believe I heard last time, it would not be as significant a drain, just a drain on the 4.10 if it was actively used. Thank you.
Bill Sandiford: Thank you, Kevin.
Rear center microphone.
Mike Burns: Mike Burns, IPTrading. I have a question: Are those limits per Org, each of those limits per Org?
John Curran: There's a one limit which applies to the whole -- the entire Org, for its total that it can get from the MDN pool. So there's a draw-down rate that applies to each MDN and then an overall limit that applies to the whole Org.
Does that answer your question?
Mike Burns: Yes, it just leads me to point that this pool is going to be the magnet for fraud. If you tell people that you can get free addresses if you have an MDN and limited by Org, you're going to get more MDNs and more Orgs.
So you've just got to consider how much does it cost somebody to set up an Org or to divide their network or do what we're setting up as requirements to access this fruit, this low-hanging fruit. And believe me, there are Orgs that are going to do exactly what you say, and you're going to have more Orgs and more MDNs.
So to Kevin's point about counting the potential impact and projecting the draw-down of the pool based upon the current numbers, I think you should think that these numbers are going to grow.
However, I do support the policy.
Owen DeLong: So in response to that, the 4.10 policy already exists, and each Org can get one /24 every six months. This creates a carve-out for organizations that have -- and I think your comment about creating Orgs is perfectly valid, but it applies to that as well. This does sort of multiply that possibility by eight for organizations that can legitimately show that they have multiple non-connected sites.
But that's why we have the limit of a total of a /21 overall in an effort to curtail gross fraud in that area so we don't have organizations getting a thousand blocks that way, but we do have organizations that have a real legitimate need for this. And so we're trying to balance that as best we can.
Bill Sandiford: Thank you, Owen.
Front center microphone.
Chris Tacit: Chris Tacit. I want to remind everybody that the reason this got drafted, and I was one of the two co-authors, along with Chris Woodfield, as a result of the previous Policy Experience Report that we had on this issue. So this is solving a real problem of ARIN that I think staff have found when people are calling in and complaining about it.
Bill Sandiford: Thank you.
Kevin Blumberg: Kevin Blumberg, The Wire. John, could you speak to the complexities of MDN with staff, because my understanding, and I'm sure there's some people in this room who have MDN, is it was probably one of the hardest things for an Org to justify to get in the first place. And if that continues, then --
John Curran: Administration of MDN policy requires you to show that you have discrete networks that you can't connect and that's why they're discrete.
So it has a technical justification to demonstrate before you're allowed to use the MDN policy. And it's pretty rigorous. There are organizations that have circumstances that prohibit them from having their own backbone effectively or they're required to use someone else's infrastructure, someone else's services in order to serve multiple customers. And so you actually have to explain that and explain the requirement in order to qualify.
I'm not sure it's 100 percent impossible to game. You'd be amazed the creativity of people in the world. But there certainly is a significant barrier.
Bill Sandiford: The lady with the awesome Halloween t-shirt.
Cathy Aronson: Cathy Aronson. I'm in favor of this policy. I just wanted to make sure that -- I'm pretty sure we passed a policy that said that if you no longer need a block in the -- that you got from this block, that you can't sell it, you have to give it back to this block.
John Sweeting: That's correct.
Cathy Aronson: Okay. I wanted to make sure that everybody here remembers that, because it's harder -- you can't get these blocks and then turn around and sell them, you have to give them back. Just wanted to point that out. Thanks.
Bill Sandiford: Last call for participants to approach the microphones. And do we have any remote participants? No remote participants with questions.
John Sweeting: John Sweeting with ARIN staff. There's one other thing to remember: That they can only get one for a site. They can come back six months later, but they're going to have to prove they have used 80 percent of that /24 for that site deploying v6 technology.
So we're very hard when they come back. They get the first one pretty easy, but to come back and get a second, it's not so easy.
Bill Sandiford: Thank you.
John Sweeting: And it comes to me for review.
Bill Sandiford: Thank you. All right. Seeing no further participants at microphones, and being told that there are none with remote questions, we'll move forward to the next stage, which is gauging support. And we'll thank Owen for his presentation.
All right. All those who are in favor of the policy, please raise your hand to show your support.
Hey, John, what did the skeleton say to the bartender at the ARIN social?
John Curran: What, Bill?
Bill Sandiford: I'll have two beers and a mop.
John Curran: Why was the skeleton so relaxed? Nothing gets under its skin.
From the Floor: It's only going to get worse.
Bill Sandiford: If it wasn't for the fact that it's dead time, I'd be the last person on stage telling jokes, I can assure you.
From the Floor: And you're telling skeleton jokes.
Bill Sandiford: You got that one, Owen.
John Curran: If you can't tell, we'll be soon coming to the community for a large funding request to automate the show of support so there's no lag and no delay. But first we have to soften you up with some jokes about why this delay is such a problem.
Bill Sandiford: All right. The vote counters tell me we're good. Now we need to see those who are not in favor of the policy.
All right. Vote counters are tabulating. Kudos to whoever made all the cards today orange, by the way. Thank you.
We continue to lose participants. Those in person and remote, 102; in favor, 32; against, zero. Thank you for your feedback. We'll pass it to the AC for their consideration.
John Curran: Thank you. Okay. Very good. The loss of participants has nothing to do with the quality of the jokes. I want to say that right now.
Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A
John Curran: Okay. So let's move ahead. Next policy up is Recommended Draft Policy ARIN 2019-10: Inter-RIR Merger and Acquisition.
The Advisory Council shepherds are Kerrie Richards and Rob Seastrom. The proposal started as ARIN Policy Proposal 270. It was made into Draft Policy in May.
It was recommended for adoption by the AC in September. This is the first time this policy is at an ARIN meeting.
The latest version is the 21st of May. And what it says is the intent of the Draft Policy is to clarify the circumstances where we have mergers and acquisitions happening between RIRs for organizations located between RIRs with compatible transfer policies.
I have to say we recognize when merger and acquisitions happen. If a company buys another company, company A buys B, then we recognize that B no longer exists and that we need to update the registry to reflect its new legal owner. The challenge is that what if A and B are in separate regions? We've been finessing this circumstance and attempting to make the registry consistent when it occurs.
And that means that, yes, it is possible if you're in one region and you're a member of an RIR and you already have resources and you come to ARIN and you buy a company in this region, we actually will help work with the total legal entity and get the resources registered correctly even if that means in another RIR.
It's not clear -- we're in this very interesting world -- we're not moving resources, per se, it's not the registry that's actually changing the allocation. This is a case of a legal entity change making sure the registry is accurate.
So we've been doing that, but it's not clearly delineated in the registry policy because it's not really about allocation of resources. The proposed change would not be a change from present practice, but would make the implementation very clear by putting a policy statement in the manual.
It's understood that IPv6 would be excluded since this refers to inter-RIR transfers which IPv6 presently is not part of the inter-RIR transfer policy.
So for that reason, this is literally the cases where we update, and we do that in cases where we know there's a compatible transfer policy between the RIRs.
We'd like to make the suggestion, staff made the suggestion that the change be made in Section 8.4 and generalize Section 8.4, but we can implement it either way.
The other note was that the third bullet in conditions we noted that it would be clearer with a different wording of that bullet.
Let me move ahead. The legal assessment. While staff has been handling these situations successfully, the proposed policy change would not materially increase our risk and should be considered if consistent with community's intent for handling.
That's really the key item here. In particular, we need to know if you want this policy. That would be a good way of reaffirming what we're doing. We definitely need to have feedback if we don't want to be doing this at all because we do update records for legal changes.
So resource impact. Typical policy. Three months after ratification by the ARIN Board. And very simple because it is an existing practice. Just clarifying things.
At this point I will have the AC presentation given, and that's going to be done by -- that's a good question -- Kerrie Richards. Come on up, Kerrie.
Kerrie Richards: Good afternoon, everyone. So I am the primary shepherd on the Recommended Draft Policy ARIN 2019-10. Thank you very much, John. You've covered quite a lot of what I was actually going to say.
So it's been happening. So ARIN has been dealing with these cases as they have come up. So merger/acquisition and re-org activity sometimes results in restructuring where a company resources the management of number resources, all those things. So the business case has been ventilated.
The policy statement or the suggestions by the staff and legal: So the staff and legal has completed on the 28th of August. And as John had said, the addition to 8.4 is this restriction does not include transfers completed on the 8.2 mergers/acquisitions and re-orgs.
We have gotten quite a lot of feedback on PPML. And as much, as we've already gone this far with this specific policy, one of the things I'd like to note, we don't have outright nos. We have persons saying they would support if there was a change in the wording.
And for that reason, we want to do a bit more work on this policy to ensure that there's no ambiguity. I see David -- that there's no ambiguity in this policy because cases have come up, they have been dealt with, but we have to ensure that the intent of the community is very, very clear.
And with that, I...
John Curran: Yes, we'll go to questions, and Vice Chair Mr. Sandiford will come up and moderate the discussion. You should stay up here to help in case questions arise.
Bill Sandiford: Thank you. All right. Calling on those to approach the microphones or submit their comments remotely. We'll start with the front center microphone.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I do not support the policy as written.
I would support the recommendations of staff in the staff and legal in how to reframe the problem or reframe the policy statement. The problem statement is pretty good.
I also have to say that I disagree with the staff's assessment of the current text that it excludes IPv6. I do not believe that is the intent of the current policy statement.
I believe that what staff is currently doing in its practices is consistent with the community's wishes, but I do not believe the current text is consistent with the community's wishes. Thank you.
Bill Sandiford: Thank you, David. Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I'm a little confused. An organization that no longer has really a nexus in our region can transfer the space today to a region that's more appropriate for them, and this sort of is meant to clarify that. Is that the gist of it? Because they could do that today.
John Curran: Are you asking what they can do today, or are you asking what the policy intent is?
Kevin Blumberg: I'm saying they can do that today. So what is the policy intent that's different than what they can do today?
John Curran: So the question is presently, for example, if you are -- if you acquire a company and you're located in the RIPE region and it has IPv4 resources and it's a complete acquisition, we can process that because we have compatible transfer policies. And we effectively make, as your entity in the ARIN region disappears, the resources appear in RIPE.
I'm going to note that that's not necessarily the case when we're talking about another region. So if we have a region that we don't have a transfer policy with, that doesn't occur and that that hasn't been implemented for resources other than IPv4. So those might not transfer. So --
Kevin Blumberg: ASNs have also been implemented.
John Curran: So your intention here is to clarify what you want us to do in these cases?
Kevin Blumberg: In the cases of resources that are not yet compatible to be moved.
John Curran: For example, if the community actually wants us in all cases to process M&A transactions no matter where they go to another region, there's operational coordination that needs to occur with the other RIRs to make that physically possible, because in some cases it's not possible.
So, that's why we're asking for clarity in policy.
Kevin Blumberg: I do not support this policy. If we had the ability -- we have the ability to transfer to regions that want to accept those resources, that is more than possible for the other regions who would like to have the compatible policies to allow for it as well.
But to jump through hoops to move things that shouldn't be moved in any other situation, I don't support.
Bill Sandiford: Thank you, Kevin.
Rear center microphone.
Charles Abramson: Charles from IPv4.Global. Would this work the other way as well, if there's a block in the RIPE region that we want to bring over to ARIN? How would that work?
John Curran: That also works fine because we have existing compatible transfer policies between the regions in both directions.
Charles Abramson: If there's an M&A -- let's say a US company acquired a RIPE region company.
John Curran: Right. That would work fine. The transfer policies are compatible between ARIN and RIPE and ARIN and APNIC, and we can effectuate an M&A transaction, and we have been doing so, absent -- even absent any clear policy.
However, if you want to have language in the policy manual that makes this, A, either universal, or, B, effective, specifically, you want it to be effective for v6 and ASNs, we would need to know that.
Charles Abramson: Thank you.
Bill Sandiford: All right. Last call. Any remote participants? No remote participants. All right. We'll move to the next phase, then, which is the statements of support. And I will ask you to thank Kerrie for her presentation.
All right. All those in the room and remote in favor, please raise your hand now.
All those opposed, raise them high, folks, nice and high.
We will tabulate.
(Jeopardy! music playing.)
From the Floor: Better than a joke.
Bill Sandiford: Thank you, Michael. All right. We gained a couple.
Total in person and in the room and remote, 107. In favor, four. Against, 11.
Once again, thank you for your feedback. It will be passed to the AC for their consideration.
Recommended Draft Policy ARIN-2019-15: Hijacking Authorization Not-intended
John Curran: Okay. Moving right ahead. Next up, Policy Block, Recommended Draft Policy ARIN 2019-15: Hijacking Authorization Not-intended.
The Advisory Council shepherds are Chris Tacit and Andrew Dul. It was made into the proposal on the 6th of May this year. Draft Policy this June, and recommended for adoption in August. First time at an ARIN meeting. And the version in the manuals, latest version, is the 22nd of July.
So very interesting one. Let's try this. We understand as staff that the guidance here is that addresses used incidentally are not a reassignment. Okay. And we believe that to be the intent and that this policy clarifies that; that it makes it more clear that IP addresses used by third parties in an incidental transient manner must be authorized for that use.
There's a question here that comes up. The draft policy talks about -- the problem statement talks about the problem of whether or not when someone uses addresses whether or not it's a hijacking or not and that we do have cases where people use addresses for conferences and others, and this clarifies that we don't consider those cases of hijacking as long as they're being used with permission.
There's no material issues. Minimal import, resource impact, and we would update the guidelines.
I'm now going to turn this over to Chris Tacit to do the hijacking presentation.
Come on up, Chris.
Chris Tacit: Thank you very much. So as John said, this is an attempt to just make sure that there's absolute clarity on the point that if there's authorization from the person to whom resources are delegated for third-party use that's incidental or transient, that this does not result in an unauthorized -- doesn't result in a reallocation or reassignment.
So this is the present text right now that we have in the note in Section 2.5, and these are the few words that are proposed to be added.
There's no intent to change the policy from the way that it's being implemented and that it's assumed to have worked, it's merely being clarified further.
We didn't see, as John said, any staff or legal concerns. And the way it's done right now is consistent with the way that staff interprets it.
After we made the last round of changes, there were some previous edits to this. A handful of people chimed in on PPML and said they liked it. No opposition has been expressed. And there haven't been any comments for some time on this draft, Recommended Draft Policy.
So the question is: Are the amendments proposed -- do they clarify the policy, and therefore should they be considered for adoption?
John Curran: Stay up here. We'll bring Mr. Sandiford up to moderate discussion from the queues. Go ahead, Bill.
Bill Sandiford: All right. Comments, please approach the microphone, or if you want to make your comments remote. This is about as exciting as John's jokes.
John Curran: Don't jam up the queues at once.
Bill Sandiford: Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. What's this fixing? I love the cleanup, Chris, don't get me wrong, but even if somebody says this is my space, what does this have to do with policy, per se? I don't understand the problem we're fixing here.
And is it that people are coming to ARIN saying I'm using this space, please SWIP it for me? I don't understand the -- I understand being pedantic, and that's helpful and the text makes it clearer, but the space is with an organization that has an RSA. It's their space to use. Some third party coming along doesn't have any rights to it. So I'm a little confused how this is fixing anything.
Chris Tacit: All I can tell you, Kevin, is we received a proposal. There's already a note clarifying what a reassignment is and isn't. The author thought that the current note could be improved because it wasn't crystal clear.
It was within scope, and the problem statement was clear, so we took it on. We don't view it as any big issue or any real deviation from what's happening.
John Curran: So in the definition section of the NRPM, what you have in your Discussion Guide, if you go into Section 2.5, you look at the last definition there. This is after allocation of assignment, reallocation reassignment. You'll see a sentence that says: "Note that the incidental or transient use of address space by third parties shall not be considered a reassignment or a violation of the exclusive use criterion."
There's belief on at least one member of the community's part that that's a statement endorsing you can temporarily hijack space and it's not a problem at ARIN; that the incidental or transient use of address space by a third party is -- doesn't have to show up in the registry because this sentence is in the definitions.
Kevin Blumberg: I believe this was the same author who originally proposed the addition who was then concerned about that so they wanted a cleanup of that, correct? That was --
John Curran: I'd have to go look at the author. I try not to associate; take everything on a level of ground regardless where it comes from.
Kevin Blumberg: They were trying to fix the first mistake. Does the word "authorized" create other problems by now having that specificity associated with it?
Chris Tacit: What do you mean not enough specificity --
Kevin Blumberg: No, having specificity that --
Chris Tacit: I don't think so. I mean, authorized by the delegated organization is fine. I mean, I don't -- as I -- I tend to agree with you that it was pretty clear. Clearly staff knew what to do with this and how to interpret it and the guidance it gave to the community on it. I don't think, frankly, it's necessary to spend a lot more time on this one way or the other.
Kevin Blumberg: It's gone all through the process. I wanted to understand.
John Curran: Effectively it's adding three words. Four words.
From the Floor: Five.
John Curran: Five words. It's adding "delegated to an organization."
Owen DeLong: And "authorized."
John Curran: I guess you're right. It's a very small addition for the clarity of language.
Bill Sandiford: Rear center microphone.
Kevin Loch: Kevin Loch, QTS. So my only concern with this is it seems to be implying that ARIN is not just publishing registry information but it's also policing routes. Maybe this is fixing something that's already in there, but I really don't like the idea of ARIN being the Internet police. I'd like ARIN to be the publisher of accurate registrations.
Bill Sandiford: For or against the proposal?
Kevin Loch: I'm still confused by it. So I'm not sure.
Bill Sandiford: Fair point.
Front center microphone.
Owen DeLong: Owen DeLong, ARIN AC. Policy-wise this is a NOAP. Clarification of language in the NRPM was: I think it does provide additional clarity. It is not ARIN becoming the routing police. I would strongly oppose it if it were. I actually do support it at this time.
It is ARIN saying: We're not going to view you as violating policy if you're operating within the bounds of this particular text. Because the original text, before this note was added, did potentially imply that, for example, if you were a Starbucks, you were not allowed to hand out addresses to your Starbucks customers because they weren't part of your organization.
I think adding this originally was rather pedantic, but, okay, it made things more clear, what the heck. This is in that same vein. And I believe that the horse is dead. It's been flogged enough.
But I think that putting this in does provide some clarity that was previously lacking. And so I view it as mostly harmless and potentially somewhat beneficial to other people being able to read the NRPM that aren't immersed in this stuff and don't understand that staff just does the right thing when it's not super specific.
Bill Sandiford: Thank you, Owen.
Rear center microphone.
Mike Burns: Mike Burns, IPTrading. I'm against the proposal. I don't want ARIN to determine what "authorized" means. I don't think it's important to have that in there. The "delegated to an organization" is a waste of words. I'm against it.
Bill Sandiford: Thank you.
Front center microphone.
Joe Provo: Joe Provo, Google, ARIN AC. Support as written. The intent was merely to clarify. And I would ask the folks in the room to please consider the non-native English speakers that are both in our region and outside of our region that are going to run the NRPM through translation tools and that this assists them in understanding our policy.
Bill Sandiford: Remote participant.
Kerrie Richards: Nick Kesari: Has there been a problem in the past? Is this fixing a problem that does not exist?
John Curran: We've not seen this potential problem actually occur, a case of someone reporting to ARIN transient use that might be a reassignment or a reallocation that is not adequately recorded. I'm not sure why they would bring that to us, in any case, but we have not had it.
Bill Sandiford: All right. Last call for participation.
Front center microphone.
Kerrie Richards: Anthony Delacruz has requested another joke from John.
Bill Sandiford: We'll see what we can do at the appropriate time.
I would like to thank Chris for his presentation. I'd ask you to join me.
And at this point we'll look for show of support. So I'll ask those of you in the room to raise your arms high if you are in support of the proposal. And of course those online to indicate for or against.
All right. And those against the proposal, please raise your hand high. All right. Thank you. Enjoy.
Why did the skeleton cross the road?
John Curran: Why did the skeleton cross the road?
Bill Sandiford: He had to get to the body shop.
John Curran: Very nice.
How do vampires ship things? Blood vessels.
Bill Sandiford: Front and center microphone is closed.
Just joking. Go ahead. I'm just joking.
Owen DeLong: Can I propose that before we do another John joke we do a show of hands whether we should do another John joke or not?
Bill Sandiford: We'll take your considerations into request before we deny it.
Total people in the room and remote participants, 111; those in favor, 19; those against, two.
Thank you for your feedback, and we'll pass it along to the Advisory Council for consideration.
Draft Policy ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool
John Curran: Okay. Our final policy of the Policy Block today, and we're going to cover Draft Policy 2019-17: Returned Addresses to the 4.10 Pool.
Shepherds: Alison Wood, Alyssa Moore. They look like that (referring to slide). This is actually not a Recommended Draft Policy. What am I doing? I'm going to turn it over to them, let them cover it.
It is a very interesting policy. But as it's not Recommended Draft, there's no chance that you won't see it again, they're just working on it right now. It's not necessarily -- it will not be sent to the Board of Trustees between now and the next meeting, but it's to get more input from you to help the AC guide its development. Come on up.
I don't look like that.
Alison Wood: Thank you, John. I want to reiterate that this is a Draft Policy, not a Recommended Draft Policy, which is what you've heard previously.
The Advisory Council really wants your input at the end of this discussion so we know how to proceed.
So my name is Alison Wood, and my very helpful co-shepherd is Alyssa Moore, seated over there. This is Draft Policy 2019-17, and the spirit of this policy is that of populating the waitlist is somewhat inconsistent and unreliable and is there a better way to do this.
All right. So we would just make some very minor changes to the statement, but it's a very major change to the way that we do business. So the IPv4 pool dedicated would be -- the incoming addresses returned from ARIN members would be returned to a pool that then facilitates IPv6 address space.
And the way this then would be -- I want to say this really clearly: The waitlist would then be decommissioned and all current requests that are sitting on the waitlists would be grandfathered in.
One more time. The waitlist would be decommissioned and those that are sitting on the waitlist today would be grandfathered in.
All right. This has gone through staff and legal already. So the policy can be implemented as written, and you guys have that. So a few things about that. So the 4.10 pool was started in February of 2011, and only 4 percent of that pool has been used. So there's a lot of address space in there.
And it is projected to last more than a few years. If this policy is implemented, ARIN would be unable to provide IPv4 address space to existing customers, new entrants, anyone. There would be no waitlist. So the option to people wanting to obtain space would be on the transfer market.
So I'm going to skip over the next slide, which is our "thank you" slide, because for discussion points I pulled some statements right from the PPML, and I wanted you guys to see those statements to encourage discussion. Because, like I said, this is just a Draft Policy. We really need your input to further or not further this policy.
So just to read them really quick. Could this policy help with fraud? Would this sequester space where it cannot be used? If it goes into this, could we -- would we be taking -- receiving space back in that couldn't then be given back to the community? Is this the end of the free pool era? And populating the waitlist today is haphazard and unpredictable.
So I'm going to go back to myself and Alyssa, and we very much appreciate your discussions and questions today.
Bill Sandiford: Award for most colorful slide today goes to Alyssa and Alison.
We'll start this time with the far microphone. Who is declining. We'll start with the front center microphone.
Cathy Aronson: Cathy Aronson. I just have a little nit. Could we not call it a pool? Like an IP address pool? Or something more specific than a pool? Because I'm just not sure how I feel about the policy, but I think that that's not clear.
Alison Wood: Yes, thank you.
Bill Sandiford: Rear center microphone.
Kevin Loch: Kevin Loch, QTS. I support this. I think the 4.10 is great. I support its mission. I would prefer that the addresses not be issued at all; that ARIN start building a pool of addresses for future use, things we haven't imagined yet that we may need down the road five, ten years from now.
I think the waiting list is kind of misleading those that need larger groups of addresses, they really should be going to the efficient open market to acquire those. And putting them on a waitlist for two years is kind of misleading them about what they really should be doing right now.
Bill Sandiford: Far microphone.
Kevin Blumberg: Kevin Blumberg, The Wire. I don't think this should be limited to the 4.10 pool, reserved by people. We have many reserved pools, and they all, quite frankly, have even far more important aspects -- the micro-allocations for critical infrastructure pool, the IP pool.
I believe this should be expanded to all the reserved pools that ARIN has. And what I think it really should be about is about making sure that the reserve pools receive priority; that space that comes back allows those pools to get refilled so that they aren't drained down over the waiting list.
So what those numbers may be, if it hits 20 percent, you get X amount back, whatever it may be. But all of those reserved pools are just as important as each other. They should all be taken care of with this policy, and it should just be to the priority of, but we should not just stall all of the space in a pool that is never going to get touched.
Bill Sandiford: Front and center microphone.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I kind of like what I just heard Kevin talk about. However, I will note that none of the reserve pools are in any danger at this time. They probably have many years before we have to worry about this.
When that time comes, what Kevin's talking about seems to make sense to me. So I do not support this policy particularly at this time. The waiting list is doing useful things for some people.
Yes, it's limited to who it's useful for. But as was stated earlier, we're dealing with what is possible in the art of the possible. And making sure everybody can have access to resources through the waiting list is not possible today.
Bill Sandiford: Thank you, David.
Rear center microphone.
Owen DeLong: Owen DeLong, ARIN AC. Could we go back to your questions slides. That's an eye chart from here.
So end of the free pool era, probably, but this isn't the policy to do it. Will it sequester addresses? Yes, it absolutely would. And for that reason I oppose the policy. Could this help with fraud? I can't see how it's going to enable fraud, but it probably has some way that somebody will figure out, but I don't think it makes things generally worse or better in regards to fraud.
I think overall that the status quo is far superior to what is proposed here.
Bill Sandiford: Far microphone.
John Petrakis: Hi. My name is John Petrakis with Stratus Networks, and I'm one of the owners, and I'm here with the other owner, Kevin Morgan, one of our engineers, Tom Pruitt. And if anybody agrees with some of the things I'm about to say, please come talk to us.
This is our first time attending this, and we're learning an awful lot. Thank you for being patient with me in advance here.
So what I want to talk about doesn't directly relate but it indirectly relates to what you guys have up here that you're considering because it would end the pool.
And we did it the right way at Stratus Networks when we started it. We're an ISP serving businesses Internet services and other communication needs.
And when we started, we asked for a /24. We got a /24. Then we needed more IP; we went to a /22 and then to a /21. We ended up with a little over a /20, and we were eligible for a /19.
By then there was a waiting list. We put ourselves on the waiting list. And no fault of our own, we didn't create any fraud. In fact, the more I talked to people, we did things by the book compared to a lot of other organizations. A lot of other organizations figured out how to sneak more IP addresses through other means.
We can prove our justification. We would welcome an audit to prove our justification. And so we were on the list. And because somebody else committed fraud, you guys came out with a ruling and first killed the waitlist but then re-implemented it with a rule of a /20.
I would advocate that you keep the waitlist and you grandfather the 30 companies or so like ourselves that were on that waitlist. And then if you want to cure it after you honor who was on the waitlist, then, fine, do so. But we shouldn't be punished.
We spent a lot of time on that waitlist, from being a couple few hundred people on that waitlist all the way to the top, then you killed the waitlist with the restriction also as a /20. We shouldn't have to go to the secondary market at this point.
We're not -- no offense to our friends at Google and AT&T and Amazon who can afford and are big companies using a lot of IP addresses; that it seems like you put this rule in place to protect the little companies. Well, we're caught in the middle. We're not tiny, asking for a /24 anymore, but we're not asking for a /8 either.
So we would advocate one of your tenets is to be fair, and we don't think we were treated fair in this circumstance. So I'm not only against this particular item that you're voting on and debating, but I'm also going to try to put a motion or work with the proper people to try to put together a proposal that you get rid of the /20 and grandfather the folks who were on the list and put them back on it; and then if you want to make your changes, you can.
So, sorry for the long speech. Thank you.
Bill Sandiford: Thank you for coming to share your views.
John Curran: If I could ask a question back. So I would highly recommend, if you want to make a change to policy, anyone who wants to talk about the waitlist and the limit, the max size limit, you can't have more than a /20 worth of IP addresses, seek him out. Good opportunity.
I will ask one question. When we suspended issuance from the waitlist and we posted that to the community and had the AC working and the AC put its message out on the Mailing List, did you file any comments against the change to put a /20 limit in?
John Petrakis: My engineer is nodding his head affirmatively.
John Curran: I guess that has been something that was discussed on the list. But at the end of the day, the community, we ended up moving ahead and restoring. Certainly, if the community wants to continue to change the waitlist policy, I recommend proposals to do that. I want to know how involved you were in the process at that point, and it's helpful to know.
John Petrakis: Well, we're learning how to become more involved. And we've talked to several folks that are on the Advisory Council, and we plan to work with them and get them more out here.
John Curran: It's your registry. Let's get some policy that works for you.
John Petrakis: Thanks.
Bill Sandiford: Front and center microphone.
Chris Tacit: Chris Tacit, Tacit Law, ARIN AC. I oppose this policy at least at this time because I think it's contrary to ARIN's ethos of needs-based provision of resources. There are a lot of startups and small ISPs who might either not be in business or whose business plans would be delayed significantly if they didn't have access to the waitlist.
That's why it's there. And I think we need to sustain it, especially when there's no scarcity in the other pools.
I think if there was a contest between this waitlist and other pools, then that might be worthy of discussion and perhaps recalibration. But as was pointed out, there is no problem anywhere else. So I don't think we should pass a policy that is meeting actual needs in order to fulfill a speculative need that may never materialize. Thank you.
Bill Sandiford: Rear microphone.
John Sweeting: John Sweeting, ARIN staff. I think I'm going to answer Joe's question. So in the 4.10 pool, the IP pool -- sorry, Cathy -- there are 15,727 /24s left. 657 have been used over the time since it was implemented. And it puts about an average between 10 and 15 a month.
On the 4.4, there's 123 issued. 389 left and about 1.5 per month. So maybe 15, 18 a year.
Bill Sandiford: Thank you, John.
John Sweeting: I think the numbers speak more than the percentage.
Bill Sandiford: Joe.
Joe Provo: Joe Provo, Google, ARIN AC. Don't walk away, John. You got almost all my numbers I was going to ask you for. He reads my mind. I was going to ask also what is the projected run rate based on past performance? I think you shared that with us before, so I just want to make sure.
John Sweeting: It's about 15 a month on the 4.10. So that would be about a thousand months before 15,000 would go out. 4.4, it's like one and a half a month. 389 -- 260, 260 months.
Joe Provo: I'd say I oppose the policy as written. I oppose as intended. And in a couple hundred months we revisit what we need to do there.
Bill Sandiford: Rear microphone.
Kevin Loch: You can go first.
Bill Sandiford: All right.
Kerrie Richards: Matthew Wilder, Telus: I like the idea and also would like to see them set aside for future purposes and not immediately allocated to 4.10 necessarily.
Alternatively, I would also be interested in introducing the qualification for the waiting list to stipulate that the IPv6 must be deployed in order to qualify.
I have another one.
Bill Sandiford: Go right ahead.
Kerrie Richards: Gary Buhrmaster: I think what Kevin mentioned has value. Fill the reserve pools up to whatever the community agreed was the appropriate size first, and only then make them available to the waiting list. This would be an ongoing process. For example, if addresses go out of the critical infrastructure pool, then it gets placed at the head of the end of the grandparent lane to get new returned addresses first well after the grandparents.
Bill Sandiford: Rear microphone.
Kevin Loch: Kevin Loch, QTS again. I do support this again. Some people have commented that they're concerned about addresses being stranded in this pool. There's already too many for the current run rate.
Remember, they can always be reallocated to other uses or other pools in the future. And I think putting them in this bucket, the fact that the run rate is so low, does further my goal of ARIN building up a pool of addresses for future, currently unknown uses.
Bill Sandiford: Thank you. Front center.
Scott Johnson: Scott Johnson, SolarNetOne. So, fundamentally, we all can probably agree that IPv4 has some irreconcilable flaws that IPv6 addresses. For close to three decades now, the IETF has been working on this problem.
I personally was part of the 6bone with the 3ffe deployment, and I have worked in an engineering fashion to help implement IPv6 throughout the time period since, including implementing on all of my networks and encouraging all other network operators and owners to implement it.
I think in arguing over semantics and construction of the mechanism to fight over the scraps of a system that we have engineered a replacement for is the wrong course of action for the community as a whole.
I believe that moving in a direction that will allow implementation of IPv6 as a replacement for IPv4, where practical, and that includes the IETF working toward, say, replacing dotted quad as a requirement for a router identifier, is probably the best course of action and will allow all us to have the necessary resources we have in functionally infinite fashion to address every device that we need to bring online.
The roadblock has primarily been commercial forces, as represented by essentially edge providers and others who have monetized IPv4 and do not want to give up that financial stream.
And this is holding us back as a community as an Internet. Thank you.
Bill Sandiford: Thank you.
Front and center again.
Aaron Hughes: Aaron Hughes, 6connect. I guess first a question of clarity. What is the intent of this Policy Proposal? Is the discussion about what to do with reclaimed space, or is this -- versus, say, the waiting list versus the question of putting things in 4.0 and 4.10?
And I'll add the reason I asked the question. If we add something to, say, 4.10, it becomes nontransferable by policy today, and it makes it difficult to discern the difference based on the allocated resource.
Tracking that as operators for us is challenging. Then we have to do extra verification with the RIR to say, hey, is this a block that we can actually transfer by policy? We don't know based on which pool it's coming out of, as one simple example.
Alison Wood: Thank you for the question. When the policy was submitted, the intent of the policy was to correct an inconsistent stream of IP address space coming back to the waitlist.
The original intent was to correct that issue and effectively take the IP addresses that were coming back and put them into an IP pool that would be used under policy and eliminate the waitlist so that there wasn't this inconsistent stream of coming in and going out.
And I don't think the original policy stated that it would go to the transfer market, but that would be -- if you look holistically at this policy, that is a consequence of the intent.
Does that answer your question?
Aaron Hughes: It does. My feedback on this is, is I don't think we should put anything else in the 4.10 or 4.4 pools. I think conversations about more creative ways to figure out how to get what we want out of this community, the collective community, would be better focused on what kind of carrots would be forward progress.
So, hypothetically, if a carrot is v6 adoption, even if we have something like a waiting list, maybe we have a requirement that there is a visible public host of service that is v6 accessible. People need v4 resources for other reasons. People certainly want them on the transfer market.
And while we're trying to protect ourselves from some level of fraud, we certainly want to get v4 resources out there and where they need to be appropriately. So maybe it's time to explore some other carrots.
Bill Sandiford: Thank you. Last call for microphones and remote. Going to the far microphone.
Kevin Morgan: Kevin Morgan, Stratus Networks. If I understand the policy correct, there was a grandfathering of people on the list in this policy. I guess I just have a question: Why? What is the rationale behind grandfathering them in?
Alison Wood: So I guess maybe John should speak to the rationale, but when we put this policy together and made it fair and impartial, we felt that it was -- the way this policy was written -- fair to implement this policy after those on the waiting list had received their IP address space based on the needs.
Kevin Morgan: I think you just proved the point of what my partner had spoken about, fairness.
Bill Sandiford: John.
John Curran: Actually, I was trying to figure out how to say the same thing in a different way. So the Advisory Council, when we did -- when the Advisory Council did 2019-16, the waitlist resumption, it took care to make sure the people on the list had the option to reset their existing request, if it was larger than /22, that we would ask each party: If you're looking for more than a /22, you can get asked to only get a /22. So that aspect of grandfathering was considered.
What wasn't considered is for the people who had total holdings greater, a /20 or greater, and therefore were disqualified under the new policy from getting anything, whether they should be grandfathered.
In my history of the recollection of the discussion, I don't know -- the AC members may know, but clearly the policy as implemented didn't have language as this did. If it did, we would have implemented it, whatever it said.
But because it wasn't that clear, the people who had address holdings /20 or larger were not grandfathered in because this policy wouldn't allow someone else to get that.
So I guess I'm proud of the AC for putting specific language in one way or the other for the policy going forward. But for what it already did when we resumed the waitlist, it did not contain grandfathering language. So staff did not implement it.
Bill Sandiford: All right. Last call again. Microphones are now closed but those in queue.
Front center. Go ahead.
Owen DeLong: Owen DeLong, ARIN AC. My recollection of the discussions -- and this is me speaking as myself and only about my recollection -- is that it was considered and that we decided that the potential for fraud from permitting that extended grandfathering exceeded the benefit.
There may be people who disagree, but I believe that was the conclusion we came to, but that we did consider it. And I'm open to being corrected if I'm recalling that incorrectly.
Bill Sandiford: I think --
Owen DeLong: It was for the original waiting list resumption.
Bill Sandiford: Last comment, rear microphone.
Mike Burns: Mike Burns, IPTrading. I was the policy author. I wanted to provide a little feedback.
When I changed the single word from IPv4 "block" to "pool," I didn't consider certain objections. So I think if that was changed to "pool" or "pools" or "IP pool" or whatever, that's fine. But also the comments that have been made about the other pools, and I didn't consider those when I authored this policy.
So I think further discussion in terms of returning addresses to pools other than the 4.10 pool are worth it for sure.
Bill Sandiford: All right. I'd like to thank the world record woman's high jumper, Alison Wood, for her proposal.
This was not a Recommended Draft Policy. So by definition we aren't required to do a show of support of hands. But given the nature and length of the discussion and also noting that we're about eight minutes ahead of time, I would look to the two AC Chairs and Vice Chairs and ask if you would like to see a show of support from the members or not, if you feel it's beneficial to you at this time.
Tina Morris: Sure.
Bill Sandiford: All right. So this is just for informational purposes only to guide them in their further discussions. So those in favor of this proposal, please raise your hand.
Also remind those online, either for or against, put your comments in now. All right. Thank you.
And those against this proposal please raise your hand.
Thank you. So between policies, I got a text message from Nancy Carter. As you know, she's not here; she's on her way. But she had a question for you. She wanted to know if you knew why spiders make great web developers.
John Curran: I do not know. Why do spiders make great web developers?
Bill Sandiford: Because they love finding bugs.
Is she here now?
From the Floor: She stepped out.
Bill Sandiford: She sent it to me before --
John Curran: I'd step out before I told that joke.
From the Floor: That one laid a few million eggs.
Bill Sandiford: A-ha. All right.
Total in the room, 110; in favor, three; against, 19. It will be given to the Advisory Council in an informational capacity.
John Curran: Thank you. Excellent job.
Public Policy Meeting, Day 1 - Open Microphone
John Curran: Okay. We're coming to the valuable Open Microphone session. This is the opportunity to raise any issues we haven't discussed, any follow-up that people didn't get a chance to put in. We have one of these -- we actually do one at the end of each day in case someone wants to address the community.
This is their opportunity. And I recognize the mics as open. And the back middle mic, our esteemed General Counsel, Steve Ryan.
Steve Ryan: I just want to reemphasize how we do things here. We really need to be careful about using the names of other companies when we discuss public policy problems; that we don't use the names as euphemisms for a category of companies; that you can talk about large companies and you can talk about hosting companies. You can talk about cloud companies. But I'd prefer that people not use their names as we do that.
Remember, everything here is an industry meeting that's permitted to do what we do -- standards setting, deciding policy. And in order to keep that safe, we just have to be careful how we do it.
And you do this very, very well. Just a reminder at the end of the day how we'll conduct ourselves tomorrow.
John Curran: Thank you, Steve.
Center front mic.
Chris Woodfield: Chris Woodfield, Salesforce, ARIN AC. During the discussion of the last Policy Proposal, it occurred to me that we did the informational roll call vote, which is a standard "Do you support the policy as written? Do you not support the policy as written?"
How often, if ever, have we done similar roll call votes with different questions about policies? Like, for example, I was thinking to myself during the last show of hands was could we have had a roll call vote asking the room if anyone agreed with the intent of the policy, but if more work was done to figure out what would have happened, what would it have done with the returned space as opposed to just putting it in the transition pool.
That's just an example. But I'm wondering if there's any room in our procedure for more -- not just "for" or "against policy as written" roll call votes in this room.
John Curran: As it turns out, there's 20 years of ARIN videos online. And some of them, if you knew which year to look and which meeting, you'd see me saying to someone point-blank: No, you're not going to call that question out for a vote because it hasn't been discussed.
So I ask the AC, if you want to poll on some other matter, put it in your slide so that the Chair or the Vice Chair knows, but also so the people can have discussed it.
If the question is would you rather see this policy with a /18 than a /16 in this sentence, ask people. Let's talk about just that. Do you like /16 over /18? And have a discussion about that. And then it's easy to ask, regardless of whether the policy moves forward, let's talk about should the text say /16 or /18.
What gets complicated is when you haven't done that setup in the discussion and then you get to the end and you ask for a show of support. Then someone says, wait, are we saying /16 or don't adopt, or are we saying /18 or abandon, what's the permutation matrix?
So if you wish to have a discussion and poll upon something specifically, happy to do it. I ask the AC shape that in a slide so we can specifically talk about that and we know what A and B is, because otherwise, doing it on an ad hoc basis, I guarantee you some people raising their hand do not know -- or different people raising their hand have a different view of what it is they're supporting when you do it on an ad hoc basis.
Chris Woodfield: So the answer is yes, we could do that, but we could not do that on an ad hoc basis.
John Curran: Well, not unless you want to have a particular discussion, you want to have the discussion and do a show of support on a clear question. Thank you.
Kevin Blumberg: Kevin Blumberg, The Wire. I wanted to speak to what Chris brought up here. When it was tried, it failed miserably. Consistency on recommended questions are critical for the community. They're critical for me. I know what I'm going to be asked, yes/no, move it forward.
And there needs to be discussion, not random anonymous voting on random anonymous questions that confuse the community as much as the reason why it was brought up was because the policy was confusing as well.
So when it was done, I found it was actually worse than just having a good discussion and furthering it until it could be voted on for a yes or a no. Thank you.
John Curran: Thank you.
Lee Howard: Lee Howard, IPv4.Global. To exactly that question, I know we have in the past -- or let me -- I would like to suggest that for Draft Policy, so things that the AC is only beginning to discuss, that maybe an appropriate question in every case is, all right, this isn't the final version maybe, but even if you oppose should we continue work in this area. We have done that question.
John Curran: That's common. That's actually, quite frankly, on non-recommended policy, policies that are in draft, the most common question is, is it worth continuing to work on this or should we adopt it? Now, even in that you just asked two questions. So we generally ask people to just ask one.
Should the AC abandon work on this? It's very clear. If you get affirmative on that, that's clear guidance to them. That's the most common question asked. I don't think -- it's not the end of the world that it wasn't asked.
And sometimes the AC comes to its own conclusion based on discussion on the list that policy side is called for and either merges or kills off one.
Lee Howard: That's why we elected 15 smart people to the AC.
Betty Fausta: My name is Betty Fausta. I'm a Fellow for the first time here. I want to thank this organization of ARIN for everything and particularly for -- we have a really proud team. They are welcoming all Fellows.
So I have just a remark as a new ARIN member about the PPML list, Member List, because we see a lot of information. And I observe as a newbie, someone new in this organization, that people speak a lot that can have a domination on the information about some proposal, and some people couldn't propose something different because they are in a minority or maybe they say maybe what I can propose is not correct because there's a majority of people who talk a lot say something.
So I suggest to maybe to think a way for the evolution of the PPML list, because this is a good idea to prepare policy before, but it's so messy for me, and particularly my mother tongue is French and Creole. So it's really hard to follow every policy.
John Curran: Understood. So I want to comment on that because it's a great point. We do use English as our primary language here, and that requires, for some cases, that people understand it's important for us to go fairly slow, even when people have passionate ideas, to let people speak slowly so other people can work.
But it also means that we need to take the time to explain ourselves. Because a lot of times this policy material, it's not that it's complicated -- it's not that it's complicated itself, it's because the people in the room already know so much, we've been doing it for so long.
So I do ask people to take the time to explain why you're doing -- why you're saying what you're saying; when you come to a mic with a comment, be explicit. Don't just say what you're saying, but say: I'm saying this, and that's why I'm against the policy.
A lot of people in the room know if you're speaking and you say something they can interpret whether you're for or against. We ask people be clear and say your reasoning, because, again, it's not easy for everyone. Excellent point.
Center rear mic.
Robert Seastrom: Rob Seastrom, ARIN AC, Packet host and speaking on my own behalf. Thank you very much for open microphone at the end of the first day. I appreciate it. I've characterized open microphone as agenda bashing for the hallway track.
And I appreciate having one at the end of the first day, which has not always been the case.
John Curran: Understood. Thank you. On that point, open microphone remains open. Putting remote people -- but I'm going to close it shortly. Don't want to dominate the evening with open microphone.
If you have a matter, approach the mics and speak because I'm closing them shortly.
Remote participant, yes.
Kerrie Richards: Nick Kesari: I want to encourage the idea of amending policy to make leasing IPv4 numbers possible, without the numbers owner losing control of their block. It would make the market more dynamic and safer for possible bad actors -- from possible bad actors.
John Curran: Something for people to think about and either get together and work on policy for or -- go ahead.
Scott Johnson: If I can speak to that last point from the remote participant. Nobody owns the numbers they're assigned.
John Curran: Right. Let's cover that briefly. Integers are integers. You can configure your router with what you're configuring them. But there's a registry. And when people are issued address blocks, we associate their name with an entry on the registry, and it's been done that way since the dawn of time.
It's the fact that you're in the registry that makes it important because it means other people aren't in the registry for the same numbers and hopefully therefore aren't configuring their routers that way.
We only control the registry. That's what we control. It's been called the Internet Registry for years and years. And you are cooperating with everyone and these rules and you have this cooperative registry, and as a result of that the most important thing is that you have to participate in those rules to make it valuable. That's the policies that you develop.
But at the end of the day, all you get is the rights that you're provided to, we provide you a contract that's explicit with the rights, rights to be associated with the entry.
In terms of ownership, I'm not sure if any term "ownership" is really meaningful. But if people want to discuss that, feel free to find me.
People have rights to numbers. That's what we talk about. You're the address holder. You're the rights holder. Feel free to use that language. And you can sell rights. We have people in the transfer market to sell those rights. But our ownership is a strange term when applied to address blocks.
Certainly you have rights to address blocks and you have the right to sell them, and that's all called out in policy.
I'm going to close the mics. Open mic is closed. Thank you, everyone. I'm going to move to our closing slides. I'm going to talk about what's going on now and tonight. Some pretty important stuff.
Public Policy Meeting, Day 1 - Closing Announcements and Adjournment
John Curran: So closing comments. Vote. You vote for the Board of Trustees. You vote for the Advisory Council that works on these proposals on your behalf. You vote for the ASO, the ASO -- sorry, the NRO Number Council, also known as the ASO AC, which is the organization that handles global policy development.
So, if you're a member, members in good standing can vote. Go online to ARIN Online, and click on "Vote Now." If you have a challenge, find the Elections Help Desk or drop us an email.
Thank you for our sponsors: Network Sponsor, AT&T; Webcast Sponsor, Google; and Meeting Platinum Sponsor, Addrex. Big round of applause.
Okay. Tonight's social -- I've said it a few times. Walking distance. Sixth Street, which is right up the road. It's Maggie Mae's, and it's going to have delicious food and drinks and music. It should be lovely. If you have a costume, wear a costume.
Okay. Bring your name badge or your social badge. If you have a social badge, take it out of the back, you can put it on -- it fits better on your costume that way. Okay.
So what else? Don't forget the meeting survey. If you liked how we did things and any of the sessions we did, if you didn't like how we do things or any of the sessions, if you have an idea, fill out the meeting surveys. We take these very seriously. It's how we refine how we do these meetings each time.
Oh, by the way, we'll look at the responses and draw one in our random number generator for a chance to win an iPad Air. If you fill out the meeting survey, give us feedback, there's a chance you might end up with an iPad.
Reminders: Tomorrow is breakfast. And then the Public Policy Meeting here will start at 9:00. We have a final block of policies to be considered.
We'll have -- lunch is at the break, boxed lunches, and then the Members Meeting, which is open to everyone. You don't have to be an ARIN member, but we actually do a report on ARIN at the Members Meeting from all departments and the Board of Trustees reports and the treasurer reports. We do that at the Members Meeting in the afternoon. All materials are online, and we welcome anyone who wants to stay for the Members Meeting to stay.
Okay. I'd like to congratulate Susan Hamlin. Susan, congratulations. Stand up, Susan.
Susan has been with ARIN nearly 20 years. She runs the department, the Communications and Member Services Department, that makes this meeting possible.
And we've had the benefit of her services for 20 years. She's been literally an essential part of ARIN, and a lot of people come up to me and say we like your meetings, they're so well run and so well organized. It's not me; it's her.
And the reason that we're doing this, recognizing Susan, isn't just because of her lengthy service, but we're going to lose Susan. Susan is retiring. She will be retiring at the end of this year.
And so Susan will be moving on to greener pastures, and we're actually going to do a toast to that outside immediately after this meeting. If you walk outside, we shall have a champagne toast.
We're actually proud of the staff who are with us so long they can actually go from us to greener fields and happy retirement. So I'd like to ask everyone to join me outside now, and we'll toast to Susan. Thank you.
(Meeting recessed at 5:00 PM.)