ARIN 40 Public Policy Meeting, Day 1 Transcript - Thursday, 5 October 2017

Table of Contents

Public Policy Meeting, Day 1 - Opening Announcements

John Curran:  If people will come in, we'll get started.  Good morning.  My name is John Curran.  I'm the president and CEO of ARIN.  I'd like to welcome you to the ARIN 40 meeting in San Jose.  Thank you.

We're here to have a great couple of days, work on policy, get updates on how the organization is running and how we're working with other organizations, and should be fun filled. 

I see we have a good-sized number of people, not as many as NANOG.  Back of the room we could set up some volleyball courts or something.  But please come in and get to the front here.  And we will start right off doing introductions. 

So, let's see, if I could bring up my first slide.  Welcome slides.  Very good.  Okay.  I'd like to start off by saying we have a number of people present.  That includes the ARIN Board of Trustees -- our chair, Paul Andersen, who is up here; myself on the Board; Patrick Gilmore, who I know is out there; Aaron Hughes; Merike Kaeo; Bill Sandiford; and Bill Woodcock.  All the Board members are here. 

We have the ARIN Advisory Council, which is the one that does the heavy lifting when it comes to policy development.  And that includes Dan Alexander, our chair.  And then all the members of the AC, please raise your hand.  That's the ARIN Advisory Council.  If you have a question for policies under development or have an idea for one, find one of these gentlemen, or gentleperson. 

Oh, yes.  Next slide.  Might be an operator error here.  There we go.  The NRO Number Council, which works on global policy.  We have Louie Lee, Jason Schiller, and Kevin Blumberg.  Gentlemen, raise your hand.  Yes, yes and yes.  Very nice.  These folks are the contingent from the ARIN region that participate in the Number Council. 

We also have a number of guests from other RIRs, our RIR colleagues.  Folks, if you're from another RIR, raise your hand nice and high.  Helping us work on one global registry.

Okay, the ARIN management team is present, myself, obviously, CEO.  Nate Davis, the one who does all the work.  Where are you, Nate?  Thank you, Nate.  Cathy Handley and Anne-Rachel.  Anne-Rachel and Cathy, stand up.  Where are you? 

(Applause.)

Okay, very good.  As people may be aware, Cathy's put in many, many years at ARIN.  And we're at the situation now where she's going to get some additional assistance from Anne-Rachel, a very happy addition, and we'll take it from there. 

Richard Jimmerson, our CIO, over here.  Thank you, Richard.  Erin Alligood, HR and Administration.  Erin, where are you?  In the back.  The one who makes all the staff happy.  The person who actually puts this meeting together, her and her staff, Susan Hamlin.  Susan, stand up, please. 

(Applause.)

Our head of Engineering, Mark Kosters.  Mark, where are you?  In the back.  All your technical problems, go find Mark.  You're going to anyway.  I might as well point him out. 

Leslie Nobile, who works for me.  She's our Senior Director of Global Registry Knowledge.  Leslie, where are you?  Way over there.  Leslie's doing work, helping to keep high accuracy registry and working with folks with other RIRs on initiatives, law enforcement, things like that.  So, round of applause for Leslie. 

(Applause.)

And then the gentleman who is keeping everything running back in the shop while Leslie goes off and does that is John Sweeting.  John, where are you?  John in back.  He's our RSD Director.  Thank you, John Sweeting. 

(Applause.)

Billing, Val, you in the room here?  Very good.  The person you pay your invoices.  Val runs Financial Services.  Round of applause for her.

(Applause.)

And then our last staff was just up here.  Michael, where are you hiding?  My Associate General Counsel, Michael Abejuela, is the one who handles all your contract work.  When you're trying to change an RSA or have a problem with compliance, you talk to Michael and I. 

We have the management team here.  We also have our fellows here.  Our ARIN 40 Fellowship Program provides funds and support so that fellows can come attend the meeting on a small stipend for support and learn about ARIN, bring that message back to their community. 

Fellowship Program has been remarkably successful.  So we have -- this year we have a handful of Fellowship recipients.  So all the fellows, raise your hands, nice and high.  These are our fellows from Canada and from the US and our fellow from the Caribbean.  Where is our Caribbean -- very nice. 

Each fellow is assigned a mentor, someone who will work with them.  And the mentors are here to help guide them through, explain how we do things and answer any questions we might have.

I'd like to also point out -- oops, that's a fellow from the outlying areas -- I'd like to point out we have a number of newcomers at this meeting.  We have 52 new attendees who have not been to an ARIN meeting before. 

And the newcomers all attended our session which was yesterday afternoon, get to meet the ARIN staff, learn about ARIN, and we have a prize drawing now. 

So, I need someone to come up and help me do the drawing, some member of the audience.  Owen, are you hiding here?  Yes, come on up, Owen.  There you go.  Glad you're here.  I like consistency.  Very good.  Just one, unless you're giving out one this year.  No.  Okay.  Just one.

We do a survey at the end of our Fellowship Program, at the end of our Newcomer program, to make sure that we have orientated, so that we have good information.  It's a very important form of feedback to us.  And as a result, people who complete the survey are put in the running for a gift certificate. 

And Marie Holen, are you here?  Raise your hand.  Yes, we're going to email you the gift certificate.  Thank you for completing the survey.  I thank all of our newcomers for completing the survey.  They provide essential feedback to us.

On with our program.  Couple of little details.  Remote participants, we have a number of remote participants.  The remote participants have access to the webcast, a live transcript of the proceeding. 

Because we have a live transcript of the proceeding, and I should tell myself that before I get up here, we need to speak slowly and clearly.  I'm from Boston; that doesn't come very well for me, but I'll try.

So when you're out here, please speak clearly, slowly for the sake of the person doing the transcription. 

We have all the meeting materials that you have, the remote participants have.  There's also a chat room where remote participates can ask questions and can participate in the show of hands for policy consensus. 

Emergency procedures.  You're in a ballroom.  There are exits.  If you need to leave here for an emergency, like a fire or disaster, head out the exits.  They're all marked.  Run across the street.  We'll all gather over there at the park, directly across from the Market Street exit. 

Wireless SSIDs.  If you were here for NANOG, you already know this.  NANOG-ARIN is 802.1X secured.  And NANOG-NANOG, NANOG-ARIN-Legacy is an open, unencrypted one.  Use one of those.  Very happy to share the network with NANOG.  That's sort of seamless moving from one to the other. 

Attendance stats.  So we have attendees from Canada, nine; from the United States, 123; four from the Caribbean; 40 from outside the ARIN region; 21 remote participants.

I'd like to thank our two sponsors, Zayo and Google, network and webcast sponsor. 

(Applause.) 

And then I'd like to remind everyone during the afternoon break to claim your ARIN t-shirt.  We have t-shirts, the sunny ARIN logo on it.  So during the afternoon break, head to the front and turn in your ticket and get your t-shirt. 

We're coming up to our 20th anniversary.  Okay.  You may be asked about fond memories of times at ARIN, particularly those who have been here as long as I have.

Don't be surprised if staff walks up to you and says, "Tell us about your experiences at ARIN over the last 20 years."  We're building a number of quick videos and information that we'll put online when we have our anniversary celebration. 

Okay.  So I'd like to now -- oops, one more.  Interesting remote.  Okay.  If you want to have a copy of the agenda, your ARIN 40 app, you can download.  And that has convenient access to the agenda and all the materials. 

Rules and reminders.  When you come up to a microphone, speak clearly, state your name and your affiliation.  The chair is going to moderate things so that everyone can be heard.

Be polite.  If you've already spoken on something, when you come back up let other people speak first before you go and take the microphone again. 

We want to try to make sure that everyone has a chance to speak.  And there's a list of courtesies and rules in the program.  If you have your Discussion Guide, you can find it there. 

So here's the agenda for today.  Kind of busy.  We're going to have an AC On-Docket Proposals Report, which is everything that the Advisory Council is working on. 

We'll have an update of the Policy Development Process and each of the RIRs.  We'll have an Internet Number Status Report, giving the status of the free pools. 

We'll have a Policy Implementation and Experience Report, feedback from the staff on a number of policies, how their implementation has gone.  Things to think about in terms of developing policy. 

We'll have an update on our second customer survey, which is soon to happen.  We'll have a report from the IETF activities reporter.  We'll talk about the ARIN website, which is being redesigned.  We'll have the ARIN Election procedures and candidate speeches.  We'll do an update on the Caribbean, and then we'll have an open mic session.  A lot of information today.

We also have a number of policies we're going to be talking about.  We have four draft policies on the docket.  We have an update on annual Whois POC validation.  We have change to the definition of community network.  We have the removal of -- the removal of reciprocity requirements for inter-RIR transfers.  And we get to improve those same requirements for inter-RIR transfers. 

So we have four policies on the docket for today, and we'll have some great discussions about them.

Tonight's social at Club Auto Sport.  So tonight we have buses that leave starting at 6:45, every 15 minutes, and return buses coming at 8:30.  Wear your social or regular name badge to get in, and we should have a great social tonight.

So at the head table I see my Chair, Paul Andersen.  I see Vice Chair, Bill Woodcock.  Dan Alexander, Chair of the Advisory Council.  Tina Morris, our Vice Chair.  And I see at the end -- is that Chris?  Looks like Chris Tacit, our Jabber scribe who doesn't have the Jabber terminal right now, but we're getting him one shortly. 

So I want to invite up our sponsor -- come on up, Rob -- and give a quick update.  Zayo is our sponsor, and Rob is happy to be here to talk about it.  If we can get his slides loaded up. 

Remarks from Network Sponsor

Rob Hagens:  Good morning, everyone.  I work at Zayo, and I'm responsible for the architecture and planning of Zayo's IP backbone.  That's AS 6461 as well as our optical network, long haul, and intercity. 

So when I started talking to Betty about providing the bandwidth for this last NANOG and for the ARIN conference, one of my first thoughts was:  How much bandwidth should I provide? 

Zayo is like many carriers out there selling gobs and gobs of 100-gigabit circuits.  I thought, well, maybe 100-gigabit circuit.  Then I thought, let's just see how much bandwidth we really need.

I looked at the MRTG graph at the last NANOG and discovered something very interesting.  The folks at NANOG and the folks in this room work to build and scale the biggest, fastest, baddest IP networks on the planet.  But as individuals we really don't use that much bandwidth.

The graph on the right here is a graph of the Zayo circuit.  We provided a 10-megabit circuit, but the high bar there is actually 400 meg.  So we could have provided just a 1-gigabit circuit, 1 GigE, but that just seemed chintzy, so that's why we went with 10 gigabits. 

So, the message here for everyone is that there's a ton of bandwidth sitting out there waiting to be used, so when you're discussing policies that are maybe a little bit boring or not interesting, you know, get -- download some things, go ahead and get "Game of Thrones," catch up on some binge watching.  We're here for you.

I thought I'd also take just a couple minutes here to talk about the cost of optical transport.  We obviously have a large DWDM network, and it's growing.

This chart shows the actual cost compression for 100-gigabit circuit on Zayo's network. 

And I've been a little careful to cover the exact Y axis, but I'll tell you that there has been tens of thousands of dollars of cost compression for 100-gig circuit.  And that's a really, really good thing.  And so I wanted to talk a little bit about how is that happening and where is it going in the future. 

So the thing that's driving this cost compression is different kinds of modulation.  And the modulation schemes have these kind of complicated sounding names like QPSK or 16 QAM.  Let me translate it into how much capacity per channel.

The current most common bandwidth that's out there today is QPSK, which is 100-gigabit channel.  8 QAM is 150-gigabit.  16 QAM is 200-gigabit channels.  The interesting thing about these higher-modulation schemes, so it's more bandwidth per channel, right?  200 gigabits per channel is twice as much.

But the result of that, due to physics of light and things like that, is that you don't send the signal as far.  You don't have the same reach. 

I'm sure most everyone knows that in an optical network one of the costs that you want to avoid is when you have to convert the signal from the optical domain into the electrical domain back into the optical domain.  That's known as a regeneration.  Regens are expensive and regens kill your economics. 

The interesting thing about these new modulation schemes is that they have different distances that they can travel before you need to regen. 

So if you look at this graph, the Y axis is terabits of capacity of the line system, and the X axis is distance going from 100 to 4,000 kilometers.  And that long line that extends almost the entire way across represents 100-gigabit channel. 

So as you can see, you can send 100-gigabit signal 4,000 kilometers without a regen, which is an amazing thing these days.

The higher-capacity modulation schemes have lower distances, smaller distances.  You could see one of them is about 1800 kilometers.  And then the most capacity goes the shortest distance without regen.  That would be 16 QAM that can go about 1600 kilometers. 

What does that mean for a service provider?  It gets more complicated to build your optical network if you're trying to have the lowest cost per bit.

So imagine a hypothetical system going from, say, Los Angeles to Phoenix to Dallas.  For traffic that's going from Los Angeles to Phoenix, we would want to use 16 QAM.  We'd want to use 200-gigabit channels, because that gets us the most capacity for the least cost.  That's the lowest cost per bit. 

But for traffic that's going from Los Angeles through Phoenix all the way to Dallas, we need to use a modulation scheme that's not as high in terms of capacity, but that gets us longer reach. 

So this all becomes quite complicated when you're trying to plan out a network.  And also when you don't know what your demand is, what's coming down the line, it means that you have to be pretty flexible with how you do your channel planning. 

So that's probably more information about optical networks than you wanted this early in the morning, but I just wanted to share with you what some of the things that service providers have to deal with.

That's the end of my remarks, so just want to say thank you for the few minutes and have a great conference. 

(Applause.)

John Curran:  Very good, very informative.  Okay, happy to have such large amount of connectivity to the conference.  For all of you who will be doing torrents and Bitcoin mining in your spare time, that's of course, in the breaks because we'll be working on policy while we're in the room. 

So the next report up is Dan Alexander giving the Advisory Council On-Docket Report. 

Advisory Council On-Docket Proposals Report

Dan Alexander:  Good morning, everyone.  We'll be talking about a few policies this week, the next two days.  The first one here is Recommended Draft, and that's going to be discussed on Friday.  And this is around improving v6 registration requirements.

We'll discuss it in detail, of course, on Friday.  But essentially what it's talking about is the current policy has SWIP requirements around any v6 block of a /64 or larger.

This adjusts that requirement slightly to a /47 or larger, or blocks that may be announced specifically to the Internet, and smaller blocks all the way up to a /64 upon request to a service provider. 

We have four draft policies that we'll be discussing today.  One of them is an annual Whois POC validation.  Currently the POCs are validated by ARIN staff on an anniversary date where they basically go out and they try and validate all the POCs out there.  This proposal suggests that is modified slightly as to when they're validated.

And it also deals with some procedures around when the POCs are not able to be validated.  In some cases, ARIN staff will actually disable the ARIN Online account until those contacts can be validated.

2017-4, which removes reciprocity requirements for inter-RIR transfers, suggests that under the current system ARIN allows inter-RIR transfers to other regions where they have reciprocal transfer policies in place. 

This proposal suggests that in certain cases for the smaller RIRs that that bidirectional agreement does not need to exist. 

For those who would want to take the other side of that conversation, the 2017-6 actually suggests that that should remain in place, and it should go even further because there are some who have concerns that even in the bidirectional regions there are cases where that region could then transfer it to another.  And there were concerns about people skirting the system. 

The last one, the 2017-8, amends the definition of community networks.  For a long time within the Policy Manual, there's been different categories that define exceptions whether there's ISPs and end users, community networks.  Community networks is just an attempt to better define who would qualify as a community network for making the resource request to ARIN. 

One thing to note about 2017-4 and 6 is both deal with these inter-RIR transfers.  One allows them to occur in a one-way fashion under certain circumstances, and the other disallows those.  But one thing to note is during the discussions, ARIN staff could implement one or the other but they can't implement both.  So the AC has to take that into consideration. 

Of course, the goal of the discussion is to get the feedback from this room.  So please, everybody, come up to the mic, provide your input for the AC to consider. 

The one Recommended Draft that's being discussed on Friday can actually move to Last Call after this meeting.  But all the other drafts will have to come back to another meeting as Recommended for the AC to move them forward. 

And if people would like, you can find an AC member and can always arrange policy breakout rooms.  If discussions are desired during the breaks or after the session closes, you can track down myself or any of the AC members if you would like to discuss these proposals.

And that's it. 

John Curran:  Any questions for Dan on the On-Docket Proposal Report? 

(No response.)

Thank you, Dan. 

(Applause.)

Okay, next up we'll have the Regional Policy Development Update, and that will be given by Sean Hopkins.  Come on up, Sean. 

Regional PDP Update

Sean Hopkins:  Good morning.  So who attended the PDP tutorial yesterday?  Nice.  All 500 of you.  This will be exactly one seventh of that time. 

We're going to start with APNIC.  Now, these proposals include two that are focused on v6 allocation policy.  They just require folks to let APNIC know what their hierarchy is, what their usage is when they're requesting v6. 

There's another one to prohibit transfers for five years out of their final /8.  All three of these reached consensus at the last meeting, which puts them into Last Call. 

Some stuff that didn't reach consensus.  That includes an importing of RIPE's no need policy, and that does include the caveat that if the space came from an RIR with needs space policies like ours, that the organization requesting would have to prove 50 percent usage over five years.

There's another one that focuses on temporary transfers.  And one that focuses on merging two pools together, the recovered pool and the 103 /8.  None of these reached consensus, so they were put back to the Mailing List for more discussion. 

This Mailing List is something that you can subscribe to.  Talk to any APNIC staff that are here or just visit their website if you want more information about that. 

AFRINIC.  Lots going on in AFRINIC.  This is one out of two.  So let's talk about here:  We've got one specified transfer policy procedure proposal that's actually gotten ratified.  It's just pending implementation at this point. 

Few things that didn't quite reach consensus yet:  Lame delegation reporting; aggregate v4 issuance; and a rewrite of the PDP, a rather extensive rewrite of the PDP, that are still on the table.

Also on the table, a proposal to have AFRINIC deny services to government entities that shut down or deny Internet services for their citizens; a resource usage audit proposal and rewrite of their soft-landing policies.

As far as LACNIC is concerned, they have a one-way transfer proposal that did not reach consensus after a number of meetings.  That has gone back to the list.

But what did reach consensus are the other three.  This includes modifying the resource recovery process.  It actually puts an intermediate step into that process which specifically removes reverse DNS delegations before the resources are actually recovered. 

There's also a proposal to shorten the Last Call period to 30 days.  That doesn't actually affect the Last Call that these three proposals are in, but it would take effect thereafter. 

There we go.  Also reaching a consensus, a proposal to let organizations come back to LACNIC if they have a new addressing plan that requires more space, and then an adjustment to the subsequent allocation policy for IPv6 that actually mirrors what I just presented for APNIC.  It was the same author, the same idea.  Show your hierarchy, your usage, what you're going to use the space for. 

RIPE NCC, we have a proposal defining v6 subassignments as a /64 or shorter.  That did reach consensus and is in a -- or actually it passed through an initial discussion.  It hasn't reached consensus just yet.  But it's in their sort of second phase of discussion. 

Still on the table in early discussion is their Abuse Contact validation procedure proposal, and then another for reducing the v4 allocation.  For everything I did not say go here, and for questions go there or there.

John Curran:  Any questions on the Regional PDP Report? 

(No response.)

Thank you, Sean. 

(Applause.)

Okay.  Next up we have the Internet Number Resource Status Report with John Sweeting. 

John Sweeting:  Okay.  Good morning, everyone.  Nice to see everybody here.  Good old San Jose.

I'll be giving the Experience Report.  Okay.  I think it's a little out of order, but I'll do this one first.  I was given two.  It's on the agenda with the Internet Number Resources first.

It's all good.  That's the next one.  I can just do this one.  Doesn't matter -- flexible, old, grumpy. 

(Laughter.)

Not really.  Very happy. 

John Curran:  Talking about you or your boss? 

(Laughter.)

Policy Implementation and Experience Report

John Sweeting:  Okay, so we're going to go with the Policy Experience Report, which was actually next on the agenda, but we'll do that first while they can find -- maybe the other one's missing.  Maybe I didn't submit it. 

(Laughter.)

No, I did.  Okay, Policy Experience Report.  The purpose of this report is to provide feedback on issues or on policies that are within the NRPM, the Number Resource Policy Manual, policies that might not be working as we expected or that there's been things changed.  So policies don't always stay current and have relevance. 

That's part of today, what I'm going to be covering.  A couple of them, they're just not relevant any longer.  So we want to point that out to the community and let you do whatever you need to do to fix that. 

Ultimately, like I said, it's up to the community to decide what we're going to do with them.  Proposed changes, removal, new policies or, actually, you can leave it as it is. 

So the policies we're going to review today are NRPM 4.2.3.5, which is the ARIN approval of reassignments and reallocations; 4.2.1.6, which is immediate need; and 4.2.2, initial allocation to ISPs, wait list; and 8.5.4, initial block transfer.  There's kind of a contradiction in those two that we wanted to point out. 

So 4.2.3.5 is the approval of reassignments and reallocations.  And right now, currently, all extra large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN, by the Registration Services Department. 

We do a lot of these.  We spend a lot of time because it's in policy.  So people are submitting them and asking us to approve them. 

However, it seems to be a little bit outdated, because the ISPs -- well, first of all, the sizes have changed and these sizes are no longer germane to the process. 

But the other thing is people aren't giving -- since we're not providing free space anymore, the fact that -- you would think the fact that somebody has to come back in to us for approval to give a whole lot of space doesn't really make a lot of sense because they're not going to give out a whole lot of space to people that aren't really needing it, was the thought. 

So we're really saying whatever you want to do with that, but it seems to be an unneeded process these days; that if an extra large ISP or 3X large or one of those categories is going to give out a /18 to one of their customers, that there really isn't a need for it to be approved by somebody at ARIN. 

It's just -- so with that information, it's up to you guys, the community, to think about that and feel if there's something that you want to do.  There is a lot of work associated with it.  We get a lot of them. 

And the small-to-large ISPs making customer reassignments to a /19 or larger must first seek ARIN approval.  Again, it's the fact that those aren't really categories anymore.  There's a whole lot of additional categories. 

So we try to apply the policy in -- the spirit of the policy as it's written, but it doesn't actually translate to the actual sizes that we have today. 

So with IPv4 depletion, there's no incentive to give customers more than they need.  Not all the current sized categories are covered.  And there's the ticket workload, there was over a thousand of these in 2016.  And this was the other thing, approximately 70 percent of those are self SWIPs. 

It's the big guy taking a block and assigning it to a division within their company somewhere.  So for them to have to come to us and put that -- open that ticket and go through the whole thing of us reviewing it, asking them questions and approving it just seems a bit too much. 

So the questions for the community:  Is this policy still required?  And, if so, what changes should be made to them? 

Go ahead. 

Okay.  Now, the next policy is 4.2.1.6, immediate need.  That reads:  If an ISP has an immediate need for address space and can provide justification to show that the address space will be utilized within 30 days of the request, ARIN may issue a block of address space not larger than a /16 nor smaller than ARIN's customary minimum allocation to that organization. 

These cases are exceptional, meaning there's not a whole lot of people coming for -- even when we had space to give out for immediate need.  So you see where I'm going here?  Okay.  So the items to review is ARIN has no available IPv4 to fill an immediate need request. 

NRPM 4.2.2 and 8.5.4 now auto qualifies requesters for an initial allocation, and the policy now allows organizations to request up to a 24-month supply. 

So the question:  Is this policy still required?  And, if so, to cover what circumstances? 

So the gist of the whole thing is if you have an immediate need for IPv4 addresses, then you put that request in, we don't have anything to fill an immediate need with.  You'd have to go on to the waiting list, at best, and you'd have to sit there and wait for some time to have it filled.  So, something to consider and think about. 

And finally 4.2.2, initial allocations to ISP.  This is the one that has a contradiction in it.  4.2.2 says all ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. 

When you go to 8.5.4, transfers, it says organizations without direct assignments or allocations from ARIN qualify for a transfer of an initial IPv4 block of ARIN's minimum transfer size, which is a /24.  So in one section it's a /21.  And in the other section it's a /24. 

What happens is people will come in and sort of -- to request under Section 4, they'll come in to request IPv4.  They'll get approved for a /21.  Then if they go to do a transfer to fill that /21, it's not really what they're approved for under the transfer section because they can only get a minimum transfer size of -- they can only get a /24. 

So there's a contradiction there that -- the items to consider, the default via the waiting list and only /24 via transfer, and that both policies allow the ISPs to request a 24-month supply with justification.  Is this a feature or is it a bug? 

It's up to you guys to decide.  Should the 8.5.4 default initial allocation size via transfer be a /21 for ISPs?  Should the 8.5.4 default initial assignment size via transfer remain the minimum transfer size for end users? 

Those are the few things that my department wanted to point out to everyone and ask for your help in providing us some clear, good policy to follow on at these three issues. 

Questions? 

John Curran:  Any questions for John? 

David Huberman:  Hi, good morning.  David Huberman, Oracle, ARIN Advisory Council. 

Let's go back to the first one, please, Mr. Sweeting. 

John Sweeting:  You want to go back to the slide? 

David Huberman:  Yes. 

So you said two things, and I want to make sure I understand them well, please.  You said that you get a lot of requests that you have to review for sub assignments of /19 and /18. 

And you said generally organizations don't make these unless the recipient needs them because, of course, these are IP addresses that are very scarce and very valuable.  And that resonates with me.

But you also said there's a lot of these.  And you put up a number of about 1400.  And you said if we ignore the 70 percent that are self SWIPed, that still leaves about 400 requests in 2016 when ISP made a sub assignment to somebody else that was pretty substantial. 

Can you, in very general terms, talk about what these are?  Are these just -- are these -- you're reviewing them.  Are you approving them? 

John Sweeting:  For the most part.

David Huberman:  For the most part.  And you're approving them after applying a needs test? 

John Sweeting:  Yes.

David Huberman:  And there are some that you're not approving.

John Sweeting:  I would imagine there's a few.  You know, we try to approve everything our customers want.  I'm not supposed to --

John Curran:  We need to go pull stats actually. 

John Sweeting:  We follow the policy.  We follow the policy.

John Curran:  We need to go pull stats if you want to break down --

David Huberman:  I guess my question for you -- I'm sorry I took so long to get there.  I guess my question for you is: The spirit of this was, hey, if you're making this really large assignment, ARIN probably needs to be taking a look at it to make sure you're meeting the needs-based policy framework we all live under.

Do you feel like -- you don't have to answer this right now, but I guess the question is:  Do you feel like with those 400 that you're reviewing that are not self SWIPs, are you still following -- is the spirit of the policy still germane here? 

John Sweeting:  Yeah, but some of this has changed; it's gone from three months to 24 months.  The whole needs basis has shifted and changed.  So -- and I think the other thing that we were looking at is the fact that with depletion upon us, like, can we not trust, have more trust in our ISPs to be given -- to be asserting the needs test themselves? 

David Huberman:  So allow me to put you on the spot real fast, and I'll sit down --

John Sweeting:  We're not asking you to do anything.  We're telling you this is what's going on --

David Huberman:  Just having a conversation.  To put you on the spot real fast, and then I'll sit down:  To the best of your knowledge, there's no malfeasance going on here, for the most part, right?  These are generally legitimate assignments approved or not approved based on circumstances, but there's no games being played here, right? 

John Sweeting:  Actually, now that I've had a few minutes to think about it, that was part of the conversation I had with my staff, was that they actually have approved all of them that have come in. 

David Huberman:  Okay.  Thank you. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  How would this affect transfers?  And where I'm going with this is, if you're not doing needs assessment, are you then rubber stamping when somebody says -- and they say I need space for the transfer market, I need to go out and get space and, look, I've used all these /18s that have been SWIPed over to my customers, but at this point we're not doing needs assessment on them because you're just -- if this policy were to change, as an example -- does that mean that we're just assuming that that space is approved and has been used, et cetera? 

I know it sounds a little complicated, and I don't know where this comes in, but if we're not -- if you're not checking on that space, maybe they could just put all /24s and then whatever the case may be.

What's the purpose of this?  That's what I don't understand today.

John Sweeting:  One thing to remember is one of the things is the size -- the sizes that are in the NRPM are -- there's no size categories.

Kevin Blumberg:  I understand.  What I'm saying is:  What is the purpose of this today?  I understood it in free pool, but I don't understand what the complexity is post-free pool with verifying this.  Is that data ever going to be used by ARIN in any other place? 

When there was a free pool, you wanted to know that the space was being used properly.  But post-free pool, why would you ever need to look at this data? 

John Sweeting:  I'll let John answer that.

John Curran:  The question is actually turned around.  To the community, post-free pool, do you want to have this data and what would you need it for? 

John Sweeting:  That's kind of what we're asking.

John Curran:  We're bringing this to you to say we're doing this.  We presume you've got a reason why we're still doing it.

Kevin Blumberg:  I understand.  What I'm asking, John, is post-free pool, is this data used by ARIN in any way other than you collecting it and stamping it?  But is it used by ARIN in anything else? 

John Sweeting:  I guess it would be used for approving transfers, somebody's need. 

John Curran:  Someone could use this as an example of their utilization.  So there are circumstances where it could be used, but it's not inevitably required.  And you're collecting it for everyone.

Kevin Blumberg:  Thank you. 

John Sweeting:  And with all the other -- and with some of the other conditions that have been relaxed, such as going through the 24-month, even everything, it's not that pertinent any longer. 

John Curran:  Far right microphone. 

Lee Howard:  Lee Howard, Retevia.  It seems to me that in this case, if I worked for a large ISP, you mentioned that 17 percent of these assignments are self SWIPs, I might be inclined to do large allocations to individual departments that were not necessarily efficient allocations, if I were trying to show justification for acquiring more addresses, especially while I thought prices were cheap, if I thought prices were cheap.  So I can see a reason why we should still keep doing this. 

John Sweeting:  To that, Lee, on the self SWIPs, and you're putting in for a large approval for recipient transfer, we're going to look at everything you have as a company. 

So even what you have SWIPed to yourself, you'll have to at that time show the justification.  So that's another reason why on the self SWIPs, like, should we approve them?  Then we have to go back and ask for all that again. 

Lee Howard:  I see, because you're going to look at it again.  You may use --

John Sweeting:  We're absolutely going to ask you for everything that's SWIPed to you.

Lee Howard:  You may use the information from the original approval, but you can ask for it again when you approve the transfer request.  Okay.  Thanks. 

John Curran:  Center front. 

Andrew Dul:  Andrew Dul, CrowdStrike, ARIN AC.  Two things here that came out of this in my head.  One is it's clear that the AC needs to go and revisit the Section 4 in the post-depletion world and do some cleanup and things like that. 

And the second point was with regard to your last point about the transfer size being smaller than the initial ISP size, my intent in writing the transfer policy change that we did last year was that if an ISP, a new ISP, came in and could qualify for a /21 under Section 4, then they should be permitted to transfer a /21. 

That was the intent of the policy.  If that's not clear, then we can make some clarity.  But that's how I intended it to be used. 

John Sweeting:  And the only -- well, not the only, but the one problem with that is that we actually have been told transfers have to be -- everything for transfers is under Section 8.  So we can't go to Section 4 to say, oh, you qualify for a 21 under Section 4, so we can approve a /21 under a Section 8 transfer.

Andrew Dul:  So, presumably, if an organization could qualify for a /21 under Section 4, then they could use the same justification that they did to also qualify for a /21 under the Section 8 transfer stuff.  If the language isn't there to support that, then I guess we need to add some more language.

John Sweeting:  An ISP automatically qualifies for a /21 under Section 4. 

Andrew Dul:  Correct.

John Sweeting:  They don't under --

Andrew Dul:  They don't automatically qualify for a /21 under Section 4 or Section 8, but they could use their justification to qualify.

John Curran:  Right. 

John Sweeting:  And we actually -- we're following that.  We're saying the intent is that they can do that.  But that's not what the policy -- we're just pointing out that's not what the policy says. 

Andrew Dul:  I understand.  There's some clarity needed there, but that's okay.  We didn't think of everything the first time.

John Curran:  Final question from the middle mic. 

Jason Schiller:  Jason Schiller, Google.  ASO AC.  In my previous life I worked for an ISP, and one of the big concerns about 8.5 -- I'm sorry, not 8.5.4 -- 4.2.1.6 -- no, that's immediate need.  4.2.3.5.  The reason why ISPs were seeking approval from ARIN was because an ISP, when they give this space to their customer, from the ISP's perspective it's considered fully utilized.  They can't give a piece of that space to another customer.

And then when they run out of blocks to give other future customers, they want to be able to go back and get more.  And they didn't want to be in a situation where ARIN would come back and say, hey, you gave a huge chunk of your address space to this customer and it turns out they don't really need it.

So you need to go claw that back and get the utilization higher in that block before you can come back and get more space. 

So, this was sort of a safety valve to prevent that scenario from happening.  One could argue that maybe it may or may not be relevant to SWIPing space to yourself.  Some may argue that it's relatively easy to renumber if you're holding the address space and using it.  Some would argue maybe that's not so easy. 

But certainly it was in the case where the customer is another entity that you don't have control over, where it would be difficult to get that space back in order to bring the utilization up.

So that's historically why it was there.  We're still looking at utilization for transfer approvals.  You have to -- your total address space has to be 50 percent utilized or better in order to get a transfer going forward.  So I think it's probably still important. 

The question I have:  Is there a drop-off somewhere in terms of size?  If we push the boundary up, say, one bit or two bits, does that change the number of requests drastically? 

So when you go and pull stats and look at that, the other thing I'd like to see is a breakdown by size.  How many of these do you process? 

John Curran:  You're asking for a histogram of the distribution? 

Jason Schiller:  Yes. 

John Curran:  Acknowledged.  Thank you very much. 

John, thank you for giving us a view into policy.  And we'll now -- I think we have the Number Status Report next.

Internet Number Resource Status Report

John Sweeting:  I think so.  There we go.  So we have the Internet Number Resource Status Report as of 30 June. Third quarter just ended Saturday, so we don't have the third quarter stats yet. 

Okay.  Leslie gave this briefing, this presentation back in New Orleans.  And why is it going so --

(Laughter.)

Step away from the podium. 

(Laughter.)

And she mentioned the fact that the Registration Services Coordination Group was working on a new slide presentation with new statistics.  We're still working on that.  So even though we hope that the last time you saw it in New Orleans was the last time, but it was not.  This could be the last time because I understand we're trying to have it ready so that RIPE can do the initial test run at their next meeting in Dubai, I think, the week after next. 

So this could be the last time you see this particular presentation.  And you might -- you should get to see the new one in April.  So I don't know where we are. 

John Curran:  Stand by, we're working on a little haunted presentation problem. 

John Sweeting:  I can sing.  Can't dance. 

John Curran:  You mean you're able to sing. 

(Laughter.)

You should have it, John. 

John Sweeting:  Can you get me back to the start?  I want to be at the first slide so I can start. 

Thank you.  All right.  Here we go. 

(Applause.)

Hold the applause.  We'll be here all week.  Internet Number Resource Status Report as of -- as I said, it's only up to the second quarter because the third quarter just ended and we haven't gotten it compiled yet because somebody was away from the office attending meetings.

Maybe I'll just try to talk fast and keep up.  This is the IPv4 space with the status of the 256 /8s.  We still have those unavailable /35s that are reserved at IANA.  We still have the -- still have 91 that were given out by the Central Registries -- that would be IANA, SRI-NIC, DoD NIC and InterNIC -- leading up to ARIN and the other RIRs.  I stole that information from Leslie's last presentation. 

And then we have the 130 that have been given out to the RIRs since the RIR system has come into place.  And as you can see there in the breakout, APNIC has 45; ARIN, 36; AFRINIC, 5; LACNIC, 9; and RIPE NCC, 35.  So it's an eye test. 

Okay.  So currently the available -- as of the end of second quarter, the available IPv4 /8s in each RIR, not a whole lot of change from the last time.  AFRINIC has .83; APNIC, .37; ARIN is still zero; LACNIC is .26; and RIPE NCC is .75.  And those are all mostly due to last /8 austerity policies that they have in each of the regions.

I will note we did get -- I think it was a /22 -- no, a /21 worth of IPv4 September 1st from IANA.  All five of the RIRs got that /21 worth.  In ARIN's case we immediately turned around and handed it out to the wait list, whoever is next on the wait list. 

March, there will be a -- I don't want to steal IANA's thunder, but March there will be a /22 and then I think September a /23, and that will be it, I think, for that space. 

So IPv4 address space issued.  RIRs to customers in /8s, as you can see, hasn't really changed much since the last meeting or the meeting before that.  I'm not going to read through all those.  You can see them.  It's not that interesting. 

Okay.  ASN assignments, RIRs to customers.  This graph just really shows that ASNs have been pretty -- we've been dolling them out pretty steady over the years.  And it's pretty much there's been some shift in how many have gone out of each RIR, but for the most part it's pretty steady. 

There's no big surprises here.  4-byte ASN assignments, the thing here is just to show that it's growing.  It's mostly 4-byte ASNs.  I don't believe there's -- this is one of the slides we probably won't report on anymore, because an ASN today is an ASN. 

We have very, very few people that end up getting a 4-byte that come back and ask for a 2-byte.  So this slide is, it's good, I guess, for the purpose that it served when there were issues with a lot of -- if they got issued a 4-byte, they were going to have to come back and say I can't really use this; my upstream provider says they can't peer with me.  They can't set up a BGP session with me unless I have a 2-byte.  So we exchange for a 2-byte.

But for the most part that's pretty much done.  I think maybe we've had two this year that have said they needed to exchange it. 

I think we skipped over a slide.  Maybe it wasn't an important slide.  Can you get me -- are you doing it or am I doing it? 

So I'm going to let you do it.  I'm going to put it down. 

4-byte ASN assignments.  Okay.  I guess this was very important before, but it's something we're changing this to just we'll be ASNs forward. 

And then what's still pertinent today, and it's going to be pertinent for quite a while, is the IPv6 address space.  How much has been allocated to the RIRs?  Each RIR is still working off their initial /12. 

As you can see, there was a /3 reserved for global unicast, and then each one of the RIRs had their /12s.  We can go back and ask for more when we're past 50 percent utilization.

Some -- I think maybe ARIN with its reserved and RIPE maybe is over 50 percent.  But neither one of us have chosen to go back yet.  Maybe it's a stare-down:  Who is going to be the first one to go back and ask for some?  Maybe it's not.  Don't know.

All right.  Let's go to the next slide.  IPv6 allocations, RIRs to LIRs and ISPs. 

There's nothing really surprising there.  Shows that RIPE's been the leader in giving out IPv6 allocations with the usual culprits right behind them -- APNIC, ARIN, LACNIC and AFRINIC. 

Okay.  And this is just a pie chart of that graph.  This is the totals from January '99 to June to present.  And again no surprises there. 

Next.  IPv6 assignments to RIRs, from RIRs to the end users.  It's a little bit different there -- APNIC, as you notice, in 2015, 2016, APNIC either through policy or some other method started giving out a lot of IPv6 assignments to their end users and jumped right up there to lead the pack.  Maybe it's their IPv4.  They ran out of IPv4 first, I don't know. 

So next slide.  And there's your cumulative from 2002 to 2017.  RIPE and ARIN still have assigned out the most to end users.  But APNIC is quickly catching up, and AFRINIC and LACNIC are doing their thing and handing out their assignments to their end users. 

Next.  So percentage of members with both IPv4 and IPv6 in each RIR.  You see LACNIC has a very high percentage of their members that have both IPv4 and IPv6.  RIPE is almost three-quarters. 

ARIN, we went past the 50 percent a few meetings ago.  And we climb about 2 percent a year, is what we've been doing over the past couple of years. 

And APNIC's right there.  We're over 50 percent.  We'd like to really see that grow.  Maybe we need some kind of policy that would help that.  I don't know.  And then AFRINIC is at 35.  Next. 

That was the last slide with statistics.  These are the links to where those statistics are kept.  And next.  Thank you. 

John Curran:  Any questions for John on the Number Status Report?  Far microphone, go ahead, Louie. 

Louie Lee:  Louie Lee, Google Fiber and NRO Number Council.  This is Louie's hat.

If you would just flip back to slide number two, the first slide after the title slide.  So you have some addresses listed as being from the Central Registry, 91 /8s.  As some of these addresses get transferred and come under RSA, does it actually change your numbers here, or are you just reflecting initial status on things? 

John Sweeting:  This is initial status.  It's not going to change.  We're not going to try to track and say, oh, well, one of those 91 /8s is now in the RIR system.  We're not -- this is historical and won't change unless those reserve -- those not available 35 all of a sudden become available.  That's probably the only thing that could change, and I don't see that happening. 

John Curran:  Okay.  Over here. 

Owen DeLong:  Owen DeLong.  Akamai.  If you could go to the comparison of IPv6 allocations by registries, is that the number of blocks allocated, or is that the number of /48s allocated or --

John Sweeting:  Blocks.

Owen DeLong:  Okay.  It would be interesting to see how the relative size of those -- as in the relative number of /64s allocated by the different registries rather than just the number of assignments. 

John Sweeting:  It's interesting you say that because I believe that's one of the new slides that will be in the new deck.  We actually were doing that. 

Owen DeLong:  Okay.  Excellent.  Very good.  And I think that covers it.  Thanks. 

John Curran:  Okay.  Far right mic. 

Rob Seastrom:  Rob Seastrom, Neustar, ARIN AC.  I think it's one or two more slides further down.  I'd like to see the people who have both IPv4 and v6 -- there we go; that's the slide I'm looking for -- so, I would be interested in another statistic related to this as a point of information, and I apologize for handing you what's going to be an enormous pain for data reduction. 

I think that the overwhelming majority of IPv4 addresses that get issued end up in DFC.  And I would be interested in what percentage of the v6 that's been issued actually is ending up routed. 

John Sweeting:  Turn around and ask that guy behind you. 

(Laughter.)

Sorry, Geoff. 

Rob Seastrom:  Am I going to be happy or sad? 

Patrick Gilmore:  Patrick Gilmore, Markley Group, ARIN Board.  This is the slide I wanted, so yay.  Of the 55.48 percent that's ARIN, I'm wondering does that include legacy holders?  Because my guess is they're not asking for v6, and then we can't match them up, or if they do ask for v6, it will look like it's a separate organization.  And relatedly do we have anybody who has only v6?

John Sweeting:  Yes, we do, and that will be in my departmental report tomorrow.  It's not one of the stats we collect for the combined RSCG and NRO stats, but it was requested by one of our ARIN members, and we now report that in our -- in my report tomorrow I'll have that.

Patrick Gilmore:  If you take the legacy holders out, what does that 55 percent become?  Because none of the legacy holders are going to ask for v6 under -- unless they've signed an LRSA, right? 

John Sweeting:  I can actually get back to you, Patrick, with that answer.  I have somebody in my department that can do that.  He's very good at doing that kind of stuff.  But we don't collect that.  All the RIRs don't collect that.  So it wouldn't show up in this report.

Patrick Gilmore:  Seems like it would make --

John Sweeting:  I can get that for you before this meeting is over. 

John Curran:  Far right mic, yes. 

Geoff Huston:  Geoff Huston, APNIC.  This is a suggestion to you and your NRO colleagues when you prepare future versions of this report.  There's an implicit assumption when you talk about the free pools that either addresses were in the free pool or they were allocated.  And as you're probably aware, there is this third category, which is called reserved. 

And there are resources of both IPv6, v4 and AS numbers that are held by the RIRs for various reasons in this reserved category. 

It would be informative of the total picture in the context of this report to at some point also list those quantities that are being held in this manner, not for any other reason in this context other than to show the complete picture.  Because you know there is a significant area. 

So it's not you, John, it's you and your colleagues, and it's not this report --

John Sweeting:  And we totally agree with you, Geoff.  And we've had the discussion.  As a matter of fact, we've had very deep discussions on that.  There's -- we're actually trying to do that in the new presentation that we're going to start showing. 

But there was, as you can imagine -- every RIR calls this category something different from this category.  And if you try to put it all under that category, then it means different things to different communities.  We're trying to iron all that out. 

Geoff Huston:  I appreciate that, but actually when we jointly publish, we call the lot reserved. 

John Sweeting:  Yeah.

John Curran:  Okay, and last question, go ahead. 

Dmitry Burkov:  Good morning.  Dmitry Burkov, RIPE NCC, maybe I repeat one question, but with a different analysis.  I like this picture.  What I missed on this picture is the Central Registry holders.  Do you have any assumptions -- how many IPv6 percentage among Central Registry address space holders? 

John Curran:  Repeat the question part one more time. 

Dmitry Burkov:  What's missed here, we have five RIRs.  But also remember about Central Registry.  If you will join this picture, the question, how many IPv6 are allocated by holders from the Central Registry, legacy.

John Curran:  I see.  All right. 

Dmitry Burkov:  Do you have any assumptions because only you as ARIN still have more information for such analysis.  A significant part you remembered, it's a lot of -- it's huge, how we can estimate the IPv6 deployment.

John Curran:  Understood.  Yeah, this is not very good at showing the level of deployment.  We've got to think about that one.  I'll get with John on it.  Thank you, Dmitry. 

Okay.  That ends our Number Resource Report.  Thank you, John.

(Applause.)

John Sweeting:  Thank you.  Glad I could provide some humor this morning.  Thank you.

John Curran:  We like our schedule to stay on schedule.  We'll move directly into the IETF Report and have our IETF reporter, Cathy Aronson, come on up. 

IETF Report

Cathy Aronson:  Okay.  So those who noticed my awesome shirt at breakfast, I ran into a friend of mine at the IETF.  Pretty exciting, huh? 

(Applause.)

It has three options -- off, on, and auto.  I'm not entirely sure what auto means, but it's a little scary.

I hadn't seen her in a really long time and I lost track of her, but she was hiding in plain sight working with David Huberman.  But who knew?  It was super fun.

I want to take a little poll:  Who was in the path of totality for the eclipse?  Wasn't it the coolest thing ever?  I didn't leave my neighborhood, so that was pretty awesome.  Oh, there's slides there.  Oh, okay, cool.  Anyway, so much for that.  Okay.  That didn't work.  Where am I -- next slide, please. 

(Laughter.)

We do that at the IETF.  It's very high tech.  So about this presentation.  It's actually official even though for six years it wasn't official, and, I don't know, maybe I'll just delete the slide for next time. 

But I like really weird quotes.  I take pictures of people when they don't see me doing it.  And anybody who was there who has any input is welcome to pipe up and say what I've gotten wrong or that you don't like my awesome shirt.

Anyway, let's see.  Next slide, please.  I don't know what that was about, can we go back?  Because this worked.

So, these are some highlights.  I finally got to put a picture of the fountain at the Kafka Museum in my presentation because the social event was there.  You can peruse that later. 

Highlights.  I wasn't at the QUIC meeting but I had some conversations during the meeting about it.  And I went back and watched the video of it.  But things are really changing, you guys.

So QUIC is a UDP.  It's the new transport for the Internet over UDP.  And the BoF for this the first time was last summer, July of 2016, and there are five interoperable implementations now that were at the hack-a-thon in July this year.  So the Internet as we know it is really changing.

Pretty soon we won't be using TCP -- Ruediger is stabbing himself back there.

(Laughter.) 

For better or for worse, we may notice, we may not notice, but this is a huge change, and it's happening.  I mean, five interoperable implementations in a year is pretty amazing.

Nothing happens that fast in the IETF anyway.  So something to keep an eye on would be that. 

I had some other things that I'm going to talk about as the presentation goes along that are intertwined in the rest of my presentation that are also highlights.  But that's really something to pay attention to. 

It works now.  So John and the Board let me go to the advanced networking workshop.  I've always been fascinated by the winners of the whole contest.

I went and listened to a bunch of the presentations on Saturday, because you might as well stay an extra Saturday inside in Prague instead of outside.  And they were really interesting. 

A lot of research gets done because of the RIPE Atlas probes.  I have one of two in Wyoming.  If you're interested in traffic in Wyoming, it's at my house. 

But there's a lot of really interesting work that was presented that people are taking the data, and this whole vantage point selection thing is how do you pick which RIPE probes to use to get the most information for what research you're trying to do?  So it's research about how to do research with RIPE Atlas, which was a pretty interesting talk.

I can hardly read these.  There isn't a thing up here -- no.  Okay.  Awesome.  Let's see.  So these are some more of the presentations that happened at the Advanced Networking Research Forum, the ones of note.  There's a lot of implementation going on with segment routing in v6.

There's a lot of testing going on for varying forms of Happy Eyeballs, like how well is your v6 working, that sort of thing. 

Let's see.  And then our own Leslie Daigle did a house metrics panel with some ISPs that was pretty interesting.  I liked the opportunities for optimization quote, like, well, maybe we have v6 and v4 both running, but the v6 thing is, like, on the other side of the earth and maybe if it was closer it would be better. 

So as time goes on, these ISPs have looked at, you know, like how do we make it so that they're more -- the connectivity is similar and therefore it's better with v6, but not having it be worse.  It's all videoed, if you want to check it out.  It was actually a pretty good panel.

Let's see.  And then these are some other papers I won't go into because I'm sure you all want your coffee break.  But if you're interested, they're all online as well. 

So IEPG, like I always say, it's the operator forum that happens the day before the IETFs that no one at the IETF seems to know is happening.  But it's been happening for like 20 years.  And it's usually pretty -- it's my favorite part of the IETF.  So I always go Sunday from 10:00 to noon. 

So, let's see.  Exploring the network data for fun and profit, which was -- George is always -- is he here?  You can ask him -- he's over there -- about his presentation.  Who's -- what -- the https deployed fairly ubiquitously who's left behind, and he has some stats about the predictors of who can't do secure http.  So you should check that out. 

Automatic DNSSEC.  And there's some implementations -- is that like a voice or something?  Anyway, some implementations of Automatic DNSSEC and the domains that are signed and not signed.  There's some stats here for that.  So it's happening. 

Unidentified Speaker:  How do you know something has been assigned if there is no published DS record?

Cathy Aronson:  Let me see if I can go back.  Not entirely sure. 

John Curran:  I think it's read the RFC time.

Cathy Aronson:  Yeah, I'm sorry.  It's a high-level presentation.  No, that's okay.  Sometimes I know.  Sometimes --

Owen DeLong:  My guess would be that it finds the relevant resource records in the zone even though it can't validate them against the upstream DS.

Cathy Aronson:  And then there was a talk about BGP, more specifics, the three kinds, the hole punching for traffic, engineering or just hole punching more specific overlays.  And 53 percent of BGP more specifics are -- I'm sorry, I just had like a huge loss of my thought process there -- are more specific.  So a lot of the routing table in BGP is still more specifics. 

Let's see.  And 1 percent of the prefixes generate 40 percent of the updates, which isn't a huge surprise.  That's been that way for a long time.  And v6 has a lot more instability still on the routing table, even though the routing table for v6 is smaller.

And these are some other projects that are going on that were presented in the IEPG. 

Let's see.  And then this is about DNS recursives and how to analyze their behavior and look at what could be fixed.  And it looks like in a lot of cases using anycast more ubiquitously really helps the recursives behave.  And there's some slides that you can get to with that URL. 

So IRTF.  So this was singularly, I think, the most interesting part of IETF this time, were these two presentations at the IRTF.  So there were two winners of the Advanced Networking Research prize.  And, seriously, if you get a chance read these papers, they're amazing. 

The first one is all about carrier grade NAT deployment.  And they used, again, BitTorrent.  You look at your BitTorrent neighbor and then you can extrapolate where all these carrier-grade NATs are, it's really pretty fascinating.  They looked at how much carrier-grade NAT is going on, and it's really pretty significant. 

They also found that a lot of what I presented a few reports back where people are snarfing up address space that isn't routed and using it as RFC 1918 space.  They saw a bunch of that in these carrier-grade NATs.  Anyway, it was really well presented and really, really interesting.

And the second paper, which I just can't even -- I can't believe it.  There was this big security flaw in a Juniper software.  Actually there were two of them.  And this guy did this whole analysis of what happened, what went wrong, the whole calamity of errors that made these security things happen.

And it was just really interesting.  Like halfway through the presentation the guy in the back of the room just went "oooh," out loud.  Like I don't think he realized.  Like all of a sudden you're just like, no, that didn't happen. 

And like the new version of Ike, the NANS is bigger, and that made it easier to do the hack.  It's really worth reading and watching the presentation if you get a chance, especially if you're into security, because it's just, you know, like that loop didn't get implemented.  So this check never happened and it was just a whole calamity of errors.  Anyway, I was really geeking out over that one. 

So v6man, not nearly as exciting.  But super exciting that IPv6 is now an Internet standard.  Isn't that exciting? 

(Applause.)

Yay.  Who knew?  Who knew it would some day happen that we've been doing this for how long and now it's official? 

Let's see.  Let's see what else.  They're talking about Addressing Architecture, which affects this community, I guess.  They say a prefix length should be a certain prefixes length, and we say a prefix length should be a certain prefix length, then I'm not sure why it can't be a net and a mask, but we're still having discussions about it.

Let's see.  There's Node Requirements still happening.  And there's other drafts being worked on in 6man, if you're interested. 

Homenet, again, hasn't changed much, the host node configuration protocol.  Ted, one of the guys, implemented it in his house, and he said it was really, really super hard and that somebody in their home probably wouldn't be able to do that very easily.  And then everybody got upset with him because 19-year-olds can deploy that stuff. 

So, anyway, I think it really needs to be easier for stuff to work in the home, not harder.  And if an IETF guy can't make it work, then I suppose my brother can't.  I don't know.  But more will be revealed, I guess. 

Let's see.  So they're still working on Babel, whatever, the routing protocol they created for Homenet, which I still don't understand why we need another routing protocol for Homenet.  But they're still working on it. 

And, you know, different churns of the spec.  And these are some of the other drafts that I won't talk about. 

SIDR Operations is the security for the routing.  And so there's easy ROA validater now that you can use that tells you if your ROA is valid or not, which is pretty cool.  And I like that quote, "Because blockchain is all hip and cool." 

If you want to check on your ROAs and see if they're valid, there's ROAalert.org.  So you can check it out. 

Some other drafts that are going on in there, there's a tree validater that is being worked on.  Let's see what else.  There's a BGPsec reference implementation being updated.  There's other stuff going on there.

V6 operations.  Okay.  So this is where I ran into my friend, Justine, and she gave me this awesome shirt.  So this is what's going on at turning off v4 at Microsoft.  The guy who gave the presentation, he talked quite a bit about the reasons why they're doing v6 only.  They ran out of RFC 1918.  They need to interoperate with other parts of the company.  The NAT solutions aren't good enough for them.  And dual stack is really a lot of work for them. 

So they're doing a lot of v6-only work.  And so he has a blog that he wrote about as well, and the link is there. 

And here's some stats about v6 deployment status.  So there are 9 million -- I still can't read my slides from here.  Anyway, check those out.  There's 37 countries exceeding 5 percent traffic, which is pretty cool.  Akamai says there's seven countries whose v6 traffic exceeds 15 percent.  So we're moving along with the deployment.

And now that it's an Internet standard, who knew?  Maybe it will even go faster, right?  Could happen. 

Let's see.  So there's a bunch of work again being done with Happy Eyeballs.  This guy, he's suggesting that happens.  Say you send your request and you get your AAAA record back before you get your A record.  If you're dual stick, why don't you just do v6 and not wait for v4.  So they're trying to optimize some of these things so that, well, if v6 is faster, why don't you just use it?  So that's being worked on.  Let's see. 

Oh, and then there's a huge discussion about the IETF, as we say, eating its own dog food.  So maybe we should have a v6-only network at the IETF.  But then people complain that they want to get real work done so they really don't want that.

So there's a big argument about that going on right now -- like, when does the IETF start using v6 itself?  I mean, there is a 6to4 network and a v4 network and a v6 network, but when is it going to be v6 with maybe a little v4 on the side?  It's not quite happening yet. 

So, oh, and the other thing is that, you know, say you go to electronics store A and you buy a box.  And you bring it home, and you plug it in, and v4 works.  Right.  It just works.  But you buy one that does v6, and you still have to jump through a whole bunch of hoops. 

So there's some work being discussed about how to make that happen where you just get a v6 box and you bring it home and you plug it in and it just works.  And obviously Ted, when he did the Homenet thing, that didn't work so well.  So hopefully we can make it simpler to be able to do v6 just out of the box. 

Let's see.  They're still talking about unique local addresses and whether we should use them or not.  More Happy Eyeballs stuff.  There's some other drafts going on in v6.  I could spend -- v6 ops -- I could spend forever going over them. 

I went to the Ops Area meeting, which is sort of an overarching whatever, doesn't fit in an individual ops group.  It goes to Ops Area and then maybe it stays there or maybe it moves to whichever group it ends up being put in. 

And so some of this they talked about versioning and structure of specifications.  And I just don't think that using a YANG model to structure IETF drafts is going to be super exciting. 

But I don't know.  So there's a big discussion about the specifications themselves and what format, even though there is a new format, which I think I have a slide about, what other work is being discussed is right here -- service models, exporting BGP community information, more YANG models, feel like YANG models. 

So the ISA BoF is about the interaction between the IETF and Internet Society.  So there's some work being done.  How does the IETF fit into the Internet Society?  If you ask them, what do they call it, an activity of the Internet Society, but I think maybe the IETF might want it to be more than that or they might form, like, a separate staff.  So there's some work being done on that. 

So this is the other thing.  This is in my highlight slide.  I have a friend that I've been doing some work with at the IETF.  And I went to a meeting about TLS.  And TLS is Transport Layer Security.  It's never been kind of my thing.  I go there for IPv6. 

But this is actually something that's changing, along with QUIC and some other stuff that's happening.  And there's a huge group of data center people that are really worried about the new Transport Layer Security, because they're not going to be able to look in the packets and see what's wrong with their networks.

So they're trying to push to have this Diffie-Hellman that they can look at, they can open up the packets and see what's broken in the data center.  If you need data center stuff, this might be something you might want to follow, because if you can no longer debug problems, then that might be kind of hard to do your job.

So there's a group that has been meeting pretty regularly.  I went to their group on some ridiculous hour in the morning before the meeting.  And then I went to the working group.  And there's actually -- yeah, so TLS version 3 --  or 1.3 is the new version, and that's the one where it's going to be really hard to look into the packets.

And so the data centers want to use, like I said, a static Diffie-Hellman so that they can look into the packets and see what's broken in their networks.  So, anyway, it's something that might affect a lot of you, I don't really know.  But it seemed like there were a lot of big-company data center people that were there that were pretty up in arms.

So let's see.  So this is more about the static Diffie-Hellman and the requirements that people need. 

So dynamic host configuration is all the DHCPv6 stuff.  Here's some stats on DHCPv6 deployment.  99 percent of 44 million cable modems use DHCPv6 and are v6 only.  And the other thing that I think is really interesting is that these guys, the Comcast guys are really taking v6 as an opportunity to completely change how they build their network, how they run their network, how they think about running their network. 

And it's really kind of neat.  Because they're freed up.  You don't have to split nodes anymore and remove little bits of address space around.  You can just give it a bunch of address space and make it all work.  So they're really changing the paradigm of how you build your network out and what you use address space for. 

So, anyway, let's see.  There's work being done on secure DHCPv6 but not working super full speed ahead. 

So this is the Global Internet for Everyone working group.  I've been going to a couple of these.  And these are some community networks, guys -- community networks that are doing, building infrastructure in varying, different remote places, so maybe we can get some of them to come and join the community networks discussion.  Didn't even think of that until just now.

So, anyway, I went to the Technical Plenary.  And I just want to say that on September 14th, 2017, the first RFC was published with non-ASCII characters.  Nothing before its time. 

(Applause.)

No more ASCII art, which is super cool.  For those of you who don't know, you used to have to do network diagrams with dashes and strange characters.  So, Heather, the RFC editor, was instrumental in that.  And she has a lot of patience, an incredible amount of patience. 

And, again, I said there's a number of discussions about the IETF network being v6 by default. 

So I went to the Human Rights Considerations working group as well because I just find it fascinating because -- next slide, please -- and guess who gave a presentation?  Milton Mueller, which was good to see him.  I haven't seen him in a while.  He used to be on the Advisory Council for three years or six years or something.

So he talked about Internet architecture and human rights, which was a really great talk, if you get a chance to listen to it.  Is code law or is code the enabler of human rights?  Those sorts of questions. 

And the press and the radio where technology is a freedom until everybody figured out how to regulate them and that's sort of what's happening with the Internet.  Like, it was a free and open thing and once you figure out how you can clamp down on that stuff, you start clamping down on that stuff. 

So it was a really interesting discussion.  And I always thought I was there.  If you get a chance, check it out. 

Let's see.  Next slide.  So this is a couple of the ongoing drafts, politics of standards and architecture, how Internet architecture enables human rights. 

Next slide, please.  And they do a hack-a-thon before each IETF.  And this hack-a-thon looked at human rights and they tried to detect on the Internet where censorship was happening.  And of course that's kind of iffy because you don't really want to publish where you see censorship happening because maybe it'll get harder to find that.

But they actually had that in the hack-a-thon, like, looking at what parts of the Internet are being filtered and that sort of thing.  So that was kind of cool. 

Next slide.  DNS operations.  Next slide.  So these are some of the drafts.  How am I on time?  Okay.  I'm hurrying, hurrying. 

We'll skip through these, but these are some of the drafts that are going on in DNS operations. 

And we can -- I just put Babel in here because I went to the working group.  But you can go to the next slide.  These are some drafts being worked there.  Again, it's the routing protocol for Homenet.

Next slide.  So this is where you can look for more information on what's going on at the IETF, the different BoFs, the different working groups. 

And then next slide.  This is what you can do if you are going to your first IETF.  Or if you are, let me know and I'll be happy to make goofy noises with you, like laugh at people in the back of the room or whatever. 

Next slide.  And this is a shot of eclipse totality directly from my camera.  I don't know what that was about.  Anyway, questions? 

John Curran:  Middle mic, go ahead.  

David Huberman:  David Huberman, Oracle, ARIN AC.  Thank you for a wonderful presentation, as you always give.  It's one of the highlights of these meetings for me. 

I have two questions for you.  Here in 2017, and it's October now, there's been this effort called CASM, Central Address Space Management.  And from what I've seen it's -- the operators of a network in China who think IPAM, IP Address Management, software is interesting or difficult or something and they think they'd like to standardize some things.  I've always had a little bit of a problem with that because one solution does not fit all in IPAM. 

But I'm an IP address goonie.  I spent 18 years here in the ARIN IRR community.  I don't spend a lot of time in the IETF community because I'm not a protocol person. 

Do we need to worry about things like when some person just has an idea that works for them and they want to try to make a standard out of it?  Is this something that we need to pay attention to? 

Cathy Aronson:  I don't think that CASM met in Prague.  I went at least once, and it does seem like I can't imagine it's going to go very far, but I've been trying to keep an eye on it. 

I don't think we need to worry about it, really.  And I can't imagine that it's going to -- I personally can't imagine it's going to get very far.  But I'll definitely keep an eye on it. 

John Curran:  Remember that IETF protocols are standard ways of doing things that people use or don't use.  So if a real question is do we need to pay attention to it because they'll adopt the protocol that begets about v6 or doesn't know that there's two types of ASNs. 

In that regard, even if we don't end up using the protocol, it's certainly worth making sure there's people in the room, so they don't develop a broken one.  Lee, you have a follow-up.

Lee Howard:  Lee Howard, Retevia, Internet Architecture Board.  At the CASM BoF there wasn't -- the impression was that there was not a clear enough problem statement, but -- so it doesn't -- until there's a clear problem and approach forward, approach to go forward, nothing is going to happen.  But there might be further work on developing problem statements. 

I will also note that I believe there's staff from all five RIRs in the room at the time.  So I'm sure that our good friends at ARIN and the other RIRs will let us know if we need to pay attention. 

Cathy Aronson:  They didn't form a working group, did they? 

Lee Howard:  No, because there was not a clear enough statement.  There was interest, there was activity, but there wasn't enough to charter a working group.

Cathy Aronson:  Because I was at the BoF. 

John Curran:  Follow up on CASM.

Carlos Martinez-Cagnazzo:  As far as I understand, they didn't meet prior.  They meet the previous IETF.  There was a message sent to the Mailing List asking for an initial charter for a potential working group.

But the product of that, the sort of charter that came out of it, it didn't convince anyone.  It's just to show us just the way -- imprecise, to use the word. 

Cathy Aronson:  That's how the BoF was, too. 

Carlos Martinez-Cagnazzo:  I completely agree.  So I don't think anyone needs to worry about it.  I still feel that the problem itself is interesting.  And I would actually encourage people who are interested to contribute to this potential charter.  But as far as it is right now, I don't think it's going very far yet.

John Curran:  Any follow-up on CASM?  Anything else? 

David Huberman:  Pivoting for just a moment.  This is ARIN 40.  We've been meeting here for almost 20 years now.  And one of the themes that's always been present is that the IETF has had challenges with operator input. 

Never forget Randy Bush calling it the IVTF, the vendor task force.  Today, in 2017, are we doing better on that?  Are operators participating more in the IETF and we're getting more relevant input, in your opinion, in your view, into the workings?

John Curran:  In your view, Cathy.

Cathy Aronson:  I think it's about the same.  I mean, there are operators participating.  There's quite a few of them.  But whether -- I don't know.  I think it's about the same.

David Huberman:  Thank you. 

John Curran:  I'm closing the microphones because we're running out of time.  So I'm going to take the last few comments.  Go ahead, Kevin. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  You mentioned TLS, Cathy, and I've been watching it.  And there's been a big growth in TLS this year, a big push towards it, specifically 1.2 and now 1.3. 

But from our community's perspective, the big issue with TLS is that it needs IPs and it needs lots of them if it's done old school.  If it's done with SNI, which you don't need lots of IPs, but then you get a digital divide that goes on. 

When I look at the statistics for my customers, .01 percent of customers or .1 percent of customers are using devices that don't support SNI.  But as we go into other regions and other markets and to other countries, that number grows and grows and grows.

I'm just wondering if that's still being discussed, the digital divide that goes on when technology grows.  And in this case now we've run out of v4.  So it wasn't a problem before.  We could just add IPs and add IPs and add IPs, so that it was 100 percent compatible. 

But that way of dealing with it, of the 100 percent compatibility, seems to be going.  And just for everybody in the room, that means that customers aren't able to reach encrypted websites because we don't have v4.  V6 solves it, again, but they don't have v6.  If they had v6, they wouldn't have this problem with their devices either. 

Cathy Aronson:  I think that they're both issues.  I spend a lot of time with the people who are just desperately trying to make their data centers work, and that's one of the issues as well. 

There's just a lot of issues with it.  But they are discussing the other issues as well.

Kevin Blumberg:  Thank you.

John Curran:  And remote participant.

Chris Tacit:  Question from remote participant Kevin Otte of Flying Penguin Technologies.  He wants to know:  Why does the IETF not recommend ULA? 

John Curran:  Why did the IETF not recommend ULA? 

Cathy Aronson:  I think most of it is because there's so many addresses, why don't you just use a real address.  I mean, why not just use the global address?  Lee, do you have?

John Curran:  Lee, do you want to respond to the remote?

Lee Howard:  I want to respond to that question, this time as Lee Howard, co-chair of V6OPS.  There's a common -- the big argument, I think, is that some people, many people believe, some people believe that using ULA encourages the use of NAT because it's like private addressing.  So if you allow ULA people are going to do network prefix translation or other NAT technology.

Cathy Aronson:  And the IETF has historically been end-to-end, no NAT.

Lee Howard:  I don't think there's a formal recommendation against ULA, but there's also no recommendation ever to use ULA.

Cathy Aronson:  Right.

John Curran:  Final remark over here, far right mic.

David Lawrence:  David Lawrence, Akamai.  I just wanted to provide a different viewpoint on the role of operator feedback into the IETF.  The situation has actually been improving. 

It is, as witnessed the TLS conversation on static Diffie-Hellman, operational considerations factor pretty heavily into a lot of discussions about ongoing protocol development, including through the ossification of the middleware and whether the Inven (phonetic) principle can ever hope to work in the modern Internet and so on.  It's been an improving situation, I'd say.

Cathy Aronson:  That participation has been fostered by a few people in the IETF and actually brought the issues to their attention so that they would come and participate, and it's really been great.

David Lawrence:  I agree.

John Curran:  Okay, that's great to hear.  Thank you.  Okay.  I'd like to thank Cathy for her report. 

(Applause.)

I will just say this morning that the Board appointed Cathy to the same role for next year.  She's our 2018 IETF Reporter. 

(Applause.)

Okay, we're running late and there's a break outside.  So I'm either mean and I'm giving you a ten-minute break instead of a 30, or I'm just -- just a little mean and I give you a 20. 

So we'll be back here at 11:10.  We have a 20-minute break.  Please be back in promptly so we can start the policy session.  11:10. 

Hey, one more thing, folks.  So our meeting is here.  Our break is outside.  And our breakfast and lunch is downstairs.  That's the only part of this hotel we're using.  There's a fine organization on the other side, and we all love them, and they're having their own meeting.  But they have their own lunch and meeting room. 

So if you like Netflix, use their service.  It's a great service, but don't walk into their meeting because it's their meeting, not our meeting. 

Again, we're here.  We're in the lobby outside for the break and downstairs; we're not in the other half of the hotel. 

(Break from 10:51 AM to 11:12 AM)

ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation

John Curran:  We'll now resume with our policy session.  First policy of the morning is Draft Policy 2017-3: Update to NRPM 3.6:  Annual Whois POC validation.  Amy Potter is one of the shepherds.  I'll do the introduction.  And then I'll have them come up and do the AC presentation.  I mean Amy Potter and Alyssa Moore are the shepherds. 

Okay.  So problem statement.  No intro, got it.  They're going to come up and do this.  And who do I want up?  I want Amy.  Amy, come on up.  Wherever you might be.  I forgot, this is only a draft.  Come on up. 

Amy Potter:  I've been told to go very slowly on the first slide to give everyone a chance to come in.

So basically what we're dealing with here is that we have a problem with inaccurate and out-of-date information in ARIN's Whois database.  And that's presenting some real problems for those who are trying to address issues of abuse and illegal activity.

In order to address those issues, you first need to figure out who to reach out to.  But it's really problematic doing that and identifying the correct contact to reach out to if the point of contact that they're attached to, the resources that you're looking into, don't have meaningful information. 

You really need to have the correct contact, the right individual that is responsible for that space listed and accurate information about how to get in touch with that individual.

The problem is really being exacerbated by the activities of some upstream ISPs that are SWIPing reallocation to their customers and creating Point of Contacts for those reallocations that don't really have meaningful information in there.  Sometimes they're just putting in any contact that they have at their customer's organization, but that might not be the correct person to reach out to.  And the information that is contained in there might not really be that helpful to those who are seeking to address issues of abuse and illegal activity.

Law enforcement officials need to be able to identify the ISP closest to the end user and they need to be able to figure out who to reach out to at that organization in order to send legal requests. 

If this information isn't accurate, it slows down their investigation.  They end up having to send out multiple requests.  And it's also a problem for operators who end up wasting time and resources dealing with misdirected legal requests. 

A third note that everyone that holds resources should be concerned about is that if you don't have up-to-date records and they're listed in ARIN's database as being invalid or something out of date, that does make you a more attractive target for those that are out there looking to hijack space as well. 

So how does current policy try and address this issue? 

Right now we have a POC validation process where, once a year, emails are sent out to every POC in the database; and they are asked to validate that information. 

They have 60 days to respond.  And if they don't respond during that time period, then the POC is marked as nonresponsive. 

After that, after -- if ARIN staff determines that that POC has been completely and permanently abandoned, or it's otherwise illegitimate, it will be marked as invalid. 

So basically this approach helps out a little bit, because if you're in ARIN's database trying to figure out how who to contact, it at least lets you know that the contact information there might not be that great. 

This policy attempts to take that a step further and actually incentivize improving the data that's in there rather than simply marking off what isn't good information. 

The previous draft of the policy we're working with here attempted to improve the validation process in two different ways. 

First it sought to limit the scope of who are the participants in this annual validation process. 

So the previous process sends out the email validation request to every POC in the database.  This previous version of this draft and the current version both limit the scope of that to the tech admin NOC and abuse POCs and only apply to organizations that have a direct assignment, a direct allocation or a reallocation.  So it leaves out reassignments. 

The other way that the previous draft sought to improve the issue was by adding in some teeth to really incentivize organizations to validate their POCs. 

The teeth that were added to the previous draft were a little bit controversial for -- so first the initial email was sent out.  You get 60 days to reply. 

If you don't reply in 60 days, it gets marked as nonresponsive.  After that, there's an additional 90 days, and if you don't reply during that period, then ARIN staff would investigate the POC. 

And if they determined that it was permanently abandoned or invalid, then they would remove the reverse DNS entries for the associated organization and remove the resources for that organization from ARIN's database. 

We presented this option at the last ARIN meeting, and the community's response was not positive.  They felt it was a very extreme response that they weren't willing to move forward with. 

So our current draft seeks to scale that back a little bit.  We're looking at less extreme incentives and less extreme teeth here.  So instead of removing reverse DNS and removing the resources, instead, organizations that do not have validated POCs after the validation process, those organizations will be unable to access their ARIN Online account except to validate their point of contacts. 

So we'd really like some feedback from the community about how to best address this issue and how to start improving the information that we have in the Whois database. 

So we'd like to hear from you guys about whether or not you think that removing access to ARIN Online is really going to help improve the situation. 

If it will help, will it help in a meaningful way?  Will we just have people clicking through, yes, this information is valid, they're actually going through and checking that the appropriate contact for the resources is listed? 

We'd also like feedback about whether or not there are some better options out there.  Another alternative that we have discussed doing here is to try to incentivize the upstream ISPs to put in accurate and meaningful information in the first place for their customers when they're making these reallocations. 

So one idea about how to do that would be to require that all of the POCs that are attached to reallocations that are made also be validated before the upstream ISP itself is able to access its own organization's ARIN Online account. 

We understand that there are some organizations out there that have a very large number of reallocations, so it's possible to take a more phased approach to implementing a more extreme version of what we're proposing here. 

But we would really like some feedback from all of you about how to we solve this issue.  We've been talking about it a for a while, and we would like to hear from you about what you think would actually work for the community. 

Paul Andersen:  So at this point we invite those that would like to comment on this policy, either the specific text or just if this is even a problem that the AC should continue or the high-end principles. 

As a reminder for those new to the process, page 24 of your guide details the policy process in nice diagram form.  And this one is at stage three.  So it's not recommended at this point.  But the AC is looking for that early feedback. 

So with that I would urge people that would like to say they think this is a good idea, and you can say just that, a bad idea, or they have suggestions, to approach a microphone.  You have about 10 minutes of comments.  Please remember to identify your name and organization.  And we'll start with the far microphone. 

Christopher Regan:  Hi, Christopher Regan, Bronx District Attorney's Office in New York.  I really support the proposition of trying to get more people involved with getting the POC accurate.  I'm with law enforcement and so we use this constantly.  And we were talking in the law enforcement discussion panel yesterday about possibly law enforcement getting involved with helping keeping POCs up to date. 

And we're constantly looking for who we can contact, because we have to send out our subpoenas and legal compliance stuff to somebody and we'll get it out eventually. 

So making some sort of form that we can submit, Points of Contact that we use so that if the information is invalid on that site or on the Whois that we can then add new places for things to go to. 

I was just speaking to someone who explained that if the email that ARIN is sending it out to doesn't exist anymore because the person has left the company or whatever, that it means that they don't receive any sort of follow-up email.  It's just a bounce-back email that comes back as invalid. 

I think if there are suggestions, either from other companies or from law enforcement, saying that there is this other point of contact that we use that that may be a secondary place to look for for Points of Contact. 

Paul Andersen:  So, you're supportive of the policy; you would like to see ways to inject and also, though, to inject potentially bad data to be reviewed and validated, is that it? 

Chris Regan:  Yes.

Paul Andersen:  Thank you for bringing the feedback.  It's great to get lots of stakeholders here.  Middle microphone.

Ruediger Volk:  Ruediger Volk, Deutsche Telekom.  I don't have a real opinion of the specifics of the proposal.  I would like to make a comment on the motivation text.  It seems to me that the motivation text seems to promise things that currently are not really -- that are promising tasks that are not in the design and purpose of the Whois, and I think -- I think never will be.  To be very specific -- and there may be other parts in the motivation text that are lower key like that. 

Promising the District Attorney that he will be able to find in the Whois the directly connected service provider for an address is just not what can be done by Whois and it is not what should be done by Whois.

And doing that kind of promise to parties outside of the inner community here is not going to serve the purpose of this community helping other communities.

Paul Andersen:  Okay.  So if I understood that, it wasn't so much a concern with the text but you would like to see the problem statement refined to more accurately reflect the scope and purpose of Whois, which is an interesting point because I believe that's a question that's plagued the community for some time that we haven't, I don't believe -- did we ever, John, formalize on that?  Because there was many attempts to --

John Curran:  On the problem statement or the purpose of Whois? 

Paul Andersen:  Purpose and scope of Whois.

John Curran:  No, we do not have a formal statement or agreement among -- we have lots of usages for it and lots of good reasons for it.  I don't think we have -- I don't think we have a problem statement for what Whois is.

Paul Andersen:  I would encourage the speaker to approach the shepherds if they have specific text suggestions as well because that can be refined.  Next microphone. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  The funny thing for me is what we're trying to achieve -- the problem statement, I agree with Ruediger, is wrong -- we are trying to, from what I can gather from this, improve direct allocations and reallocations, so the direct ISP assignments, and that benefits everyone in the community and should be looked at as a benefit to everyone in the community.

So I'm actually very supportive of this because previous policies went way down rabbit holes in lots of areas.  But this is actually dealing with the direct who is using this space, or who is responsible for the space, not using it but responsible. 

So I would actually suggest cleaning up the problem statement to be just that.  This is for the benefit of everyone in the community, for many reasons, and it's good for everybody.

In regards to the ARIN Online question you have on there and a bunch of other things, I don't believe staff and legal has been done -- I don't see that in the thing.  But my concern is what can be done.  I don't like knocking down ARIN Online because right now it's used for billing as well.  And who knows what it will be used for next year? 

And there's a bunch of things, I don't know if it could be done.  If we're playing with something that's part of the RSA side of the world versus the NRPM side of the world and all of that. 

So one of my concerns with the policy is when I'm reading it, we're being asked to make choices, but I don't know if we're going to go down long discussions and find out that those choices were in fact not possible, because of contractual obligations or whatever else the case may be. 

So just a suggestion that having that looked at first before the community really goes into the specifics of the text itself and how it works would definitely be beneficial. 

Paul Andersen:  I know you're familiar with this, but since you've raised it as a first point today, just as a bit of how the policies flow, this is just a Draft Policy.  A staff impact and legal analysis has not been requested because that would typically be done as it enters that stage, which those questions would then be posted first to the Advisory Council and then if it came forward to the community.  So that would be answered. 

I understand you're kind of saying perhaps on this one -- but just so the people understand, that is a step that must be passed for this proposal to keep going.

I think John and Amy -- or Amy and John. 

John Curran:  It's a valid concern, Kevin.  At a high level, there are some 37,000 entities that have resources in the ARIN registry, and 20,000 of them are contracted parties under RSA or LRSA.  For parties that are under contract, there's no issue of enforcement of policy. 

For the legacy holders who are not under contract -- which is a diminishing pool because a lot of these resources come in and quickly end up being transferred and end up under contract -- but for the legacy resources, it is possible that any policy that's implemented, when we go to review what can be done for enforcement of policy, we might have to do a balance with the community. 

So you need to, to some extent -- as it says, when you get to recommended, we will go to staff and the legal assessment, that is a rigorous assessment, about implications of the implementation. 

But you have to presume that we can proceed and enforce any policy that the community wants.  I highly recommend the community take great care in considering policies to make sure that you like a policy as much inflected on you as much as you inflect on others.  So when you're writing policies, please consider that you might be the subject of them at some point. 

Paul Andersen:  Amy.

Amy Potter:  One thing that perhaps Leslie might want to speak to is the current text is really just looking to codify the most recent ARIN practices where you go to log into your ARIN Online account.  If you don't have a validated tech or admin POC, it prompts you, in order to do that, to log into your account.  That might be helpful for your -- 

Kevin Blumberg:  Absolutely.  To answer to John, I know that the AC, the Advisory Council, can, at its discretion, request a staff and legal anytime during a draft process.  It is done when they believe things are ready. 

I'm suggesting that, having gone through a Whois cleanup eight or nine or 10 times over the years, that throwing new concepts here that might be not possible, might be a good idea to start that a little earlier, even if it's lighter touch, in that area. 

Paul Andersen:  Just as a time management, so we can have some understanding, if you are planning on speaking, if you could try to approach the mic in the near future.  Or if you are a remote participating, start typing.  I'd appreciate it just so we have a handle on roughly how much more -- far microphone.

Iranga Kahangama:  Thank you.  My name is Iranga Kahangama.  I'm with the FBI, and we are in support of this policy.  I think, as some of the others have mentioned, Whois cleanup and Whois accuracy has been an issue for a large time.  And I think as us coming to this community and seeking to kind of be a consistent partner with this community, I think this is a really good first step. 

I think for the technical people you should realize that law enforcement does realize that this is a bit of an unwieldly beast for the Whois in the database.  And I think breaking it off into very small bite-sized pieces is a really good way to start and foster this relationship.  So for that reason, in addition to some of the positive aspects that would come of it, we're in support of it.

And we're very knowledgeable that you guys have the better technological insight.  So we're happy and I was willing to work with you to kind of alter language or specificity, knowing that we aren't here to negatively impact any of your business practices or anything like that in a burdensome way.  But we're in support of the policy.

Paul Andersen:  Thank you for the input in favor.  Far microphone.

Owen DeLong:  Owen DeLong, Akamai, ARIN AC.  I'm strongly opposed to the policy as it currently stands.  As the IP administrator for an organization that has a large number of reassignments that we are responsible for, the recipient of a large number of reassignments, often the only way we find out that a bad POC has been put on one of our reassignments is that annual POC validation process where we suddenly find out that some random person in Akamai who happened to fill out a contract somewhere once upon a time with an ISP is somehow on a POC that this ISP created. 

So I'm not opposed to what the policy is attempting to achieve.  I'm opposed to the removal of reassignments from the POC validation process. 

Second, the ARIN Online account thing is problematic in a number of ways, not the least of which is that it seems to assume some sort of one-to-one correlation between ARIN Online accounts and ORG IDs.  And no such one-to-one correlation exists.  And in fact it can be both one-to-many in that a single organization can have many ARIN Online accounts tied to it, and many-to-one in that a single ARIN Online account can have many organizations that it is tied to. 

And so when you talk about if an organization doesn't have any valid POCs, you're going to take away their ARIN Online account, it makes me wonder, does that mean if one of the organizations on my ARIN Online account somehow mismanages their POCs without me noticing, is that going to interrupt my ability to manage all the other organizations that are managed through my ARIN Online account as well?  And this would be very problematic in a number of ways.

Paul Andersen:  Let's pause there.  So the text says "Organizations lacking a valid POC will lose access to their ARIN Online account until a tech or admin POC has been validated."  Was the intent that it would be just the organization lose access or anything associated --

Owen DeLong:  The problem is organizations don't have ARIN Online accounts.

Paul Andersen:  No, I understand that.  Would it be the ARIN Online account for anybody associated with that organization is disabled or that organization disappears from ARIN Online accounts?  Was there an intent or -- 

Amy Potter:  I don't think that was a scenario we thought there.  It could be just that you are prompted when you log into your ARIN Online account, if one of your organizations is lacking a valid tech or admin POC, you would be prompted to validate that before being able to engage in further activity on ARIN Online. 

Owen DeLong:  Right, but if one of my accounts that I do stuff for has this problem and I'm trying to go manage something for another entity, I don't want to have to clean up their problem before I can solve my other entity's problem. 

Paul Andersen:  John is looking like he needs to --

John Curran:  The proposed problem stack says -- or, sorry, on policy text says "organizations lacking a valid tech or admin POC will lose access to their ARIN Online account until a tech or admin POC has been validated." 

Now, that is a particularly nonsensical statement in one regard, because it's talking about organizations losing their ARIN Online account, which they don't have. 

But it's also -- the intent is semantically valid, amazingly, which is an organization needs to have valid POCs in order to be managed via ARIN Online.  Organizations not associated with any valid POCs will not be managed by anyone until this is corrected.

So I think the phrasing is particularly interesting.  But it still has the same effect, if you see what I'm saying.  There's an organization that has no POC affected with it, which is what it says, an organization with no valid POC is not able to be managed.  

Paul Andersen:  I think Kevin Blumberg has an early staff assessment.  Sent to staff, assessing the text as we speak.  So it's probably some need for clarification there.

So I think that sounds like something that needs to be clarified.  Going back, did you have some more points? 

Owen DeLong:  No, that was it.  Thank you.

Paul Andersen:  You're against the policy.

Owen DeLong:  Against the policy because of the removal of reassignments. 

Paul Andersen:  But the problem statement, you're --

Owen DeLong:  Well, the problem statement is ludicrous, as Ruediger stated, but it doesn't matter after we make it a policy.

Paul Andersen:  We'll take that input.  Thank you. 

John O'Brien:  John O'Brien, University of Pennsylvania.  Couple comments that I think will be brief. 

To the second question on this slide, will the validation that occurs be meaningful, I would propose that it is meaningful because any validation shows that there is an active point of contact that is presumably receiving the prompts to go validate.

So to me there's sort of a bright line between something that shows activity and something that doesn't show activity.  Perhaps not as meaningful as we might like, but meaningful nonetheless. 

The second point is that -- and partly in response to Owen's points -- if we consider this not just access to ARIN Online, but the privilege to perform management functions through the ARIN Online with respect to the affected organization, it might help to achieve that clarity that we're looking for.  Essentially you've got to validate in order to do the thing you want to do.  So that's my input.

Paul Andersen:  Thank you.  So we are getting a little close to the end of time.  If you do want to speak, I'd like to try to let everyone have the chance to speak, but you need to approach a microphone rapidly so that we can make sure there's time. 

But I'll be closing the microphones shortly.  We'll go to remote participation next, Chris, if you can get as many as you can let me have. 

Chris Tacit:  Only seems to be active when I'm pushing it down actively. 

Marla Azinger, Frontier Communications, says:  I support what staff is doing by prompting POC validations when you log into ARIN Online.  I had them do it to me once recently and it was great and made it easy.

Paul Andersen:  Thank you for that remote input. 

Okay.  We're going to close the microphones and remote input after this next speaker.  Far microphone. 

Bruce Roberts:  Bruce Roberts with DomainTools.  I'd like to second the gentleman from Akamai in that I support the intent of the policy but not the dropping of the reassignment validations. 

Paul Andersen:  Okay.  Thank you for that. 

Center microphone. 

Jason Schiller:  Jason Schiller, Google, ASO AC.  I support the policy as written.  The previous versions of this had issues with the removal of data from Whois and the removal of resources, and that's been fixed.  Thank you. 

And I'd also like to point out that this discussion about incentivizing the upstream ISP to do the right thing and have their reallocations and reassignments accurate is not actually part of the text as written, which is why I support it as written. 

I don't support this new twist of penalizing the upstream ISP if their records are inaccurate. 

I also do -- and I echo the same concerns that I think it was Ruediger and Kevin Blumberg brought up for reasons for that. 

I also am concerned about when someone picks a random content and SWIP addresses to and you don't know about it. 

I also have been victim of this and have only found out because I had a reassignment for a point to a point, for example, SWIP to a random contact at my company who reached out to me and said:  Why do they think I'm the authority for these resources? 

So please do keep sending those emails.  You might want to not have it be part of the rest of the process of marking invalid and whatnot. 

I also agree with Owen's concerns about locking of only a single Org. 

I manage multiple Orgs.  And if one of them is without valid contacts, I should only be prevented from doing useful transactions for that Org that doesn't have valid contacts. 

With the exception of maybe billing, I think it's probably worthwhile for someone to be able to continue to pay their bill even if their contacts are not up to date. 

And so as written, I support it.  With the twist of penalizing upstreams, I think that's a bad idea.  There's also one other idea that was floated on PPML quite a bit to deal with this issue of randomly assigning a contact for reassignments. 

And that is if you're making a reassignment to a POC that's not one that's linked to your account, they have to approve it or authorize it or acknowledge it.  That would be even better than what we have today, waiting for the annual email to come out and find these things that have been randomly assigned to us.  Thank you. 

Paul Andersen:  Thank you, Jason, for that input.  Microphones officially closed.  That microphone there, and we'll finish off here unless a remote has snuck in. 

Jason Plomp:  Good morning.  My name is Jason Plomp with the Royal Canadian Mounted Police.  We're the national law enforcement agency from Canada and the nine Canadians that are in the room. 

(Laughter.)

Obviously I support this motion as it's written.  However, we're willing to massage it however we can to help the community accept it a little bit more.

To put it into perspective, the National Child Exploitation Coordination Center in Canada had 27,000 referrals last year for child exploitation related.  So these are children that are at risk.

And we use the Whois to determine where the jurisdiction is to start that investigation, to try to either bring someone to court or to save a child. 

So this is why it's important to us.  It's not -- we're not trying to ram anything down anybody's throat.  We're just looking for help in order to do our jobs a little bit better. 

And so that's just a little bit of perspective.  Canada is only -- we only have 30 million people and we have 27,000 referrals last year. 

So it's a big problem that we're trying to get a hold of, and that's why we've come to the ARIN community to try to get that support and to try to help (indiscernible).

Paul Andersen:  Thank you for that comment, and we'll finish off here. 

Carmen Alvarez:  Carmen Alvarez, DEA.  We support the POC validation.  I think it's very important not only for us to have correct and accurate information but also for the organizations to post information that they have and that is accurate. 

We also want to be part of this community.  We've been coming to these events for years now and we want to participate.  We feel that we can add something to this; that we can actually be proactive and help out.  And we also believe that we actually get information from you that is very useful for us. 

So I think this should be an open conversation between law enforcement and the community.  Thank you. 

Paul Andersen:  With that the microphones are closed, unless, Amy, any final comments?  Let's thank Amy for the presentation. 

(Applause.)

My thanks again for also the law enforcement that was able to come to the meeting.  It's great to hear that stakeholder input.  It really helps when you can be here with the community to hear the concerns and the practical. 

There's no show of hands on this.  This is just a Draft Policy, but I would urge you, if you do have feedback you'd like to give to the Advisory Council, we'll be meeting later this week, either grab the shepherds, Amy Potter or Alyssa Moore, or any of your friendly local Advisory Council members, and please give them input, even if it's just to say you're supportive or not. 

With that, I'll turn it back to John for the next one. 

John Curran:  Thank you, Paul.  Okay.  Getting back on schedule here bit by bit.  The next policy up is Draft Policy ARIN 2017-8:  Amend the Definition of Community Network.  That will be Andrew Dul.  Come on up, Andrew. 

ARIN-2017-8: Amend the definition of Community Network

Andrew Dul:  All right.  We're here today to talk about amending the definition of community network. 

So this kind of has a long history.  We've had a community network policy in the manual for a number of years.  It's not been used a lot.  And so there's been attempts to clean it up, to remove it.  People didn't like removing it.  So here we are looking at amending it now. 

One other item that came up in our discussion is what is a community network?  The Internet Society has a definition that maybe helps illuminate what a community network is for some people.  We may not agree with this definition, but hopefully it helps us think about how community networks can help other people in the world. 

So here's the current text.  I'm not going to read through this, but it's here for our reference should we need it.  But I am going to focus a little bit on the new text. 

So I took the liberty of using large fonts and colors here to help us.  So the red text is about what the kind of an organization that we're talking about.  The purple text highlights an issue that one of the -- was raised on the list about other information technology.  That's too loose of a definition.

And, finally, the green text highlights a part that was also raised about critical functions and paid staff.  One of the main issues of the current text -- or, sorry, the current policy is that it requires 100 percent volunteer.  And it was deemed that that's too rigid a restriction for most organizations. 

So some things that have happened on the list:  Generally speaking, it has not been used very frequently.  We like policy to be used as necessary. 

We're not opposed to having something that's not used very often.  But if it should be used more frequently, we definitely want to make sure it fits. 

As I said earlier, the volunteer-only part has been a stumbling block, we believe.  And there's concern that the current policy has gone from overly strict to the new policy being overly broad. 

So are we finding the right balance here amongst the new definition? 

There's been raised a question about what is a volunteer group.  Is that an organization?  ARIN has an RSA.  Can volunteer groups sign an RSA?  How does that work?  Secondly, the question about volunteers play a large role. 

That has been raised as a possible issue of very wide and open to interpretation.  Should we change that text to make it a little bit more clear? 

Some folks noticed that critical functions may be handled by paid staff seems to imply volunteers shouldn't handle critical functions.  That certainly I don't think was the intent.  We think community networks definitely have volunteers that should be able to do all of the critical functions as part of an organization, as the original one assumed 100 percent volunteers.  We don't want to exclude that.

And there was also comments about nonprofit, not for profit, charitable status, whether that's relevant at all in this discussion or whether community networks should just be defined by what they do, not how they're organized. 

Finally, there's another section that talks about community networks in the policy manual, in Section 6, around IPv6, which has some different text than this definition that's found in Section 2.

There's been some discussion about should we be also opening up that section to editing and making all of these be harmonious.  The current text is only discussing the definition in Section 2, but perhaps we should be looking deep into there.

And, finally, there was originally the community networks policy was created in the idea that it possibly would give fee relief and that the Board needed some sort of definition so that it could define fee relief to a policy area.

The Board has not chosen to do that.  So there's no fees for community networks.  However, the Board has created smaller categories, specifically the 3X small category, that may be much more applicable to a community network.  And should we now change the definition of community network to be more in line with the 3X small category? 

So some questions for our discussion, amongst all the slides we've already talked about.  Is the financial structure of an organization important?  How do we want to define a community network?  Are there elements here we should keep?  Should we throw away?  What parts needed more work?  Should we open up Section 6 and also work on that as well? 

So those are my questions to the audience here for our discussion.  Thank you. 

Paul Andersen:  Thank you.  I'm sorry.  You can keep that one.  All right.  Same drill as before.  Approach a microphone.  However, if you approach a microphone, you're already a bit behind because I'm told we have several remote participation requests queuing up. 

Although, Chris, could you try and maybe reposition your mic because it was hard when you were looking at the screen and -- so maybe you could reposition that. 

We'll go to the remote participation queue in just a second, but we will first go to that microphone over there. 

David Huberman:  Hi, David Huberman, Oracle, ARIN AC.  Jon Postel started a lot of what we do here as the original numbers administrator.  And one of the things that Jon was characterized by was he was very easy going -- let people do what they want to do. 

In the ARIN community, when we make policy, we sometimes go the other way.  And sometimes in an attempt to manage resources well, and to be good proprietors of the numbers that we look over, sometimes we go the other way. 

We've had this community network policy for a very long time, and it hasn't been very well used, and we've gotten some input as to why that is.

I think as we've gone through this process and this policy proposal, on the list and in our meetings here, I think we're getting a lot closer to it.  I really like this more liberal definition that we're moving towards.

I'm especially in favor of the most recent draft that was posited on the list just yesterday by Richard Lutz, which opens up the language even more.

My input is simply to say I'm fairly strongly in support of the work that we're doing here, and we need to let community networks do what community networks want to do so that they can provide Internet connectivity to those whom they serve.

Paul Andersen:  Thank you for that statement in support.  All right, Chris, I believe we have almost seven, if not more, remote participation.  Can we knock two out for now? 

Chris Tacit:  Marla Azinger says:  I don't see a problem with the current text, nor that no one has used it recently.  I'm concerned we're opening up to scope creep for no valid reason.  Are there entities that have tried to use this policy and were denied because they don't qualify?  If yes, how many? 

Paul Andersen:  Is anyone from staff able to answer that quickly or at least maybe queue it up for an answer? 

John Curran:  We know we've approved one.  In terms of -- I don't know if we haven't had other requests or if we've turned them down, but I will get that stat and report it back promptly.

Paul Andersen:  We have approved one?  We have not approved one.

John Curran:  We've approved one.  I know we've approved one.

Paul Andersen:  Is this recent? 

John Curran:  I don't know whether or not that's because we've turned down all the others or received none of the others, but I'll let you know shortly. 

Paul Andersen:  Okay, Marla, we'll get you more data on that.  Thanks for the comment.  Next one, Chris Tacit.  

Chris Tacit:  That's it for now.

Paul Andersen:  I heard we had many.  Sorry.  Center microphone, then. 

Dani Roisman:  Dani Roisman with IBM SoftLayer.  I'm in support of the work we are doing on this policy as well. 

I just wanted to offer a suggestion.  The last sentence of the new text is pretty self-contradictory.  It says that functions are handled by staff but could be handled by volunteers.  My input is, since we've argued a little bit about it, just drop the whole darn sentence.  I don't understand really the point of mentioning it.  Or just simply say "critical functions may be handled by staff or volunteers" and leave it at that.

Paul Andersen:  Supportive of the policy direction but just think drop that sentence? 

Dani Roisman:  Just drop it so it's not -- I think it's a little too complicated, and I think it's unnecessary.

Paul Andersen:  Okay.  Thank you for the feedback.  Far microphone.

Kevin Blumberg:  Kevin Blumberg, The Wire.  I authored the first two community network proposals.  I'm not going to talk about the text.  I'm not in support of this policy as it's written or as it's arranged. 

My issue is very simple.  What is the problem in our policy today that is preventing community networks from getting space?  If there's a problem getting space, does that benefit apply to everyone or should it apply to a limited definition, i.e., community networks? 

If there's no problem getting space because of all of the changes that have occurred in the last eight years since this policy came out, then we don't need to have community networks at all, because our general policies have improved for everyone. 

If there's an issue where if you can't get space, then the question is, is there a benefit for everyone in the community to take advantage and have that, or do we need a definition?  Nobody has answered the fundamental question of who is being turned away and why.  And until that is answered, this policy is going to go nowhere. 

Paul Andersen:  You're opposed and you're opposed because you don't believe there's a valid problem statement effectively.

Kevin Blumberg:  Correct.

Paul Andersen:  Thank you.  Microphone over there.

Jeremy Austin:  Jeremy Austin, Whitestone Power & Communications, ARIN Member and Fellow.  I ran a completely volunteer community network for about 15 years but was not yet an ARIN member.

When I became a paid employee and an ARIN Member, then I of course no longer qualified despite the fact I was still undeniably running a community network. 

I, however, differ with our friend from The Wire.  I do believe this definition should be changed, but -- so I support this policy.  However, I believe that the benefits are insufficiently defined.  So I do agree with him on that point.

The arguments, for example, saying that if you're larger than a 3X, I'm not sure that's valid.  I'm larger than a 3X, but I think I would still qualify as a community network.

Paul Andersen:  So, I think where the interesting question was -- maybe either you can answer now or later -- is assuming this text was adopted, is there still something else that's prohibiting your network from operating in ARIN policy?  Because I think that's what I heard Kevin asking.  Correct? 

Jeremy Austin:  I don't believe that there is. 

John Curran:  You don't believe there is? 

Andrew Dul:  Do you believe that your organization would qualify under this text now? 

Jeremy Austin:  I do. 

Andrew Dul:  Okay.  Thank you.

Paul Andersen:  So the question -- your organization would meet this text, but is there a request that you would like to make that you would not get under current policy even with this -- like, is there a resource that you believe you have tried to request or would request in the future that you would not qualify under this text?  Because I think that's what Kevin was trying to get at is he's trying to get --

Owen DeLong:  No, he's getting at would he qualify without a community network's policy.

Paul Andersen:  Let me ask Kevin since he's at a microphone.

Kevin Blumberg:  Specifically, since this policy -- since the last eight years, I believe regular policy, standard IPv6 policy, has eased so much that you would never need to use the community network's policy. 

So if people are being rejected because they're so small or so specific, that's great.  I'd like to hear that.  But I believe everybody in this room who is a community network can get it under regular policy and doesn't need this policy.

Paul Andersen:  I'm just trying to synthesize comments.  I'm not trying to -- that's what I heard was that even if -- I think Kevin was just saying that if this definition is changed, it still doesn't add anything. 

I see John Sweeting in the aisle, so I don't know if there's a data point that he would like to do, so I'm just going to let him inject for a second. 

John Sweeting:  John Sweeting with ARIN.  At John's request, there have been none disapproved.  There's been one request actually in the very -- a few weeks ago that was approved. 

There was one denied, but that was the one that was the reason for the policy being made in the first place.  So it wasn't under the current policy. 

Paul Andersen:  So, in theory one denial and one pre -- and then there's been one approval which is a very recent development. 

I'll go back to you, sir, if you wanted to add anything. 

John Curran:  We had one request before the policy.  It was denied.  We made the policy.  The policy has been out there seven-plus years.  And very recently we've had the first request that came in and was approved under it.  So it's hard to say the policy's defective given the absence of application of it. 

Paul Andersen:  I think that's the question that would be curious -- if 2.11 does not exist at all in the NRPM, would that request that just came through had been denied, would have been an interesting --

Jeremy Austin:  It would have been helpful when I was making the initial request.  I was unable to do so because I did not qualify as a community network.  Now I agree, it would not necessarily help me so much then. 

Paul Andersen:  Okay, we appreciate the feedback.  We'll let you off the hook.  Just check any remote participation?  No.  Okay.  Middle microphone. 

Owen DeLong:  Owen DeLong, Akamai, ARIN AC.  It is a bit of a fallacy to look at the number of denials as a measurement of the number of people that don't fit the policy or can't apply under the policy, because the vast majority of people are actually capable of reading policy to some extent at least, and they can go:  I don't qualify, I'm not going to apply. 

And ARIN would never see those people that are disqualified by policy because they don't ask to be denied.  They simply deny themselves, realizing that the policy says you will be denied.

Paul Andersen:  That's a fair point.  And we would obviously urge those that can hear this to give examples where they might have applied if the text was different but did not, which I believe is a good point.

Owen DeLong:  I think there are a number of factors that account for the fact that this policy has been little used, not the least of which is until this year there was really no measurable place where IPv6 represented more than about a small fraction of traffic. 

Now we've got US mobile providers up over 60 percent of their traffic on v6.  Eyeball traffic in US is approaching 40 percent v6.  And so v6-only policies are starting to actually have some actual usefulness, and you can actually now potentially build a network that is v6 only and not have everybody just completely laugh at you. 

So I think that the policy may have been rather early in its adoption.  And that's fine.  There's nothing wrong with us being ahead of the game, in my opinion. 

I think that the very narrow definition of community networks that we're now looking to expand is another factor.  And I think that expanding the definition as proposed here will probably make additional availability to community networks.

Paul Andersen:  So, supportive of the policy and supportive of this approach to the problem? 

Owen DeLong:  I am supportive of both the policy as it exists and of this modification to it.

Paul Andersen:  Okay.  Thank you.  We are getting to the end of the time.  So I just want to make sure if there's any people that would like to get, that you either start typing madly if you're remotely, or that you approach a microphone.  Otherwise I'll be closing the microphones very shortly.  We'll go to this. 

Matt Petach:  Matt Petach.  I'm going to ask what probably is a dumb question, but --

Paul Andersen:  There are no dumb questions, but I may not know the answer, so --

Matt Petach:  What would prevent a community network, as defined in this, from just applying as an ordinary end-user assignment? 

Unidentified Speaker:  I think they wanted (indiscernible). 

Matt Petach:  I don't see anything about fees at all, in the text here at all.

Andrew Dul:  I think the intent was that they're more of an ISP-type organization, and so they would then qualify for a larger block and can do reassignments or reallocation. 

However, there's kind of a loophole or a weird part about that.  It says we get put in the end-user status.  So then they're not able to do those things that maybe an ISP would want to do. 

So it is originally about fees in the old days.  And I think we raise that issue as well.

Matt Petach:  So the justification for this is so you can be classified as an ISP, which isn't mentioned in the policy text, and you get a break on fees, which is also not mentioned in the policy text. 

Paul Andersen:  Fees can't be mentioned in policy text because that's not a purview of policy.  Having said that, obviously, if there's a definition and it's in the policy, it can make it easier for the Board to set a fee that would -- say those that qualified under a section.  That is the reason "fees" does not appear; the AC would know that that is out of scope. 

Matt Petach:  I'm then against this policy as it is written and in concept as I think this is trying to solve something that should not be solved this way.  Thank you.

Paul Andersen:  Thank you.  So I'm now closing the mics.  If that's you entering the mic, you're not entering the mic, then back away from the microphone, sir. 

All right, the microphones are closed, so we'll go to center microphone and then clear out our queue.  And there's a remote participation.  We'll get in there soon.  So, go ahead. 

Jason Schiller:  Jason Schiller, Google, ASO AC.  I fully support fixing up the community network's definition to remove the 100 percent volunteer piece.

I am concerned that the other information, technology services, is too vague and opens it up too much.  But with that part stricken, I support the redefinition. 

The second piece of this is Section 6.5.9, which references this definition of community networks. 

And this is the part that says that, even though they're providing transit to downstream customers, we're going to treat them like an end-user in order to get fee relief.  It doesn't say in order to get fee relief, but that's the unwritten text there.

I'm not sure that we even need 6.5.9 now at this point based on how fees are structured.  And if this really is a fee issue, I am happy for my fees to be increased for the very smallest ISP fees to be reduced further. 

Right now they're at $250 annually.  I could even see them going down to $100. 

Paul Andersen:  I appreciate that point.

Jason Schiller:  With that being said, I'm not sure the definition is useful, but we could keep it in the event that community networks needed some other special benefit at some point in the future.  But I don't see any benefit that a community network needs that they can't get as a regular end-user or regular ISP. 

Paul Andersen:  Understood.  I ask if there are feedback or suggestions on fees that we raise that either during the Members Meeting or the Open Microphone that will be at the end of the day. 

Let's go to remote participation.  And if those in the line could limit their comments as succinct as possible.  Go ahead. 

Chris Tacit:  I'm going to have to tell you that this comment is about fees.  Marla said:  Are entities just trying to get this policy to cover them to squeeze into some form of relief of a fee? 

Paul Andersen:  Thank you, Marla, for the comment. 

Rudi Daniel:  Rudi Daniel, Caribbean.  I am in support of this proposal and the approach taken.  Although I'm not quite sure that we have the definition right as yet.  And I don't have a problem with the fees that currently exist or that is proposed around the general conditions.

Paul Andersen:  Okay.  Thank you for the support.  And the last comment from the room will be center microphone.

Alyssa Moore:  Alyssa Moore, Cybera, ARIN AC and policy author.  I kind of threw the kitchen sink into this definition to spur the conversation.  So thank you, everyone, for that.

That being said, at this point I am in support of -- I think it was Dani who brought it up -- clearing up the language around critical functions and potentially just dropping the volunteer-versus-staff portion in that last sentence.  Certainly we would love for volunteers to be performing critical functions.  That is not something that it was intended to prevent. 

And is final structure important?  Perhaps not.  I think that the staff is capable of interpreting applications under this policy for whether or not we've got a multimillion dollar company looking to use this policy, obviously is going to be denied.  So that may be able to be removed as well. 

Paul Andersen:  Thank you for that comment.  That ends this Draft Policy input.  I'd like to thank Andrew Dul for the presentation. 

A reminder that the shepherds on this are Andrew and David Farmer, who was in the back of -- oh, he's right there.  So, again, during lunch, which we're going into pretty much right now, they would love to hear any feedback you can.  So, thank you very much.  And that ends it now, and, John, throw us to lunch. 

John Curran:  Okay.  Very constructive discussion.  It is now time for lunch.  Lunch is going to be where you had breakfast, which I believe is outside and down the steps.  And we're going to go through two more proposals this afternoon. 

So lunch is from now until 1:30.  Take your valuables with you -- yeah, attendee lunch in the Club Regent, which is outside, downstairs.  Two lunches.  Yes, we'll get there. 

Make sure you take your materials with you.  There's a Women's Networking Lunch.  If you signed up for that, it's in the Piedmont Room. 

And take your valuables.  This is an open, unlocked room.  I will see everyone at 1:30.  Thank you. 

(Lunch break at 12:10 PM)

Second Customer Survey

John Curran:  Okay.  I'd like to welcome everyone back from lunch.  And we have a couple things this afternoon to go through.  First, I want to thank our sponsors -- our refreshment break sponsor, Avenue4. 

(Applause.)

And, remember, turn in your ticket this afternoon to get your ARIN 40 t-shirt. 

Our agenda.  We actually have on the agenda -- you want to do the customer survey as well?

Richard Jimmerson:  I can if you'd like me to.

John Curran:  Can we queue up the customer survey one we didn't do this morning?  We'll have that just before the ARIN website redesign. 

So, we have the presentation we didn't get through this morning, which is ARIN's second customer survey, which is coming up.  Richard will talk about that and the ARIN website redesign.

Then we'll move into election procedures and candidate speeches.  We have a Caribbean update this afternoon, and we have an Open Microphone. 

In terms of policies, we still have some policies on the agenda.  We're going to be talking about ARIN Draft Policy 2017-4:  Removing Reciprocity Requirement for Inter-RIR Transfers; and 2017-6:  Improving the Reciprocity Requirement for Inter-RIR Transfers. 

At the head table, it's going to be me for this next segment, and I'll take it now to Richard.  Richard, you can do the second customer survey. 

Richard Jimmerson:  Thank you, John.  So I'm going to be talking to you about two topics today.  I'm going to talk about the second customer survey that we're doing, and I'm also going to talk to you about the redesign of the ARIN website.  But first the customer satisfaction survey.

As many of you may recall, you may have participated in our customer satisfaction survey back in 2014 when that was completed.  And we had about 698 survey participants back in 2014.  It was the first time ARIN had ever done a large-scale, global customer-satisfaction survey.  And we will be doing another one here inside the next month, and want to talk a little bit about that. 

It was completed last time, conducted last time by Rockbridge Associates Inc., and the results that we received from that survey did inform changes to our services inside the organization. 

Of course, our Board approves all of our services and everything that we do, but they have a very strong, tight set of controls in place to make sure that we're also providing the best possible customer service to the organizations who pay fees to us and who are registrants of the ARIN database.

In the first you can see this is a demographic breakdown of who took the survey.  And we don't know if it will be the same this time, but if you do want to see the full survey results themselves, if you go to the ARIN website and you click on the "About Us" and you select the corporate documents, on that corporate documents page you can see a customer survey results there. 

We published that immediately following the survey last time when we did this.  Now, when our contractor did the survey with the community a couple of years ago, they provided us a product back to the staff and said:  Here's the results of your survey. 

And they asked us another question, and the question they asked us was:  What would you like us to put together so that you can show that to your constituents or show that to your community? 

And that was evaluated internally, and John and the Board and others said, you know what, we don't want another product.  We want the community to see exactly what you showed us.

So as you go through and you look at this, if you haven't looked at it before, you're seeing everything -- the good, the bad -- and nothing was hidden.  It was completely transparent in what we published out to you as the community as directed by our Board of Trustees at the time.

And I fully expect that the same thing will be done this time when we do this next customer satisfaction survey. 

Now, between the big surveys, the one that was completed in 2014 and the one that we'll be starting here in the next month, there are other ways that we receive feedback and survey information.

Of course, we have the feedback button that's been put in place since the last customer satisfaction survey, and that's used frequently.  It was used 10 times just in the last couple of days. 

We have transaction surveys.  Anytime you come and request resources directly from ARIN, you're given an opportunity to answer a survey about what your experience was like with ARIN, and we make adjustments and changes inside the organization based on the results of those surveys.

We get telephone calls, documented feedback from those tickets.  We have the ACSP process.  We get direct feedback, of course, during these meetings and also at the ARIN on the Road events. 

And of course the Mailing List provide quite a bit of feedback to the organization.  But there's nothing like a big customer satisfaction survey.

So this is going to start in the next month.  Many of the questions you'll see mirror those from 2014, and the reason why is because we want to show you a benchmark. 

We want to show you how well we improved or how well we didn't improve over the last three years from the last time we did one of these large surveys.  And we think that the data we receive will help you see that, and we're going to publish that to you.  And you will see it just like we do.

The survey objectives are listed here.  These are some of the survey objectives.  These are the types of things that we're looking at when we do the survey. 

And, of course, again, when we get those results, we are going to publish them for full transparency to the ARIN website. 

Inside the next month you'll see a survey invitation.  Please participate in that if you receive it.  It's very helpful to us.  It's very helpful to you, to the community.  And you should expect within a few months after that to have the survey results published to the website, definitely by the end of the year.

And that's it for the customer satisfaction survey, if there are any questions. 

John Curran:  Any questions for Richard?  Proceed ahead, Richard.

ARIN Website Redesign

Richard Jimmerson:  All right, I'm going to move on to the next presentation, and the next presentation is about the redesign of the ARIN website. 

All right.  Now, I know a lot of you have been asking us at the microphone and provided feedback in recent surveys and over the years:  You know what?  It's time you do two big things.  You need to redesign the website, do a complete facelift on it because it's not working well on mobile devices, on my tablet, my phone, and those types of things.  And also the navigation could be better.  There's other things about the site that we'd like to change. 

And I'm glad to say that earlier this year we were given approval inside the organization to actually pull together a team inside the company and start working on this project.

Now, why do we want to redesign it?  Of course, because of your feedback.  And we want to improve the experience for ARIN services and provide better integration of the information sections of the website and the ARIN Online services that you all use. 

Here's a list of some of the high-level requirements we have.  At the top of that list, of course, is that it has to be a responsive design that will natively render to any device that you might use.  That's not the case today with the existing ARIN website. 

We want integration as described or -- we want integration of various Web-related suggestions that you have submitted over the years through the ACSP process.  Again, ARIN Online. 

Of course, we want to meet industry standards.  Another big thing that we're doing is we're going to be de-jargoning a lot what's on the website today.  A lot of you in the room understand the acronyms that are being thrown around in the room here, but a lot of you outside the room do not understand those acronyms or some of those terms.  So we're going to be working really hard to de-jargon the website as well.

But, of course, going through and doing this work, the main and the top priority for us is to maintain the security of ARIN Online when we're integrating these sites and we're making these changes.  So we assure you we're doing that.

And also inside the next six months we expect that we're going to have a sample site out there for you guys to start looking at so that you can give us feedback so we can polish that according to your needs going forward.

Now, here's a timeline.  We started this project in the third quarter of this year, during the summer.  The team consists of elements of our communications team, a developer, an integrator, some user-experience experts, and other staff and stakeholders are working on the project inside the organization. 

It's a very high-priority project inside the ARIN organization.  There is no risk that we will stop this project and not finish it. 

And also on site today you may have seen and also yesterday and then also available tomorrow we have some of our user-experience staff onsite at the meeting to get feedback from you on things that you might have to say about how our website currently operates or what you think the new website might look like. 

So today the back-end platform and other tools have been set in place.  We've done some work over the last couple of months to get that set up.  But a site design navigation and overhaul are currently being worked on and underway right now.  And we're looking to establish by April of 2018 the preview site that I talked about.

The next time we have an ARIN meeting, in place of this presentation what you'll likely have is a small demo of what the site looks like, and you'll be invited to go look at that and tell us what you think about it. 

For the remainder of 2018 past that, we'll be transitioning everything from the old site -- we have a lot of content on the ARIN site -- and we'll be transitioning that to the new site and looking to launch the new site for you. 

So that's an informational item, but we did want to let you know that that project is in play and is actively being worked on inside the organization by a dedicated team.  And we look forward to providing that new product to you very soon. 

Are there any questions about the new site, the project that we've started?  Kevin. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  One question and one comment.  I'll start with the comment.  Thank you.  Thank you, thank you, thank you for doing this.  I can't use your website on my mobile phone, so this will be wonderful. 

The question I had was you mentioned back-end systems.  Is the entire www.arin.net, ARIN Online, all of that part of this overhaul? 

Could you just sort of explain the scope of what site we're talking about? 

Richard Jimmerson:  Right.  We're talking about the arin.net site.  But also there's going to be integrations of ARIN Online that may look a little bit different than they do today.  So it's all of arin.net. 

What you have right now that's protected inside ARIN Online will remain the same, and we continue to work on improvements inside of that on a monthly basis. 

We've been actively working on that for many years.  The improvements that they make -- we make there will continue.  However, the major thrust of this project that I'm talking about is everything that's outside of ARIN Online that lives at arin.net.  That's being completely overhauled and being built for responsive design, including ARIN Online.  And including all of the information elements of the website that are not inside ARIN Online. 

So it does encompass everything inside arin.net.  However, this project does not interfere with the other improvements that we're also making at the same time with ARIN Online.

John Curran:  Everything that you see that you use on the ARIN website, without logging into ARIN Online, will go through significant change, complete redesign. 

ARIN Online itself will line up with those changes but is not going through the level of redesign that the ARIN website is.  Does that clarify? 

Kevin Blumberg:  Partially.  The reason I was asking was you mentioned back-end integrations, et cetera.  And I'll use one of the key new features, responsive.  Responsive is very important, having a site that works on anything.

Responsive to me also is not having to take 18 months to redevelop, to keep up with technology.  So my only concern is if you're doing a lot of custom integrations, you might not be as responsive to being able to adapt to the change in the Web requirements over time. 

And I would rather have separations, less integrations, possibly, but more of a front end for the endusers and new people coming to your site that works.  Just a comment.

John Curran:  That's effectively what we're doing.  We're focusing on the front -- what you see when you go to the ARIN website, all the information on the content, we're trying to make sure that's accessible, like, from your mobile device and your pad. 

Once you log into ARIN Online, you're in an application, and a lot of the content you're seeing is driven by that application.

That's not being as extensively redesigned because it doesn't need it.  We've been planning for that for years and years.

But the website has a lot of controls -- knobs, menus, pull-downs, pop-ups -- things that need to be harmonized on a general design interface.  So it's the wrapper, if you think about website content, website wrapper, not the ARIN Online application behind the scenes.

Kevin Blumberg:  Thank you.

Chris Tacit:  Remote comment from Marla Azinger:  Can anyone be involved in the test site?  Do we need to sign up for that? 

Richard Jimmerson:  When we put the test site up for review by the community, we're going to invite anyone to participate in that process that is interested, absolutely.  So our intent is to publish that and make it available to people to use, review and make comment back to us on, and we're going to take those comments and that feedback and we'll make further improvements before we release it as final.

Chris Tacit:  No registration? 

Richard Jimmerson:  I do not believe there's going to be a registration window for it.  I expect that we'll publish it in a public way so people can see it and provide direct feedback without having to log in or do any sort of special registration. 

John Curran:  Any other questions?  Yes, over there. 

Kathleen Hunter:  Kathleen Hunter, Comcast.  I did want to thank you guys for opening this up to the user.  But as the users, I think it would be beneficial for as many people as possible to test this out so that we don't complain about it later if something's wrong with it.

The other thing I did want to bring up, since I've tested this already, I don't know if I'm the only one that notices that there's no modify function for reassigns.  Just something to bring up. 

I do have customers that change from one unavailable address to two unavailable addresses.  And I have to do that either through the API or through email or I have to delete it and then re-add it, which is two tasks instead of one.

John Curran:  Just so we don't lose track, can a member of the staff get with her so we can put that in the suggestions? 

Kathleen Hunter:  I've already -- I just wanted to bring it up kind of in the public just to get a feeling --

John Curran:  Did you submit a suggestion to the ARIN --

Kathleen Hunter:  I did.  They have it.

John Curran:  Oh, great.  So, we'll hunt down that one.  That's a very valid point. 

Kathleen Hunter:  The other thing I wanted to bring up was we have all the policies as they stand now, but don't necessarily have historical records of what they started as and what they are now.  And commonly we have policies that get referenced to the started one way and now it's another way. 

Sort of a suggestion that I didn't bring up to them was maybe we could have somewhere where we have historical records of policies from start to finish.

John Curran:  So on the website, if you go to the NRPM, the Number Resource Policy Manual, you go to the box in the upper right, there's a change log which references each section, when it changed and what the policy that was adopted of text before and the text after.  Should have that.  It's in the upper right corner of the NRPM page. 

Kathleen Hunter:  Thanks. 

John Curran:  Thank you, Richard. 

(Applause.)

Okay.  We're now going to move into the elections.  And we start out by having the election process overview, and that will be done by Susan Hamlin.  Come on up, Susan. 

ARIN Board of Trustees and Advisory Council Election Procedures and Candidate Speeches

Susan Hamlin:  Good afternoon, everyone.  I'm filling in for Wendy Leedy, our Member Engagement Coordinator, who is responsible for facilitating the elections and did most of the work now.  And she's happily at home with a three-week-old baby boy.  So just a shout-out to her and to thank her for all of her work. 

(Applause.)

So, I'm going to run through the election process, where we are to date.  So eligible voting contacts for general members in good standing.  The cutoff for voter eligibility this year was the 20th of August. 

And the election this year -- let me back up.  So this morning you probably saw an announcement, the Board of Trustees this morning, at their meeting, appointed Kevin Blumberg to serve a three-year term on the NRO Number Council.  So, congratulations to Kevin. 

(Applause.)

So that was an appointment year.  This year, in the election, we have two seats on the ARIN Board of Trustees and five seats open on the ARIN Advisory Council. 

Voting will open today, 6:00 PM Eastern Daylight Time, 3:00 PM here.  And voting will remain open until 6:00 PM Eastern Daylight Time, Friday, the 13th of October.  Can't do much about that date.

Voting is online this year.  Everyone will vote through ARIN Online.  You can vote anywhere -- office, home, computer.  I've been told in the past some people are able to vote on their mobile device.  So hopefully that will work for you. 

Four easy steps.  You log into the ARIN website.  Log into ARIN Online.  You will see on your dashboard a "Vote Now" banner.  Click on that and it will bring you to the ballot.  And I'll walk you through what that looks like.

Why you should vote.  Because it's your responsibility and your privilege as an ARIN member to select your leaders.  You're going to carry ARIN in the future.

It is your opportunity to exercise this, and every member organization gets one vote, no matter what size your organization is.  So your one vote does count. 

So election dates, this is just to show that we followed the bylaws and the voting requirements that are published on the ARIN website. 

So the call for nominations was the 17th of July through 15th of August.  We set the voter eligibility deadline, August 20th.  We announced the initial slate of candidates at the end of August. 

At that time we also have a Call for Petitions.  Anybody is able to run a petition, and if they get enough support, their name would appear on the ballot.  We had no requests for petitions this year. 

So the initial slate -- final slate of candidates was announced shortly thereafter.  And now we're moving into the voting period.  Winners will be announced shortly after voting closes but no later than the 20th of October. 

Okay.  So to cast your ballot, you'll see you'll open up the ARIN website.  Log into ARIN Online.  This is what you should see, this blue banner on your dashboard.  If you click on the "Vote Now" link, it will bring you to a couple of pages, a transparency agreement that you'll click on "I agree." 

And it will bring you to the first ballot for the Board of Trustees, and you will click -- so some voting representatives represent more than one organization. 

So in this little box for weight, they'll see a weight that's equivalent to the number of organizations for whom you serve as a voting representative. 

So the way the system is set up, you can cast all of your votes at one time, if you choose to put all of your weights in at once, or you can change your weight.  And suppose you are a voting rep for two organizations and you want to vote differently for each one, your weight would be one and you'd cast that ballot and come back and you'd have an additional weight of one to cast your other ballot for the other organization. 

Select your candidates.  Hit "Submit Vote."  And then if you have more weights to use, the ballot will pop up back again and you can enter the weight you wish to use.  Go through the same process.

And then you'll see a vote confirmation on your screen, and you will also be emailed a confirmation.  So it's pretty straightforward. 

Just a few reminders.  When voting opens, we have some copies of the voter guide up at the election help desk outside.  You can go online and read the candidate bios.  You can read the statements of support, and you can still make statements of support throughout the entire election. 

Voting will open at 3:00 PM here this afternoon.  I will be out at the election help desk during break this afternoon.  If you have any questions or issues, please find me. 

And please remember that polls close sharply at 6:00 PM.  I encourage you not to wait until the last two minutes in case you have an issue and you need to reach out to us for help. 

You can email questions to members@arin.net throughout the election, or you can also submit an ARIN Online ticket and just select Meetings/Elections and we will look for those questions there. 

And with that, I'll take any questions. 

John Curran:  A comment.  If you are one of those types of people who like to put off things until the last minute, you should pretend that polls close on Thursday, October 12th. 

People trying to get into the election system and finding out that they're not the right contact or they're the right contact but not listed for the organization or all that other stuff, we like to discover that on Thursday.  We particularly do not like to discover it Friday at 5:44 with panicked phone calls, because we've had this in the past. 

So, please, vote early.  If you really want to put it off to the last minute Thursday night, that's great, we look forward to talking to you on Friday.  We'll have the whole day to work it out. 

Do not try to hold this off until the very last minute or run the risk that you will not be able to vote if there's any problem.  And there are sometimes problems.  People don't realize they're not their own voting contact or they're not listed for all of the organizations. 

It's a word of advice, because we've had this happen before.  Okay.  Thank you, Susan. 

Susan Hamlin:  One incentive, for those of you here or those viewing online for you to vote early, beginning next Monday ARIN staff will be calling all eligible voters.  So if you vote before Monday, you won't be receiving that call. 

(Applause.)

John Curran:  Okay.  We will now move in to the candidate speeches.  So for the ARIN Advisory Council we have a number of candidates.  Each one has a short bio, information online.  And I'll invite them up here to say a few words if they wish. 

Paul Emmons.  Paul, are you here?  Come on up, Paul. 

Paul Emmons:  Thanks, John.  Coming to San Jose is always a scary experience for me because when I leave from Phoenix, Arizona, the flight to San Jose, Costa Rica often boards at the same time in the adjacent gate.  I've never made that mistake more than once.

I've been involved in the -- basically in ARIN as a legacy holder since day one, and over the last 20 years as a member for different organizations.  And my friends suggested that I stand for the AC because I've got a lot of experience in the traditional operator space but also in the wireless and Internet exchange provider space. 

Right now my volunteer job is as the CEO for Ninja-IX where we operate five Internet exchanges today throughout -- in the United States, and we have another two coming online in the next quarter.

And so I deal with everybody from a small startup that has a /24, all the way up to the big boys that are in the CDN space.

And so I'm always being asked for a lot of unsolicited advice on how to operate, how to get addresses, how to operate, and a lot of technical questions as well, mostly pertaining to BGP. 

But, like I said, I have a lot of people that are always asking ARIN questions, and I try to direct them into the right place.

My paying job right now is primarily assisting a couple of wireless equipment vendors with their customers, getting their networks transitioned.  And by transitioned, I mean from using RFC 1918 space a lot of times and NAT and using RIP to using IPv6 and the IPv4/IPv6 transition space.

A lot of times that's a very frightening experience, whenever they realize they're going to be dealing with ARIN. 

On the legacy side, we kind of found the same thing as well.  We still work with a couple of organizations that have legacy space, and the only three letters they fear most -- well that's not true -- probably three letters they fear slightly less than ARIN is IRS. 

So I think as an organization we can do a lot more for outreach and education and comfort them as to helping maintain Whois contacts and also doing assignments and reallocations as well. 

So over the years I've attended a lot of the ARIN meetings whenever I can.  Since the ARIN on the Roads have come online, I've gone to many of those as well. 

I've brought along or encouraged our customers to attend those as well.  So right now in my career I have a lot of time and obviously effort I can put forth to serve on the Advisory Council and assist with the other communities in the ARIN area. 

So that's pretty much why I'm standing here for election.  Would appreciate your support.  If you have any questions.  I'll be around.  Feel free to reach out.  Thanks. 

(Applause.)

John Curran:  Next candidate for the Advisory Council is Leif Sawyer.  No?  Leif.  Thank you, Leif.  Sorry.  Come on up.  Now that I've said it right, you get to come up now.  Say a few words. 

Leif Sawyer:  Just a few words.  Thanks, John.

This is actually kind of a joke.  John looks at my name, hears it in his head the right way, and it never comes out correctly.  So we always like to joke back and forth about this. 

So, yeah, my name is Leif Sawyer.  I'm a fourth generation Alaskan.  I usually introduce myself as "the" Alaskan at ARIN.  But we have a Fellow here who is also from Alaska, which is great. 

Jeremy, thanks for coming down and being interested in all of this.  I'm looking forward to talking to you afterwards. 

I've been in the telecommunications industry for 25, almost 30 years now.  I don't look it.  This is what Alaska does to you; it preserves you.  So if you ever -- that's the fountain of youth, is in Alaska. 

It's a very different industry up there in that it's difficult to get out and get down to see what's going on in the telecommunications space and deal with the policy changes and how that impacts the rural communities.

So that's why I started coming down and started talking on the microphones and making sure that there was a voice for the smaller companies, the rural communities, the rural actors.  And I got noticed.  And that was a really scary thing. 

And I got elected, which was a really scary thing.  And I started helping develop the policies.  And it was a really scary thing because I didn't know what I was doing at first.

And part of me still doesn't know what I'm doing.  I feel like an imposter up there working on policies.  But my comrades on the Council give me support and they give me feedback and they encourage me to be here and to continue this as a voice of reason and calm compassion and being dead center and listening to both sides.

And so I'm here standing before you listening to both sides and hoping to continue my work on the council.  Thank you. 

(Applause.)

John Curran:  Thank you, Leif. 

Next up for the ARIN Advisory Council, Kerrie-Ann Richards. 

Kerrie-Ann Richards:  Okay.  Good afternoon, everyone.  So, as you can see, I'm number three on the ballot there.  I don't necessarily look like my other two persons who were ahead of me.  Yeah, with the blue hair, I'm the blue-haired Jamaican. 

But that doesn't matter to me.  I am Jamaican, and I was nominated by Tina Morris.  So ARIN 39 was actually my very first ARIN.  So I was a Fellow at ARIN 39, and I'm a Fellow here now. 

My exposure to ARIN was about six years ago, I would take part remotely.  I've always been on the Mailing Lists.  So I'm aware of what's happening.  So it was quite surprising to get an email in July, I think it was, at the end of July, with:  Would you like to be nominated? 

Fairly inexperienced; however, very passionate about data protection and privacy and all of those things.  I've gone through Internet governance and that sort of thing. 

My background:  So you hear a Jamaican accent, but -- but there's also a bit of a British accent as well because I spent a lot of time in London.  So I studied at London Metropolitan University.  I did business IT.  I worked with learndirect, which is the adult education arm of the UK government. 

I did lots of training, and I've always been a member of the British Computer Society as well. 

So I have a very varied background.  When I returned to Jamaica, it was to make sure that some of the lessons that I was able to learn overseas, I was able to bring that back to Jamaica. 

This is like totally not what I even wrote.  But so the charity that I'm actually working with, we go into primary schools and introduce visual coding to students. 

A story that I've been sharing since I've been here is that we have a number of communities that have been broken up because mom and dad go away to study.  But what we're doing, we're trying to educate families and students that if they can learn to code -- see, the minimum wage in Jamaica, the weekly minimum wage is $50 for the week, as opposed to a coder who is based maybe 1,500. 

So what we're trying to say to them is that you don't need to break up families, you don't need to go abroad and become -- your kids become barrel children as well.  So that's where my passion is. 

But back to data protection.  When I worked in London, I worked with very diverse groups of persons who had to flee where they're from, their comfort zone, their homes, and went into a country where they didn't know anyone.  And they weren't protected. 

And an educational institution needs to be careful of what they keep, the information that they keep.  So I was very early in the whole data protection movement in the UK, and I was adamant.  And every role that I've ever gone into, I've been very adamant about how to protect that information.  But I'm also very big on access to information. 

So there's a little bit of a tug of war, but I'm the person who will advocate for the Caribbean, advocate for the endusers.  And that's me, Kerrie, from the Caribbean, from Jamaica. 

(Applause.)

John Curran:  Very good.  Next candidate for the ARIN Advisory Council is Elford Parsons who could not be here.  I'll read bio and explain why. 

So, Elford Parsons, the Telecommunications Regulatory Commission of the British Virgin Islands, CTO there, advising the CEO on technology matters, involved in shaping telecommunications landscape of the BVIs.  Thirty-year veteran of the telecommunications industry. 

Founder and owner of Tech It Easy, BVI Limited.  A Rotarian for the past 10 years, has served as vocational services director and director of club administration.  Over the years served on various boards including the BVI Electricity Corporation, the National Parks Trust to the Virgin Islands, the British Virgin Islands Ports Authority, and Scholarship Advisory Board. 

Elford can't be here because the BVI is in recovery from hurricanes, and he's intimately involved in that and very sorry not to be here, but will, obviously, when things get more straightened out over the next few weeks, will be able to travel once again and asks for your apologies.  Just wanted to relay that.

Our next candidate for the Advisory Council is Chris Woodfield.  Come on up, Chris. 

Chris Woodfield:  Hi.  I'm Chris.  I was back here at this podium only a year ago when I was, with a little bit of nervousness, asked for you to vote me on the AC for the first time. 

Thank you for your vote then, and I'm here a year later due to the vagaries of the term policies to ask for your vote again to allow me to serve full term on the ARIN AC. 

About myself:  I've been in the network business for almost 20 years now.  That's a bit frightening when you think about it. 

I've worked for large ISPs, content providers.  I currently work for Salesforce.com, an application service provider who fully supports my extracurricular activities here. 

I've been involved in the NANOG and ARIN communities for a good chunk of my time that I've been in the business.  And a couple of years ago I decided to start giving back and volunteering for positions in these organizations and getting more involved in no longer being a net consumer of the benefits the communities provide. 

I am a member of the NANOG Program Committee, finishing up my second year there.  And as I mentioned, I was elected to the ARIN AC for a one-year term last year, and hopefully I'll be able to continue that with your vote. 

What do I bring to ARIN?  ARIN is not a policy organization, at least not a pure policy organization.  One of the foundations of the policies that go into the NRPM is that a policy in the NRPM as a whole must be technically sound. 

As such, engineering and operator experience is required in order to properly vet and process policies and make sure the NRPM, the resulting NRPM from policies are -- do have solid tactical footings and are implementable and usable by the operator community. 

I've been here one year.  And while using that expertise to assist the Policy Development Process, I've also learned to flex some mental muscles that, frankly, I didn't know I had on the policy side, on, frankly, the interpersonal side of policy development.  And it's been an extremely valuable experience for me and one that I hope to continue. 

Two things that are very front of mind, as the -- ARIN continues its mission.  First off is driving IPv6 adoption, which is as much a personal policy process as it is an engineering effort.  And I hope to continue with that. 

Handling IPv4 exhaustion transfer policy, we must be -- we must serve the needs of our community and give and make sure that the community that requires IPv4 space is able to get the resources they need while at the same time being a proper shepherd of that dwindling resource.

I hope that with my continued service I continue to be a key part of both of those efforts, as well as Whois accuracy, privacy efforts and everything else that ARIN finds itself involved in. 

Thank you, and I would very much appreciate your vote. 

(Applause.)

John Curran:  Next ARIN AC candidate, Andrew Dul. 

Andrew Dul:  Good afternoon.  I'm Andrew Dul, and I'm running again for re-election for the ARIN AC.  I'll leave most of my bio comments for the website, but I'd like to have a few other comments here today.

I think I'm, first of all, very proud of the work that we've done on my last term, working all through the transfer change policies that we've done.  And I think the discussion and collaboration that we've had over the past couple of years have been instrumental in moving this organization forward. 

Today I work for CrowdStrike, who is a security software company.  And while that's maybe not a traditional type of person you might see in this room, I would like to note that unique identifiers are the business that we're in, and those identifiers make the world work for all of the fun things and exciting things that we now are able to do. 

But the same uniqueness also allows other types of activities to occur on the Internet.  And working in this industry has made me a little bit more aware of those and how the choices maybe we make in this room also impact us through other actors who may not always have positive intents. 

And, finally, I put in personal time for this work because I believe this work here we do is important.  The relationships that we've built together I think are important to me and to those around me, and it makes the work seem less like work and more like building lasting relationships.

Thank you for letting me serve this community in the past three years.  And I thank you in advance for your vote and your trust in me in the future. 

And finally, last night, I was challenged to do something unique, because I always do that.  So I have a haiku for you to end with. 

Uniqueness our goal.  IP address to deploy.  Route end-to-end.  Thank you. 

(Applause.)

John Curran:  Next up, David Farmer for the ARIN Advisory Council. 

David Farmer:  I'll keep it quick, like I did last time.  It worked.  We'll see if it works again. 

I'm David Farmer.  I work for the University of Minnesota.  A year ago I'd swear I wouldn't have been up here.  But a number of you out there asked me to. 

And my health has improved and I'm feeling a lot better now that I started dialysis.  And so I think I'm ready to go. 

So please vote.  If you vote for me, that would be wonderful, but get on that website and vote one way or the other.  Thank you. 

(Applause.)

John Curran:  Next candidate for the ARIN Advisory Council, Joseph Karam.  Joseph can't be here, so I will read the bio.  The full bio is on the website. 

From Princeton University, the associate director of networking and monitoring services.  Managed team prioritizing resources required to manage care network infrastructure, monitoring services, manage projects and develop plans for improving network infrastructure. 

Past experience includes being senior manager there, being the director of network and communication services at Hamilton College, and being the senior UNIX administrator at University of Rochester. 

The full bio for Joseph is on the website.

Next up for the candidate for the ARIN Advisory Council is Chris Tacit. 

Chris Tacit:  Thank you very much, John.  I'm glad to be here today. 

I'm not going to delve into my biographical information because it's up there and on the website and most of you know me by now hopefully anyway. 

I'm running for my second term on the AC.  When I was elected for the first term, some community participants may have wondered what I could possibly contribute as an AC member. 

What could a person whose engineering skills and activity predate the Internet bring to the AC?  Of what benefit could business and legal skills be? 

I'll be the first to admit that I am not a 21st century network architect or operator.  However, my technical training and background have definitely helped me to contribute to the discussions of the numbering policies discussed by the community. 

More importantly, perhaps, my legal training and experience have fostered an ability to write very clearly and to build consensus.  I believe these abilities have contributed to my effectiveness on the AC.  The same is true of the 28 years I've been involved in telecommunications Public Policy development. 

It is also in my nature to listen and seek to understand, which I believe to be critical to my ability to contribute meaningfully to the bottom-up multi-stakeholder PDP. 

While I put my skills to good use in co-shepherding a number of policies during my first term, I believe one of my most significant contributions to date has been as author of the out-of-region policy which now forms Section 9 of the NRPM. 

That policy was written at the request of some community members who were very concerned about this issue having stalled despite a number of previous efforts to resolve it. 

By working diligently and patiently with the community and the shepherds of the proposal and addressing the problem in a new and different manner, the issue was finally resolved with no express dissent from any community member. 

A big motivating factor for my involvement in ARIN is that I love this community.  Community participants have always made me feel at home here since the first ARIN meeting I attended in Atlanta in 2010. 

I'm particularly grateful for the collegiality, cooperation, advice and mentoring that I've obtained from my fellow AC members as well as a number of trustees and ARIN staff throughout my first term.  I greatly value the friendships that have developed. 

There's a lot more that I'd like to do.  I am, of course, interested in working on whatever community priorities come up in the next three years. 

Some of the issues that seem to be of particular significance these days are improving the usefulness of the registration databases, any additional refinement of transfer policies that may be needed, the promotion of IPv6 adoption, and continued NRPM simplification.

For all these reasons, I hope you'll vote for me in this election.  Thank you. 

(Applause.)

John Curran:  And the last candidate for ARIN Advisory Council, Alicia Trotman.  I believe we have a video. 

Alicia Trotman (via video):  Hello, everyone.  My name is Alicia Trotman from the beautiful island of Barbados.  I'm a telecommunications officer and a civil society activist. 

I started my career approximately 15 years ago at a telecommunications unit where I dealt with the legalization of telecommunications sector.  I then moved on to the technical team at AT&T Wireless before I rejoined a regulator. 

Having worked for a small regulator, I've been involved in all aspects of the industry, which include special management, ccTLD administration, the establishment of a CERT and Internet exchange point, IPv4 to IPv6 transitioning, and cybersecurity quality development. 

Within our department, we've also started a campaign to ensure all service providers are IPv6 compliant.  I'm also a founding member of the Caribbean testing board, which is an International Software Testing Qualifications Board-approved regional testing board for the Caribbean. 

In addition to my professional work, I am heavily involved in civil society working with victims of online abuse and harassment and educating parents and children about cyber security and online child protection. 

I'm a founding member of the charity NOAH NO! To Online Abuse and Harassment, which currently won an Internet Society grant and are currently working with the UN committee to quantify and find solutions for the issues of online abuse. 

I have spearheaded a national girls and ICT day initiative through the creation of career days, workshops, and hack-a-thons. 

I'm also a member of the Internet Society Barbados chapter and serve on the planning committee for the Barbados inaugural Internet Governance Forum. 

What I bring to the table is not only a body of knowledge, but a passion and a fire that are unique in me.  I've attended two ARIN events.  The more recent one being ARIN 31, right here in Barbados.  I've also admired the dedication and the commitment of the ARIN team to facilitate an open and transparent policy development process. 

This has influenced my professional approach, and it would be an honor and a privilege to be a part of this process. 

One thing which is evident is a lack of Caribbean representation in the ARIN branches.  I have heeded the call.  We are here.  We are ready to work, but we need your vote to make it a reality.  Thank you. 

(Applause.)

John Curran:  Alicia's bio is on the website as well.

Now we're going to move into the ARIN Board of Trustees, candidates for the ARIN Board of Trustees. 

The first one is Dan Alexander.  Come on up, Dan. 

Dan Alexander:  Hello, everyone.  So it has been 15 years since I first got involved in ARIN.  ARIN 10, Eugene.  Yeah! 

By that point I had already been a small business owner, manager at a large corporation, managed budgets and P&Ls.  But I'd never been involved in a bottom-up policy organization.  Came in as a complete newcomer, and it was completely interesting to me. 

And this group was extremely welcoming and brought you in, explained how everything worked.  And as I got more familiar with how things were operating, I started to notice how particular policies might be improved.  And I actually authored several changes.

As I became familiar with the Policy Development Process, I wanted to apply some of that experience or return the favor, so I decided to run for the Advisory Council.

I think I've filled my role on the AC pretty well, as I'm now finishing my fifth term.  And as I gained more experience on the AC, I wanted to contribute there as well.  So then I ended up serving as Chair for this past three years. 

As I finish my work on the AC, I'd like to think I will leave it a little better than when I started. 

A big focus as Chair was to focus on improving the group's stability and to continue the work on the succession planning to reduce the fluctuations in the work output as members transition in and out of the Advisory Council. 

So I'd now like to bring my personal experience, my experience with the ARIN organization, the 15 years of community input and the policies that guide this organization, to the Board of Trustees.  I say this not because it's something for me to do, but I think it's a real opportunity where I can leverage my experience and help the work of the Board and its strategic planning. 

So for those who don't know me, I urge you to reach out to some people in the room who do, who have experience with my work, my temperament and how I approach a problem and ask for their input because I feel my personality would be a very good fit on the Board.  So I ask you for your vote and I thank you for your time. 

(Applause.)

John Curran:  Next candidate for the ARIN Board of Trustees, Nancy Carter. 

Nancy Carter:  Hello, everyone.  I'm Nancy Carter, and I'm very excited to have been nominated for the ARIN Board of Trustees.  I want to thank you for the opportunity to present myself today as I'm relatively new to this ARIN community. 

That doesn't mean I'm new to the Internet.  CANARIE, the organization that I work for, helped develop the Internet in Canada and the .CA registry.  And I'm also on the board of the Canada chapter of the Internet Society.  

But back to ARIN.  My first ARIN meeting was in New Orleans where I attended ARIN 39 as a Fellow.  I was inspired with new information, with inclusiveness of the ARIN community and, in particular, with how welcoming you all were. 

When I left New Orleans, I knew I had to get more involved.  As you can tell by looking at the screen and reading my bio, I come from the research and education sector.

I'm very passionate about the Internet.  I love new challenges and have a history of helping organizations adapt to new opportunities and new technologies. 

I have a rare mix of financial and legal experience.  And while I may not be the most technical candidate for the Board of Trustees, I believe my background matches the sweet spot of the role of ARIN, which is to support the operation and growth of the Internet.  I believe that I can add value to the Board of Trustees. 

Twenty years ago I made the transition from the private sector to the not-for-profit space, which was the best decision I ever made. 

What I learned through that transition was that the two sectors gauge their relevance to the communities or markets they serve using fundamentally different measures. 

The private sector uses profit and profit growth.  When that disappears, so does the company. 

The not-for-profit space, in which ARIN and CANARIE operate, strive to do public good, supporting the adoption of the Internet, increasing the utility of the Internet and advancing the digital age.

I hope we agree that measuring profit is considerably more straightforward than measuring relevancy or the impact on public good.  However, that's something that I have 20 years' experience with. 

In the ARIN region, the transition to IPv4 -- or IPv6 is essential after the exhaustion of IPv4.  In Canada, adoption of IPv6 in the higher education sector was led by CANARIE, which, among other things, included an IPv6 testbed as a test and training platform. 

So what's really at stake if we don't spur the adoption of IPv6?  The technology of the Internet is about connecting people and supporting commerce, science and social interaction, to name a few of its uses. 

Requiring workarounds to bridge between the two IP protocols only complicates connectivity as network speeds continue to scale. 

When the rules of the game change, organizations need to adapt or perish through loss of relevancy.  The rules for ARIN changed when we started running out of IPv4 addresses.  And while ARIN has adapted, it needs to continue to adapt. 

CANARIE is almost 25 years old, and during my tenure there, I have been part of a management and governance structure that has allowed CANARIE to adapt and retain relevance through predictable technology changes, from ATM to IP or from 56 kilobits per second to 100 gig, and through less predictable ones -- exhaustion of IPv4 addresses, the use of cloud, social media and so on. 

If you're here today or watching this on video, I like to believe that you are involved with ARIN because you support its purpose and want to ensure its continued value and relevance to society. 

That is what the other candidates and I are here to do as well. 

My not-for-profit financial governance and legal experience will support ARIN's mission, not only today but strengthen its value into the future. 

I hope that I can count on your vote.  I truly look forward to working with the ARIN community.  Thank you. 

(Applause.)

John Curran:  Next candidate for the ARIN Board of Trustees is Leslie Daigle. 

Leslie Daigle:  My name is Leslie Daigle, and that's not how you spell it. 

(Laughter.)

Have to do something when you're the second to last speaker. 

Yes, I'm standing for election for the ARIN Board of Trustees because I think that the RIRs are an important part of the Internet ecosystem, and I believe I have the experience and the skills to contribute to its Board and its leadership.

Not to really bore you with all the bio details that you've probably already read, right, I will point out that my background training actually is as a computer scientist, and I actually got my start with this Internet gig in developing and deploying Internet technology working for a small company in my hometown of Montreal, Canada.  And that little company ran the world's first Internet search engine, Archie, which some of you probably remember. 

So I spent the last 25 years working on Internet technology development and deployment, even as that has spread from actually writing code to management roles to participating in the Internet institutions that form this Internet ecosystem, again, in contribution roles and in leadership and the dreaded Internet governance discussions. 

So just quickly, some highlights from my background and I think that are particularly germane here.  I was actually on the corporate board of directors of Bunyip Information Systems in the late '90s.  That was the small company that ran Archie.  I was appointed to the Internet Architecture Board for eight years and elected its chair for five of those years. 

While I was the IAB chair, I helped lead the IETF through an open dialogue and discussion of its administrative restructuring so that it could get a grasp of its own administrative destiny, which was something it certainly didn't have 15 years ago.

As the first Chief Internet Technology Officer at the Internet Society, I worked with them on the contributions to the various Internet governance discussions at the time, including participating in the ITU SG2 discussions around IPv6 and how you couldn't just hand half of it off to them, as well as the very memorable WCIT meeting, IT WCIT meeting in Dubai, in 2012.  Fun times. 

But even more fun things at the Internet Society, it was my group that was responsible for the World IPv6 Day and the World IPv6 Launch that had a pretty significant impact on IPv6 deployment.  And also my group was responsible for the Internet Society's Deploy360 resource. 

More recently, I was co-Chair of the IETF's IANA PLAN working group which was responsible for developing its response for the IANA transition, which we are all heartily glad is now over and done for over a year -- not just the working group but the transition. 

Currently I am chair of the IETF's IOC, the IETF Oversight Committee, which is the oversight -- the administrative oversight body there.  And my term ends in March 2018. 

I'm currently independently employed and happy to talk to anybody about routing security or network operator measurements. 

But for -- for -- enough about me, let's talk about you for a while.  I think from my perspective, the need for open, community-driven, publicly developed policy is not in any way reduced as the Internet matures but rather becomes more and more vital. 

And I think that one of the challenges for all RIRs going forward is going to be to remain viable and relevant and viable in particular between the dual challenges of the different allocation model and frequency of IPv6 and the intensifying crush to try to obtain and/or manage IPv4 even though it has run out. 

I think those are clearly the tussles facing the organization both materially and functionally for the years to come. 

With the IANA transition behind us, surprisingly the Internet has not fallen apart, much to the amazement of some, I'm sure.  No one in this room. 

But we do need to not lose site of the fact that we need to keep our eye on the global dialogue and global engagement of all parties interested in the stewardship of Internet resources, including the numbers that ARIN manages.  And we need to stay involved in those dialogues so that we can ensure that the Internet continues to be run based on collaborative, open, consensus-based policy development.

So central to all that is healthy organizations, and healthy organizations are driven by well-functioning boards.  So I believe I have the skills and the experience to contribute to the ARIN Board in its leadership of this organization, and I'd like to spend the next few years doing that. 

So with that, thank you very much for your time, and I'd certainly appreciate your vote.  Thanks. 

(Applause.)

John Curran:  The fourth candidate for the ARIN Board of Trustees, Stephen Lee. 

Stephen Lee:  Good afternoon, everyone.  Thank you.  Appreciate the opportunity to run for the ARIN Board of Trustees. 

Just some quick background:  My name is Stephen Lee.  I was born in Jamaica, currently live in Fort Lauderdale, Florida; went to university in Trinidad.  And so my whole background growing up was in the Caribbean region.

But for the last 20 years I've been living in Florida running a technology firm which I co-founded, which is called ArkiTechs, Inc., a firm focusing on both network infrastructure and software development.

We basically have over -- the phase of the services are directed towards developing communities, developing nations.  So we do a lot of work inside of the Caribbean region.  A lot of our customers are inside of the Caribbean region.

And that is the portal to which I became involved in the Caribbean Network Operators group in 2007. 

I was one of the founding members working alongside, well, ARIN's own Bevil Wooding and the Caribbean Telecommunications Union, which at that time was getting a lot more involved in strengthening ICT capacity in the Caribbean region. 

The network operators group similar to NANOG was created around that time and basically started to build a technical community.  And I was one of those who was involved in that. 

Now, interestingly, a relationship with ARIN itself goes back all the way to 2007.  This would be my own tenth-year anniversary of relationship with ARIN. 

First meeting was ARIN 20 in Albuquerque.  And since then I've had the occasion to collaborate with and work alongside the ARIN community; some policy development, but more so in ARIN's own strengthening of ICT and Internet groups in the Caribbean. 

Even though we don't have -- there's not a great Caribbean presence in ARIN itself, that is not to say that ARIN has not been very, very involved in the Caribbean. 

And certainly, from this standpoint of CaribNOG, I can attest that ARIN has been one of the strongest supporters and backers of CaribNOG.  This is in terms of technical training, lending resources, trainers from ARIN staff actually participating in CaribNOG. 

And that whole experience has given me an opportunity to see how the organization works; to appreciate the process that ARIN has.  A lot of integrity and transparency in the process itself of how policies are developed. 

And ARIN does have this very distinct and very clear care for the region that it serves.

So part of my running for the Board is both to take the issues which are pertinent to the networks in the Caribbean and give them greater visibility to ARIN as a community, as an organization, but also to serve and give back to the whole community as ARIN has certainly contributed right into the Caribbean.

Just wanted to highlight one thing which I think is very important for the ARIN community.  As the Internet grows, just the profile and scope of the community is changing.  And that voice of some of the smaller networks, this morning we're talking about community networks, the smaller networks on some operators don't have some of the same concerns. 

We're here in Silicon Valley, and we're talking about IPv6 and transfer markets and how to get v4 addresses at the opposite end of the spectrum in the Caribbean; you have very small networks which have just been hit by a set of hurricanes in which infrastructure is almost nonexistent and it has to be built all the way back up.

So all of that falls within ARIN's concern for support in the growth and development of the Internet. 

And those are some of the things that we definitely want to encourage and see ARIN continue to contribute very strongly to going forward.

Thanks for the opportunity.  And I'd appreciate your vote. 

(Applause.) 

John Curran:  Thank you, Stephen Lee. 

So at this time the polls open at 3:00.  So in 20 minutes vote.  Or actually even 10 minutes.  We're getting there. 

All of the candidate bios are online.  All the candidate Statements of Support, statements from members of the community expressing their recommendations for these candidates are online.  You can make a Statement of Support yourself. 

If there's a candidate you feel is particularly strong for the Board or AC, I recommend you go in, read what's there, add a Statement of Support as well.

That will help others in assessing the candidates and trying to decide who they're voting for.  At this time we could get you out to break 15 minutes early, but we never do that. 

So, instead, I'm going to bring a presentation up.  Susan, could you give an update on ARIN on the Road. 

Update - ARIN on the Road

Susan Hamlin:  Hello again.  I'm really happy to spend a few minutes talking about an ARIN program I'm very passionate about, and that is ARIN on the Road:  Bringing you answers. 

So this program began in 2010.  And it was an idea we talked about, many of us on staff, of how we could reach out to the community, especially areas where we don't take a Public Policy and Members Meeting.  So to smaller cities and towns where we know there's a group of customers or a community. 

So we put this together, and basically it's a one-day program, high-level introduction to ARIN services, ARIN activities. 

And it really puts ARIN staff -- elected representatives, we bring a member of the Board of Trustees and Advisory Council with us -- it puts our faces out in the community. 

We give folks an introduction to the Policy Development Process.  And our goal is really twofold -- to get community feedback on how we're doing, what we're doing, and to foster their greater engagement with ARIN, be it a subscription to a Mailing List or their remote participation at a meeting or even applying for a Fellowship Program. 

So this is a look of where we've been since 2010, split out between Canada, the Caribbean, United States, and the number of attendees we've had totally cumulative each year at the meeting.

So if you look at the bottom, we've reached quite a few members.  And I have to say, for the most part, folks have been very pleased and sometimes very surprised when we showed up in their community. 

This is a look at the typical agenda we've been delivering recently.  Again, it's a smattering of pretty much everything we do.  We allow plenty of time for Q&A. 

We have our own Open Mic at the end, and that's where we direct all those tough questions to the Board member with us. 

And then ARIN staff, we bring someone from engineering, someone from Registration Services, and we sort of have a mini help desk at the end of the day, if people have specific questions for those departments. 

Program results:  We don't have exact numbers.  But I do know for a fact that we have had attendees apply for fellowships. 

Some of those Fellows have gone on to serve on the ARIN Advisory Council.  We have seen folks subscribe to the ARIN Mailing List after these meetings.  They become participants and remote participants. 

And we have been able to put people with questions at these events in touch with members of the Registration Services Department to get their problems solved.  And that starts a dialogue.

We encourage people to use the help desk and introduce them to ways that they can provide feedback such as the ones Richard talked about yesterday at Newcomers. 

Takeaways for all of you all, because we are currently planning our ARIN on the Road programs for next year. 

So it is a free, one-day program.  Lunch is included.  We're happy to customize an agenda.  So if you're in an area where you think we should come and there's a particular interest or another organization that's having a program, we're happy to tailor the agenda, do a half-day ARIN on the Road to mesh with another program.  We're very flexible. 

And so, really, if you have any thoughts or have an interest in ARIN coming to your community, if you'd reach out to me or meetings@arin.net, we're busily planning 2018. 

Any questions? 

Kevin Blumberg:  Kevin Blumberg, The Wire.  I've attended a number of the ARIN on the Roads.  They're wonderful.  But they're also very expensive for 25 or 30 people. 

A suggestion.  I'm not saying stop them or anything like that, but a suggestion is:  Come up with a micro ARIN on the Road where you can send one person to a smaller city, because you're now going to some of the smaller towns, one person to work in a smaller environment with a more micro type of thing, get them out to those smaller cities, because the amount of money that you're spending on an ARIN on the Road really needs to have more people come to it. 

And at the same time I do want you to be in the smaller communities.  So maybe having an A and B kind of ARIN on the Road might be beneficial.

Susan Hamlin:  That's a good suggestion.

John Curran:  Excellent.  Any other questions for Susan? 

Rudi Daniel:  Rudi Daniel, Caribbean.  Susan, perhaps you could go back to the slide where you had the numbers of ARIN on the Road. 

That's it.  Good.  ARIN is Canada, United States, Caribbean, and the North Atlantic Islands.  So do you ever hold ARIN on the Road in North Atlantic Islands? 

John Curran:  Which --

Rudi Daniel:  I know the region is Canada, United States, the Caribbean.

John Curran:  About half the Caribbean.  Not all, but half of it.

Rudi Daniel:  There's some other islands somewhere --

Susan Hamlin:  Minor outlying --

Susan Hamlin:  We have not been there.

John Curran:  We have not been there yet.

Rudy Daniel:  That's what I wanted to ask. 

Second thing is regarding the IPv6 demonstrations, or IPv6 in a box, or whatever you want to call it:  In the Caribbean, we have something called the ICT Roadshow, which is run by the CTU currently. 

And it would be nice, actually, if we could incorporate at some point maybe one or two of them, IPv6 demonstrations or in a box.

John Curran:  Happy to do so.  We've been working with the CTU on the recently rescheduled one.  I'll be speaking down there.  But if they'd like to have more technical content as part of it, we're happy to do so.

Rudy Daniel:  I'll suggest that, too.

John Curran:  Suggest that to Bernadette and the team, and we're quite willing to bring it to any event that wants it.

Rudi Daniel:  The thing is, although we're very small, and we're not contributing as much as we could do, the fact of the matter is there are any new networks that emerge out of the Caribbean are probably going to be IPv6.

John Curran:  Thank you.  Very good.  Any other questions for Susan? 

(No response.)

Okay.  Thank you, Susan. 

(Applause.)

John Curran:  I've given in to peer pressure.  You are going to have a break longer than 30 minutes.  I will see you back here at 3:30, promptly.  We have policy sessions after that.  3:30.  Thank you. 

(Break from 2:53 PM to 3:30 PM)

John Curran:  Welcome back to our ARIN 40 meeting.  We have some more work to do this afternoon.  I'd like to start out with our Draft Policy block. 

ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

All of the policies we're talking about are in your Discussion Guide.  Additionally, in your Discussion Guide is the Policy Development Process and the current version of the Number Resource Policy Manual, NRPM. 

So the text that's being changed by the draft policies are in here, as well as the process for changing it. 

So the first policy up is Draft Policy 2017-4:  Remove Reciprocity Requirement for Inter-RIR Transfers. 

Rob Seastrom is the AC member.  Come on up.

Rob Seastrom:  2017-4.  AFRINIC and APNIC -- I'm sorry, AFRINIC and LACNIC are considering one-way inter-RIR transfer policies. 

AFRINIC reached out to ARIN staff and asked, hey, will 8.4 policy language allow this to work?  And the answer was no. 

So there's some concerns that we have overall, which is ARIN should recognize other RIR operators have different needs and different requirements in their region than we do. 

And AFRINIC and LACNIC operators have a need to acquire space.  They have reasons that they think are important to not allow two-way transfers.  And they have orders of magnitude less space than we have here in the ARIN region.

So the policy statement is add the following sentence after the first sentence of NRPM 8.4:  Inter-RIR transfers may take place to an RIR with a nonreciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average, the arithmetic mean, of the IPv4 total inventory among all of the RIRs. 

So who is that?  Well, did the math.  And if you take a look, it turns out that LACNIC and AFRINIC are the two RIRs that have less than the average amount of addresses. 

We sent this to ARIN staff and legal for comment.  ARIN staff says consider changing the word "remove," that's good feedback, and the way that they will implement it is that quarterly they will compute the average of the total inventory and post that online. 

This policy would be implemented to work only with RIRs that have a unidirectional compatible needs-based inter-RIR transfer policy.  To eliminate any possible confusion, they recommended that with a nonreciprocal inter-RIR transfer policy, which is kind of cumbersome, would be better phrased as "Unidirectional compatible needs-based inter-RIR transfer policy." 

They sent us more comments:  A corollary recommendation is to change 8.4 of the NRPM so that "reciprocal" is changed to "bidirectional," because that word has been a point of confusion in the past. 

The most interesting piece of feedback that they provided, that the staff provided to the AC, is that, for all intents and purposes, we have a unidirectional transfer policy now, because the preponderance of the addresses that are available for transfer, those being old legacy addresses and addresses that have become on the market, are in fact in the US and in Canada, and perhaps, to a smaller degree, other places in the ARIN region. 

But the amount of address space transferring in to the ARIN region from RIRs with a bidirectional transfer policy is actually very, very small. 

Counsel says they want to make sure that removing "reciprocal" does not remove "compatible" and "needs-based," and that that's legally critical. 

So we have not yet applied the most recent iteration of staff and legal feedback to the text that is in our wiki or to the text that we are presenting here. 

We're going to get feedback from the community here at the microphones momentarily and add that in when we make our next iteration of changes, which will, of course, require one more round of staff and legal review. 

Microphones, please. 

Paul Andersen:  Microphones are open.  I know always after lunch it's slow getting going.

Matt Petach:  Matt Petach, Yahoo.  Just a tiny question about this.  Does the transfer text limit itself to IPv4 transfers only, or is it open for any kind of transfer? 

Rob Seastrom:  Do you want to answer that? 

John Curran:  No. 

Paul Andersen:  I invited you to.

Rob Seastrom:  So you caught me unaware that I think that as a practical matter, v6 transfers are not a thing.

John Curran:  If you look in NRPM, in Section 8, NRPM Section 8, Principles, in the specified transfer policy, it specifies that there's a minimum transfer size for IPv4.  It doesn't reference IPv6. 

But I think it's fairly safe to say that we haven't seen policy from the community that discusses the implications of transfers for v6.  8.3 specifically says IPv4 Number Resources and ASNs. 

Paul Andersen:  To be clear, specified transfers, I believe M&A transfers would probably occur. 

John Curran:  Right.  We have not had -- the community discussed IPv6 transfers.  So until we've actually had that, we're not interpreting it that way. 

Matt Petach:  Same thing for ASNs in 8.3, you can transfer ASNs, but we'd like to change this so it's based on just the v4 ratio regardless of the type of resource being transferred.

John Curran:  It can be whichever you want it to be when you clarify the policy text accordingly.

Matt Petach:  I would request that if we're going to make the ratio based on the IPv4 inventory versus average, that we limit this to just IPv4 Number Resource transfers.

John Curran:  Certainly one option.  Or you can make it for all transfers in and out of the region. 

Matt Petach:  I'm talking to the author there on the stage and asking him. 

Paul Andersen:  Shepherd. 

Rob Seastrom:  I'm not the author. 

That's an interesting clarifying point, and we'll take that under advisement.  Thank you. 

Matt Petach:  Otherwise I support it. 

Paul Andersen:  Thank you for the supportive comment.

John Curran:  Because this is specific to inter-RIR, an inter-RIR specifies the source has to be the rights holder of the IPv4 block in question. 

We don't presently have inter-RIR AS transfers under 8.4.  There's a theoretical way to accomplish them with merger/acquisition.  But I don't think that's what this policy is intended to do.  So this policy may only be applicable to v4 anyway. 

Paul Andersen:  Far microphone. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  I support the spirit of this policy.  All of the suggestions that staff and legal and everything else that's being brought up seems valid. 

I would love to see the final text.  But the whole purpose of this is to be globally fair.  And it addresses a real issue not in our region.  This is not about our region, but it's about being globally fair. 

As the numbers have shown, nothing is really coming back into the region.  It's not a big deal in that respect.  If there's a major change, that would be dealt with later on, but we need to address this in our side first before some of the other regions that this is of relevance to can make their policy.  So I do support it with whatever is written, whatever is needed.

Can you just clarify from the first slide in terms of numbers, if you can just go back to that.  Yep. 

This policy is really addressing LACNIC and AFRINIC, correct?  Would it also apply to RIPE and APNIC, or when would it apply to RIPE and APNIC? 

Rob Seastrom:  I'm not able to do the math in my head.  But --

John Sweeting:  John Sweeting with ARIN.  It would basically take RIPE to lose an equivalent of eight /8s to get down to the average.  Eight /8s. 

The equivalent of that much space would have to leave the RIPE region for them to get below --

Rob Seastrom:  They would all have to be going to APNIC and --

John Sweeting:  They could go anywhere because the average will always stay the same. 

Rob Seastrom:  That's true.  We're not making any more, are we? 

Paul Andersen:  We only wish. 

Kevin Blumberg:  They're making new ones, but they're not compatible. 

Paul Andersen:  It's called v6. 

New point.  Quickly, though. 

Kevin Blumberg:  Where I was going with this, though, is if one of the regions did not qualify in this policy, would lose eight /8s as an example, then us sending the IPs into their region would be very appropriate as well.  So I definitely support the way this has been done. 

Paul Andersen:  Thank you.  Center microphone. 

Owen DeLong:  Owen DeLong, Akamai, ARIN AC.  I opposed this policy before we did funny math to try to make it more palatable.  And I oppose it even more with the funny math. 

The reality is that the funny math does not make it any more palatable.  It simply does a lot of sleight of hand in an Enron-style gesture to confuse the community. 

It's the kind of policy authorship that Andy Fastow would be proud of. 

If you want to restrict it to LACNIC and AFRINIC, do that, say that in the policy.  Coming up with this formula by which for the next 386 years it's only AFRINIC and LACNIC, unless something changes drastically from the way things are today, is just silliness.  It's absurd.  It's like constructing special-purpose entities. 

So let's not do that.  Let's say what we mean in the policy.  And if the community supports that, let's move forward with that.  But let's avoid mathematical sleight of hand as a way to achieve policy goals that we don't want to admit are the policy goals.

Paul Andersen:  But if it was to implement your suggestion to name the RIRs, would you be supportive, or still not? 

Owen DeLong:  No.  Because I think we should actually implement fair policy, which is bidirectional. 

The community spent a lot of time discussing whether or not there should be a reciprocity requirement.  We said yes, and we put it in, and it's there for a reason.

Rob Seastrom:  Not withstanding the fact at implementation we effectively have a unidirectional transfer policy today? 

Owen DeLong:  Well, we have a policy which allows and is fair, and the fact that it happens to be, in implementation, largely unidirectional, is not an unexpected circumstance.

But if somebody wants to transfer resources in the other direction, they can.  Those transfers are occurring. 

And I think that if anything -- if nothing, that fact in and of itself is the best argument that this policy is unnecessary, and LACNIC and AFRINIC need not fear the exodus of addresses from their region towards ARIN. 

Paul Andersen:  Moving on.  Center microphone -- sorry, John Springer, do we have any remote participation? 

John Springer:  Remote comment.  Marla Azinger from Frontier:  While I understand the concern, I don't agree with nonreciprocal.  I think AFRINIC and LACNIC need to modify their policy to say "only address space directly allocated to the registry for dissemination can't be transferred out," but it should not block space not originally from that RIR from being transferred from back out. 

Paul Andersen:  I'm rapidly losing queues at the mic.  If you'd like to approach, please do so quickly. 

Center microphone, please.

Remco van Mook:  Remco van Mook, speaking as a private individual.  I don't have much opinion about this policy.  However, I'd like to make an observation and have a follow-on question to this community. 

The current version of the inter-RIR transfer policy as it stands within ARIN has certainly informed policy discussion in a number of regions, other than this one, resulting in compatible inter-RIR transfer policy. 

My question:  Why would you change that at this point?  Don't you think that keeping the policy as it stands actually helps discussion in those other regions? 

Paul Andersen:  If anybody would like to address that, approach the mic. 

Far microphone.  That's you. 

Paul Wilson:  Paul Wilson from APNIC.  As you probably know, APNIC has got a system of National Internet Registries, NIRs, that operate like a Regional Internet Registry at a national level. 

They have policies which have to be consistent with, but which may vary in nonsubstantial ways from the regional and global policies.  And this is one case where we also have variations. 

So we have two NIRs that allow transfers in but not transfers out, and I think that's for the same reasons I suspect as you've observed AfriNIC and LACNIC have got a similar situation.  So I haven't done the math, but I think in both those cases we'd find that they had a lower than average IPv4 penetration. 

So they may well be as deserving at a national level of this policy as you feel the two regions are. 

So I'd ask you, if this policy is going forward in further development to implementation, that you might like to or be able to consider this particular case that there are National Internet Registries for which the same conditions and possibly the same concessions should apply. 

Thank you. 

Paul Andersen:  Thank you for that.  That's wonderful. 

Middle microphone. 

David Huberman:  David Huberman, Oracle, ARIN Advisory Council.  We have five RIRs.  We don't have one.  We could have one, especially when we're talking about -- if we're just going to talk about IPv4, we could totally just have one registry, right?  Let's get the numbers where they're not needed to the operators who need them.

One RIR could handle that just fine.  But we actually have five RIRs, and we figured out as an Internet community that's actually really useful. 

It's useful for local cultures.  It's useful for local languages.  It's useful for local time zones.  It's useful for local law. 

It's very arrogant to say this is what we think as Americans, Canadians, as Jamaicans, whoever we are in this region, this is the way everyone in the world should be when it comes to transfers of numbers that they need. 

There are good reasons that you may or may not agree with, but some people do agree with, why AFRINIC does not want two-way transfers.  There are reasons that the LACNIC community does not want two-way transfers. 

And, by the way, Owen has asked me to point out, and it's a very good point, neither LACNIC nor AFRINIC have passed any policy, nor have they reached any consensus on any policy on unidirectional or bidirectional policies.  It's simply in discussion.

Let's get the IP addresses from where they are, which is predominantly in the ARIN region.  Talk to the brokers here.  Talk to the people who do this every single day.  The addresses are here that are for sale.

Let us allow them to move where they are to operators who are doing the same things we are doing, where they need to be. 

Paul Andersen:  So, Dave, you're supportive of the policy?  I'd like to get that -- checking remote participation quickly.  No?  We're up to date. 

Far microphone.

Alain Durand:  Alain Durand from ICANN, speaking on my own capacity.  I've been to previous meetings in LACNIC just a couple of weeks ago and to AFRINIC not that long ago, where unidirectional transfer policy was discussed. 

And to add in the direction that my colleague, David Huberman, was mentioning, there have been some discussion, fairly heated discussion, I should say.  But no policy was able to be passed in either of those regions.  And somehow interested to see what will happen here.

Paul Andersen:  Thank you for the comment. 

The microphones are rapidly emptying in queue.  If we don't see someone approach the microphone by the end of this speaker, we'll close the microphones. 

So far microphone.

Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  I got in line, but I think I'll change a lot of my comments to what Dave Huberman said.  I had a lot of the same opinions.

One thing to point out is that there are -- if anyone is concerned about why hasn't LACNIC or AFRINIC agreed to have an outbound transfer or reciprocal policy, I wanted to remind everybody that there have been, in the past, loopholes in the RIR transfer process that have been used in ways not intended. 

Those loopholes eventually, right now, have been closed.  I'm thinking primarily about RIPE's hold time for transfers. 

So people can voice that they have a real concern about losing their address space or being used as a conduit in that way. 

Paul Andersen:  Thank you for the comment. 

Far microphone, again, please. 

Dmitry Kohmanyuk:  Dmitry Kohmanyuk, Intuix, ARIN Member.  I'm also participating in RIPE region meeting so this is a good comment. 

I think if you treat RIRs as governments and we try to enact laws and try to kind of segment the space, we would ultimately end up just making things harder for people who really need the space and the ways around it would also be found. 

Another thing, that all this quarterly tactic and our policy evaluation can lead to lots of current cases, which would just be basically broad (indiscernible).  So I think we should not impose our will on other registries' rules and spending resources.  According to this triple conditions to be met as proposed in this policy. 

So I think it should be either registered agreement with everyone, just like two companies can have it to get analog, or just keep things the way they are and don't try to invent these formulas and have this feedback loop of other policies and other policies because it just doesn't feel right. 

I oppose this proposal.  Thank you. 

Paul Andersen:  Thank you.  Before we go to John, who I can see, just if you would start approaching a microphone immediately, I'll be closing the microphones at the end of John's comment. 

John Curran:  Last speaker, were they in favor or opposed? 

Paul Andersen:  I thought he said in favor. 

John Curran:  In favor --

Paul Andersen:  Could the gentleman clarify? 

Dmitry Kohmanyuk:  No, I don't think this proposal is good.  Opposed. 

Paul Andersen:  I thought I heard in favor.  My apologies. 

Opposed. 

Okay.  Microphones are now closed.  We'll go to our last two comments, starting at the middle and then the far. 

Owen DeLong:  Owen DeLong, Akamai, ARIN AC.  We keep talking as if LACNIC and AFRINIC want a unidirectional policy in this process, and yet the heated discussions that I was present for in both of those RIR meetings, much of the heat came from people who didn't want a unidirectional policy and felt that if there was going to be an inter-RIR transfer policy, it should be bidirectional. 

So there is no consensus in any region that a unidirectional policy is desirable.  And so I do not understand the perceived need to create one or create the allowance for one here at this time.

Paul Andersen:  I assume still opposed. 

Final comment from the far microphone. 

Jason Schiller:  Jason Schiller, Google, ASO AC.  Opposed.  I don't think the mathematics in this policy makes a lot of sense.  It looks like hand waving.  And specifically the comments that we heard from Paul Wilson about the situation with a number of NIRs. 

I know for my company, if we wanted to be able to leverage a policy like this, the place we'd likely do it would be actually in the APNIC region, to be honest. 

My concern, however, is the possibility that we could get addresses wedged somewhere.  If I imagine we take some of our inventory of addresses and move them into a country where we think we want to do business and then it turns out that our business needs change, we might not be able to get those addresses back out of that NIR and use them in other places easily. 

And that seems problematic to me because now I've taken addresses that have a certain dollar value associated with them, put them in a place where they're not useful to me and a place, where, if there's not need, they're not valuable anymore, and have to go to the market to replace them at a much higher price. 

So it seems to me that the people that advocate supporting this policy want the free flow of addresses.  And the people that are opposed to this policy want the free flow of addresses.

And this seems to be an untenable position to have.  My advice going forward with this is take the math out or, if you want to have useful math, you should have it based on what's available in that lookout, because just based on the holdings I don't think it makes sense.

It's really a measure of need that I think you're trying to get at. 

Paul Andersen:  Thank you for that final comment.  We have one final remote participant. 

John Springer:  Just a comment myself.  On this slide I think you can lose the millions and billions because the numbers speak for themselves.

Paul Andersen:  Thanks for the suggestion.  Anything further?  Thanks, Rob, for the presentation. 

We do not have a poll on this one, but I would encourage you to find the shepherds, Rob Seastrom and Joe Provo, or your local AC member at the break or the social, if you have comments or feedback on that. 

John. 

John Curran:  Round of applause for RS's presentation. 

(Applause.)

John Curran:  Okay.  Next policy proposal up, Draft Policy ARIN 2017-6:  Improve Reciprocity Requirements for Inter-RIR Transfers.  Alison Wood is the AC presenter. 

ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers

Alison Wood:  Hello, I'm Alison Wood, the AC.  This is Draft Policy 2017-6:  Improve Reciprocity Requirement for Inter-RIR Transfers. 

The current policy states that inter-RIR transfers be reciprocal.  A loophole in that policy is that the RIRs which had NIRs or a two-hop process can circumvent that requirement.  And we heard a little bit about that in the previous conversation.

So the policy statement will add conditions to 8.4, that the recipient RIR must not permit transfers to other RIRs or National Internet Registries whose policies do not support bidirectional transfers. 

All right.  So we sent this off to legal.  And the first two parts of the review are already in the NRPM.  So we're good there. 

But the third one states that the RIR must have an active policy that prevents them from conducting transfers with other RIRs and NIRs that do not themselves have a bidirectional policy that allows for inter-RIR transfers. 

So that would be a new addition to the NRPM. 

And currently we do allow inter-RIR transfers to APNIC and RIPE NCC.  So if we do implement this policy, we would no longer allow inter-RIR transfers to APNIC or RIPE NCC. 

All right.  So that's very important.  That's a very important part of this presentation is that the implementation of this policy, we would no longer be able to do inter-RIR transfers to those RIRs.  All right. 

So do you support this policy as written?  If not, are there any changes that you would suggest to implement this policy as written?  And do you have any other questions or concerns? 

Paul Andersen:  Thank you.  Microphones are open.  You can hold onto that. 

We're getting to the last policy of the day.  I know you're getting tired, but a little more interaction.  Please approach the microphone, give it a second or two. 

Stephen Ryan:  Could you put up the legal concerns so they're up.

Paul Andersen:  Absolutely, Alison will happily put that up.

Alison Wood:  There's two pages. 

Stephen Ryan:  Put it up and people --

Paul Andersen:  Far microphone.

Chris Woodfield:  Chris Woodfield, Salesforce, ARIN AC.  Unless I'm missing something, this policy would result in no possible RIR transfer, inter-RIR transfer from ARIN to any other region until the other RIRs changed their policies. 

Am I reading this correctly? 

Alison Wood:  That is correct, Chris. 

Paul Andersen:  For or against or you just wanted that as a clarity? 

Chris Woodfield:  Against.  Based on that clarification. 

Paul Andersen:  Okay.  Middle microphone. 

Owen DeLong:  Owen DeLong, Akamai, ARIN AC and author of the policy.  The genesis of this policy was that a number of people approached me about the, quote/unquote, hypocrisy of ARIN allowing transfers to places that allow unidirectional transfers and then standing up and saying "but we don't allow unidirectional transfers."

And I said, well, yeah, the community should probably have a discussion about that.  So I put in the policy.  

Now that we've had the discussion on the Mailing List, and everybody hates it, and I'm not overly fond of it myself, I think it's time to kill this.  And so I encourage you to encourage the AC to abandon this proposal. 

Paul Andersen:  So you are against this proposal. 

(Laughter.)

Paul Andersen:  That you wrote.  Yes.  All right.  With that, far microphone.  Do you want to follow that? 

Kevin Blumberg:  Kevin Blumberg, The Wire.  I'm going to agree with Owen.  Yes, I would like to see this policy abandoned. 

There's nothing in it that I support.  There's one key point that really, really worries me -- well, there's two, actually. 

One, the idea that there could be a six-, 12-, 18-month window where there is absolutely no transfers between APNIC, RIPE, and ARIN is not acceptable in any way, shape or form. 

The second part to this is we've had further discussions where -- on other topics where ARIN signs an RSA with a party; they have that relationship.  Their customers are not part of that relationship.  And this delves deeply into the inter-RIR policy today is between us and the other RIRs. 

And when we start forcing requirements of what those RIRs are doing beyond that relationship, it gets very murky.  And we should not be doing that.  Thank you. 

Paul Andersen:  Thank you. 

Middle microphone. 

Cathy Aronson:  Cathy Aronson.  I just wanted to -- so that it could happen more than once in a policy discussion, I agree with Owen. 

(Laughter.)

And I think this just needs to go away.  But I thought:  When are we going to have the chance for a bunch of us to say it?  Anyway. 

(Laughter.)

Paul Andersen:  Would anyone -- I would encourage, if you're in favor of this proposal, to approach a mic because we'd like to hear both sides. 

But far microphone. 

Wael Taher:  Wael Taher from Maxtel Holdings.  And I'm totally opposing this because it's restricting the movement of IPv4 between ARIN and anywhere else. 

Paul Andersen:  Opposed. 

Next microphone. 

Rudi Daniel:  On the PPML, I actually supported this policy.  But having listened to the clarification on the issue about APNIC and RIPE, I definitely do not support it. 

Paul Andersen:  Thank you.  I'm out of microphone speakers.  If you don't approach a microphone quickly, we'll close the microphones.  We'll close the microphones at the end of John, once again. 

John Curran:  Just to be clear.  Kevin Blumberg and the prior speaker both asked:  This would effectively shut down transfers. 

To be clear, it would shut down transfers from ARIN.  We would still have the ability to have transfers into ARIN the way these policies are written. 

Paul Andersen:  I'm not sure -- I want to be neutral, but I don't think that's going to change their opinion on the proposal. 

(Laughter.)

Any remote participation?  Closing the microphones at the end of Jason's comments. 

Jason Schiller:  Jason Schiller, Google.  I don't support this.  But if we did want to move forward with something like this, we could certainly delay the implementation. 

It's certainly going to take six months for the implementation to happen here, we could push it out further to give other regions time to adjust their policies.  That being said, I'm not advocating for this proposal.  I think really this is a state sovereignty issue, and it's really about countries that are requiring IP space to be used with ISPs run by those state interests, being held by a certain registry. 

I think that's really the issue here; it's not whether we can transfer space in and out.

And I don't really think there's much space for ARIN to play in terms of signing treaties with other states or asking US and Canada and various Caribbean countries to sign treaties with other countries.

It seems pretty ridiculous.  I wish we didn't have a loophole.  I wish we couldn't get addresses wedged in places, and I'd like to see less of this.  I just don't know how we can make that feasible in policy.

Paul Andersen:  Thank you. 

Microphones have closed.  I'll just double-check remote participation, since there's a little bit of delay.  Nothing in remote participation.  Thank you. 

Thank Alison for the presentation. 

(Applause.)

It is true that there's a timetable for implementation.  It's almost immediate, but that is something that could be done, but I'm not advocating it but pointing out that Jason is correct there. 

If you decide that you would like to potentially give some feedback, perhaps you didn't feel comfortable coming saying you're supportive or not, Alison Wood and David Huberman are your people, catch them at the break or during the social tonight. 

With that, that ends our policies for today. 

John, what's next? 

John Curran:  Okay.  We're moving briskly through the schedule, which is good.  Next up we have our Caribbean update. 

Bevil, are you here?  Yes, I see.  As people might be aware, we brought Bevil on to coordinate our Caribbean activities, and he's here to give his update. 

Caribbean Update

Bevil Wooding:  Thanks, John.  Welcome, everyone.  This should be nice and quick.  I want to give you a sense of what has been happening with ARIN in the Caribbean.

I'll start by reminding us that even though the participation from the Caribbean region has been small, it actually covers a number of territories and that in those territories we want to be able to service with even greater care going forward. 

So ARIN is in the Caribbean.  And over the last period of time, the different territories in the region have understood that we exist, that we provide certain services, and that that history has covered a number of strategic partnerships with organizations like CTU. 

Many of you would have heard John, Nate, Susan and others bring reports about the activities ARIN has been conducting in the region.

But in spite of the long history and in spite of the understanding of some of the peculiarities of the Caribbean, there's a recognition that more has to be done. 

And even as a region evolves in terms of its use of networks and its understanding of the requirement to participate in the policymaking process, the outreach has to now become more deliberate. 

And that's what we've been discussing over the last period of time:  How do we move into a greater degree of outreach and participation with our stakeholders in the Caribbean region? 

And so we've identified three areas, and I just want to share those with you in some detail. 

One, raising the profile of ARIN in the region.  This deals with the fundamental question that has been asked by several of the territories with ARIN:  What do you do; how do we get involved? 

And so we want to make sure that over the next period of time we'll be raising that understanding of ARIN across the Caribbean. 

Secondly, expanding the community.  And you would see it with the Fellows who have been coming to ARIN meetings over the last period of time. 

We want to grow the participation of the Caribbean at ARIN policy development, not just in meetings, but on the Mailing List and in the different fora.  That becomes our second priority. 

Thirdly, we want to strengthen and expand our partnerships with organizations like the CTU, like CaribNOG and others that we've been working with. 

There's some institutions who represent an access or portal into the communities that we want to get deeper involvement with. 

So let's break those down and just see what specifically will be happening over the next period of time.  One, increasing awareness of the mission.  Greater direct outreach and support to the technical community. 

ARIN intends to work more closely with CaribNOG to touch the technical community. 

As I indicated earlier, one of the things that's happening is that you have more networks being sprung up in the region. 

And traditionally people have thought the only way to get Number Resources would have been through incumbent telecommunications operators.  We have, Susan and I, in the BVI, just before the storm, where at a breakfast discussion we were talking about the ease with which people can approach ARIN directly. 

And there was genuine surprise that you can come straight to ARIN for number resources and that you did not have to go to the telecom provider. 

And so we wanted to bring greater awareness of those kinds of opportunities for network, those who are building networks and those who are managing networks.

Second is highlighting some of the issues, the policy issues priorities that ARIN has to the Caribbean community and encouraging greater participation in the meetings.  Not just inclusion but also using some of the remote tools and facilities.

At the end of it, what we're hoping to have is greater contribution from the region.  You would have heard several persons indicate that there is a unique perspective that is coming out of the region where you still have nascent networks. 

You still have some issues regarding understanding of possibilities and technical requirements, bringing those people into the discussion process will involve outreach, will involve education, will also involve having them share their needs and their requirements to the wider ARIN community. 

Second issue of growing the support.  One of the areas where the messaging is being developed is encouraging more persons, more organizations in the region to build autonomous records, to get their own resources and to understand how to manage and operate with less dependency on incumbent operators, for example --

Of course, IPv6 deployment, IPv6 adoption, IPv6 utilization is another big priority in terms of engaging the Caribbean community, and we'll be facilitating workshops, training and outreach in this area in the coming months and extending ARIN on the Road to new territories. 

You saw the list.  You see the number of countries, many of whom have not participated in any way in the ARIN process.  We want to reach out to those territories and give them a sense of what services they can avail themselves of. 

As Susan said in her presentation, we're bringing the answers to the communities where they are.  Encouraging sign-up and participation on the Mailing List is another way we hope to support the community in the regions and of course getting more business to sign up. 

I say here Fellowship Program, but also nominate themselves for the Advisory Council and the Board as we go forward. 

And then how do we propose to strengthen the partnerships:  Well, continuing to strengthen our interactions and relationships with the CaribNOG community.  This is an interesting one because CaribNOG itself is in a state of transition. 

The work with the CTU continues, and our work with other Internet organizations in the region, including ARIN, including ISOC, sorry, ICANN, and the new national Internet Governance Forum is one way we see ourselves being able to forge new partnerships in the Caribbean.

And we have some interesting discussions going on now with the organization of Eastern Caribbean States, which is an intergovernmental organization representing 10 territories.  They have their own regulatory structure, and they represent a way for us to now engage governments directly. 

We believe that the governments actually represent a good platform for building out that message around network autonomy, participation in the ARIN policy process. 

So that's where the focus is going to be for the Caribbean in the coming months.  I want to close by giving you a sense of some of the very immediate priorities. 

As many of you know, the region was given a double punch with two Category 5 hurricanes that in some cases literally took out entire countries, took them offline -- cell phones, power, land lines -- all communication knocked out. 

We want to provide support for, and I have been actually working with some of the territories over the last few weeks, with the support of the ARIN organization, to provide that support for the disaster relief and recovery efforts.

One of the things I want to note here is, as tragic as the situation is, many of the countries are still struggling to get back even basic amenities.  As tragic as it is, it also represents an opportunity to reinforce this notion that the region has taken greater care and greater attention to how it builds out critical Internet infrastructure and telecommunications infrastructure. 

We've been working on discussing with those at ARIN, PCH, and others, the possibility of establishing a commission that could look at the history of network resiliency, have it as part of our contribution to the process moving forward. 

The expectation is hurricane seasons are annual.  The expectation is that storms are expected to get stronger.  If attention is not paid to this area, then we would be looking at these kinds of extreme weather events on an ongoing basis. 

So that's what's happening now in collaboration with regional players -- CTU, CaribNOG, and others. 

We also, in the short term, are making a real push to have more Fellows join the ARIN Fellowship process and participate in the meetings. 

The allocation is now five per meeting, and we're hoping we can get good participation across the region. 

Several territories have also indicated a desire to set up remote meeting points to join in the meetings and have groups gather for those who can't attend in person.

Promoting IPv6 adoption I indicated was going to be a priority, and we're developing Caribbean-specific, Caribbean-tailored, I should say, material, to help boost adoption and understanding of v6.

And finally contributing to the regional and national IGFs.  Three territories in the last 12 months have established national IGFs.  And we have been working with them and their members in terms of providing speakers, providing resources and helping support this very important development.

So with this list, I think it's safe to say that the region will be feeling, sensing, and, in a very real way, experiencing ARIN in an even greater way in the coming months.

This is a good thing.  The amount of territories represented in the Caribbean region alone ought to have a greater presence in these fora, and for that to happen the outreach has to be greater and more relevant to the region.

And that's what we intend to do.  The message we have that we've been proclaiming is that ARIN is in the Caribbean.  And for those who don't get it, keep staring at the image. 

(Laughter.)

And you'll figure it out.  But it's a serious message.  And it has so far been accepted by the communities that we have brought this out to. 

The sense that we not just will be coming to conduct meetings, but we'll actually be helping and supporting and encouraging the build-out of networks, infrastructure and so on, in collaboration with those other organizations that have their own missions, is something that is resonating very well in the region, and we hope to emphasize this as we move forward.  Thank you. 

(Applause.)

John Curran:  Any questions for Bevil? 

(No response.)

Thank you.  Okay.  We are still ahead of schedule.  And we will -- you have a question.  Bevil, come on up. 

Rudi Daniel:  Rudi Daniel, Caribbean.  I want to thank you for a great presentation.  It's not really a question. 

I've listened to all of that and I had something else in mind.  I'm thinking like ARIN is probably the only or maybe one of the only RIRs that don't have LIRs.  And I'm wondering if how downline we have North America, we have -- and then we have all these little islands. 

Now, when it comes to policy, it's like the bulk of the policy is going to be centered towards the large entity of the USA and Canada. 

The policy that really relates to and is very helpful towards the smaller items, the Caribbean, the North Atlantic -- and I'm wondering if we could get to a point where we could have an LIR inside of ARIN which will port a great deal of knowledge of policy development and the Internet space to those small countries.

John Curran:  There's nothing in particular that precludes the equivalent of an LIR from being formed.  But there's also not a lot of benefit, necessarily, to be derived. 

Let me talk about this.  Because the -- if you think about how the LIR systems work, NIR systems work at some of the other regions, they operate within a framework of overall policy. 

And so there's not a lot of policy now as there was in the past.  In fact, if anything, there's an aggressive move to simplify policies to make things simpler.

So we're in an era here, where, as someone said, someone got up and said earlier, for v4 we could put it all in one registry.  There's no particular reason it has to be in five, or more than five, if you count the NIRs. 

So it's not clear that there's any benefit or any policy need because policy seems to be a decreasing element, not an increasing element. 

And so we've had policy discussions of needs for community networks.  We had a Caribbean policy in the past.  We've had policies for very particular cases.  We've had a Canada resale, wholesale cable policy, which is a fairly specific policy.  We're quite capable of handling those in the ARIN region. 

If it turns out that there's a desire to have policies specific to the Caribbean, I believe ARIN's capable of handling it.  We have great attendance and participation, and we do do a lot of engagement. 

So I'd recommend that first.  If there's a reason for an NIR structure, that comes with a lot of overhead, and it's actually not clear it has a lot of benefit.  So I would advise looking at that very carefully to see the cost benefit.

Rudi Daniel:  I hadn't really thought it out.  It was a conceptual thought that I had on it.  But there is a need in some of these states to inject knowledge and also knowledge of the multi-stakeholder bottom-up process.  They're not as -- perhaps I should say as free to think as perhaps some of the larger countries. 

So there are elements there.  But I don't know how that balances out.  But as I say, it's something to think about.

John Curran:  Thank you. 

Bevil, any comments? 

Bevil Wooding:  Yeah, I do.  Rudi, that's precisely why the priorities are identified as they are. 

We have to first get to the point where we can gauge a community with an understanding of what ARIN is, what the Public Policy process is like and what their opportunities for engagement are.

And that is going to take time.  Before you get the kind of body of knowledge and awareness of what participation can actually mean, but it's not happening in a vacuum.

The last two weeks with the storms actually creates an even different perspective on what ARIN means for the region in terms of building and supporting and strengthening with resiliency.  So for these things, these messages to get out there, the community has to be engaged as a first step.  And that's exactly what we intend to do. 

Rudi Daniels:  That's great.  I want to say I have a new network rolling out in the next six months in the Caribbean. 

John Curran:  Thank you, Bevil. 

Lee, go ahead. 

Lee Howard:  Lee Howard, Retevia.  This may be starting to get more into Open Mic --

John Curran:  We actually have a presentation in between, but go ahead.

Lee Howard:  I wanted to respond to that point because my initial thought was, ooh, I actually don't like most of the NIRs.  And then I thought about it a little bit more.  As you were saying, it's not worth doing.  I went, yeah, maybe you said it's maybe not worth doing.  I think we ought to explore that further.  That's a conversation worth having.

Arguing, well, gee, we've never needed a separate structure because we haven't had any policy proposals here is kind of arrogant of us to say because we're here. 

To say that we can handle, that we have mechanisms and plenty of participation in order to consider separate policy to the Caribbean, I think, denies the population that's in the room.

We don't have enough representation from the Caribbean.  And having members in the Caribbean who can therefore discuss appropriate policies for them might actually bring better policies to them.  Just because we're running out of policy ideas doesn't mean there aren't new ones required there. 

I'm not yet advocating for it, but I think there are arguments that we ought to listen and think about a little further. 

John Curran:  I want to be clear.  I wasn't advocating against it.  What I was saying was there are cost-tradeoff analysis, and people need to show up and describe what it is that needs to be solved in order to understand that. 

Because we do a lot of outreach in the Caribbean do and end up engaged heavily with, for example, the CTU and their activities and the ICT outreach. 

We actually have a lot of contact, and we have heard the voice saying there's a need for an NIR system down there.  And so it's not that there's a -- it's not that there's necessarily no reason to do it or that it's not a good idea.

It's that it's an idea, but, like most ideas, you start with a problem statement and then you come up with a solution. 

I don't know the problem statement yet.  So people should get together and talk about that and talk to others; and if there's a problem to be solved, and that's a solution for it, that's great.  There may be other solutions.

Lee Howard:  That's what I want to encourage, is further discussion, especially among people who aren't in the room.

John Curran:  Very much so.  Yes. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  I believe that's why Bevil is in the room, A, as an employee of ARIN, but going down, being part of the Caribbean region as a dedicated resource. 

Be careful what you wish for, John.  You were really tempered in what you said.  Be careful what you wish for for NIRs; you're going to add a level of complexity and policy that may not be good for actually improving things.  It may make things worse. 

Yes, by all means.  I think what I heard, though, was two different issues.  The primary function of an NIR is related to policy.  What I heard being discussed was not the policy side of the NIR but the outreach and education and the community portion of the NIR. 

That doesn't need to be formalized.  That has nothing to do with anything.  But from a policy perspective, the NIR in this region, I don't think, would be a good idea.

John Curran:  Understood.  Any further questions for Bevil?

Okay.  Thank you, Bevil. 

(Applause.)

John Curran:  Very good.  We are ahead of schedule.  How nice.  John Sweeting, please come up and do a SWIP analysis, our IPv4 SWIP Analysis Report. 

IPv4 SWIP Analysis

John Sweeting:  I did get trained on the remote.  We're ready to go.  So I'll just leave this up.  A lot of people know what SWIP is, but we added the slide in to level the playing field. 

I don't know, maybe three weeks ago, a month ago, we were asked to provide some statistics to the AC for -- I believe it was maybe 2017-3. 

So we went through doing that, and we provided it.  And they saw it, and they said, wow, this would be some good information to share with the whole community. 

So John asked me to put this slide together, this presentation together, in case we had time to go through this, so that's what I did.  I don't think I need to go through the SWIP slide because you've had time to read it, and most people know what they are. 

So the data that we analyzed was how many networks are actually in Whois?  How many ISPs actually publish SWIP records?  Of those SWIP records that -- how many SWIP records has each ISP that actually publishes SWIP records published?  How many of those actually have annually validated POC validation required, and how many reallocations -- and then next was how many of those are reallocations, and then a slide that we can kind of talk about. 

So the first slide is how many networks are in Whois?  There's a little over 3.1 million total NATs in Whois.  Of those two and a half million are simple reassignments.  Simple reassignments have no POC validation done directly for them.  That's 79 percent of Whois. 

Detailed reassignments, so that's the reassignments that actually have POCs and more information in it, there's 16 percent; reallocations are 3 percent.  And direct allocations and direct assignments from ARIN are 1 percent each. 

So how many ISPs that get direct allocations actually publish SWIPs?  It's basically 50 percent.  50 percent publish SWIPs and the other 50 percent don't have any SWIPs published. 

Okay.  Of those records that each ISP has published, how many -- okay.  This is each ISP, how many SWIPs has each of those ISPs published that have actually published.  There's four ISPs with 100,000-plus SWIPs which is equal to 56 percent of our SWIPs that have been published. 

22 more ISPs that have between 10,000 and 99,999, they actually account for 23 percent.  So between those two categories, 26 ISPs account for 79 percent of the SWIPs in the database.  And then you can see the other data.  It gets a little bit smaller.  14 percent with 1,000 to 10,000 -- 999 -- 9,999; 6 percent with 100 to 999; and 1 percent that actually published between 1 and 99 SWIPs. 

So of those SWIPs that are published, how many actually require annual POC validation.  So this would be all your reallocations and all your detailed reassignments.  Six ISPs that have at least 10,000-plus SWIPs actually account for 66 percent of SWIPs that require annual POC validation. 

There's 30 ISPs between a 1,000, 9,999 SWIPs that are another 19 percent.  And you go down 178 between 100 and 999, so that's 11 percent, and then 4 percent with between 1 and 99. 

So there's actually 36 ISPs that account for 85 percent of the annual POC validation messages, emails that have to go out and the work that's associated with all of this.  But it's interesting that six ISPs account for 66 percent. 

So if you take away the detailed reassignments, and you just do the reallocations, 39 ISPs with 100-plus reallocations are 93 percent of the database. 

When it's broke down, it's actually like eight ISPs account for 80 percent.  So it's a very small number of ISPs that are responsible for most of the data we're trying to keep accurate within the Whois database. 

So what does this tell us?  Tells us that 79 percent of SWIPs are not required to be validated.  Only 51 percent of ISPs actually publish SWIP records, and, of that, six ISPs are responsible for maintaining 66 percent of the SWIPs requiring annual validation.

So those are the numbers we've shared with the AC, and I'm not sure what they did with them, but we're now open for discussion/questions.

John Curran:  Microphones are open.  Center microphone.

David Huberman:  David Huberman, Oracle.  Hi.  We talked about this privately, but let's talk about it publicly. 

To me, this has to be a huge wake-up call to the ARIN staff, the ARIN Board, the ARIN AC, and the community. 

A lot of the problems of the law enforcement community, a lot of problems of the policy community we talk about with POC validation simply come down to an education of a very, very small handful of organizations. 

If we spent time and money with the staff doing actual outreach to these six ISPs and, in some cases, to these 30 ISPs, we could do much greater things.  I'm losing my words here. 

John Sweeting:  Improve accuracy.

David Huberman:  We would improve accuracy.  We would improve validation.  We would help our friends in the law enforcement community, help friends in the operations community, in a much greater, more meaningful way than any of these policy changes we're talking through.

John Curran:  You might need to stand by the mic for a moment. 

So I agree.  But need to ask a question:  It would be nice to know for parties that do not comply after they've been educated what the intent of the community is, because how you approach that education, how effective it might be, a lot of it depends on what your attitude is towards noncompliance. 

And so the policy question is still a really valid one here because having clarity on what the community's expectations are make it ten times easier to do the communication with those organizations. 

David Huberman:  So your point hits home in a way I never expected.  Would we have the previous iteration of POC validation, and we tried to put a little teeth in it.  We said if you don't validate your POCs, we're actually going to strip your reverse DNS. 

When I read that, as an operator, I said, oh, heck no, I'll put my considerable body in between the policy and that, okay?  We're not stripping people's reverse. 

But if you then change the topic and you say it's actually only six ISPs, and let's say one or two of them just wants to be a little belligerent to what the community wants, that's actually where I'd actually be more in favor of those types of things.  So it's a very good point you bring up.

John Curran:  Thank you.

Kevin Blumberg:  Kevin Blumberg, The Wire.  Can you go back to the questions you asked?  To clarify, those questions were asked by the Advisory Council; is that correct? 

John Sweeting:  No. 

Kevin Blumberg:  Where did the questions come from? 

John Sweeting:  The questions --

Kevin Blumberg:  The questions that were asked, who were they asked by? 

Paul Andersen:  The AC asked you for data.

John Sweeting:  The AC asked for data.  They didn't actually ask of this, but most of this was contained in it.  They asked it for, I think, 2017-3.  I believe it was Amy Potter that asked for it through Dan.

Kevin Blumberg:  Where I'm going with this is the next question:  Is referral Whois included in this data set? 

John Sweeting:  SWIPs only.  We don't POC validate.

Kevin Blumberg:  I understand that.  Where I'm getting is there is a major set of data that is missing from this in terms of the total aggregate amount of IP space because the number of Orgs that use referral Whois is also very large. 

So these numbers look extravagantly interesting, but they're completely missing out on also another incredible number of companies and Orgs that use referral Whois where you're pulling the data. 

I want the community to know:  This is not 100 percent of the Orgs and 100 percent of the address space; this is I don't know how much of the address space and how much of the Orgs. 

So the problem with statistics is we've got to know what it's based on.  How much of the address space, et cetera, is this based on? 

John Sweeting:  Right.  But this is totally for the Whois accuracy and POC validation, that's what they were requesting.

Kevin Blumberg:  I'll use a random number.  If 60 percent are using referral Whois and their numbers, their SWIPs are completely baloney, it's even worse in terms of validation. 

Jason Schiller:  Jason Schiller, Google.  ASO AC. 

Just wanted to follow up on the conversation that John and David were having.  And the question was posed:  What does the community want in terms of if we sit down with these six large ISPs and they're the majority of the problem, what does the community want to happen? 

Unfortunately, I don't think that's a simple question.  I think what the community needs to understand is what are the challenges and what scope and what scale is preventing this data from being better. 

And I think once we get to the bottom of that question, then we'll be in a better position to answer the question you proposed, which is what does this community want to see done about it.

John Curran:  I'm sorry.  Are you saying that you want, need to know the difficulty of updating things with SWIP or --

Jason Schiller:  Yeah -- no, no, I'd like to try to understand what is the problem state.  Why is there so much stuff unSWIPed?  Is it in RWhois and we're just not accounting for it?  Or why are there so many accuracy issues?  What are the actual challenges that these six problem child are facing? 

John Curran:  The community is never going to know that because that's a question -- even if I were to get told those answers, that would be under NDA. 

And so you can find these very easy, and you can try to reach out to these folks and ask.  But it's not something -- unless they come and say "We're having technical challenges, help us," I can't give the information to the community, even if we're told it. 

John Sweeting:  One of the things we were trying to do with this, Jason, was to size the problem and maybe make it more focused to where we can really focus on where it needs to have the attention. 

Do we need to -- obviously we don't have to waste any time on the simple reassignments.  Do we really need to waste a whole lot of time on detailed reassignments, or do we focus strictly on reallocations? 

The direct stuff is pretty much -- I can guarantee it's pretty high up in the accuracy for the direct allocations and direct assignments.

Jason Schiller:  As a simple question to that, I would say, for the detailed, if we can get them to acknowledge at the time it's registered, that would probably solve a huge portion of the problem there.

John Curran:  Yeah, because of the way things work in the world, the only dialogue that I would ever really have would be the one that talks about their obligations, contractual and policy obligations.

So reaffirming in the community what your expectations are is necessary to engage them in a way that's productive and talk about this.  Certainly, if you know -- it doesn't take much to find the six organizations.  Okay.  I think any of you could find it in 30 minutes of looking online. 

So you can reach out technical advocate to technical advocate, that certainly works, but that often doesn't explain why you won't see compliance.  That's an organizational issue.

Matt Petach:  Matt Petach, Yahoo.  I beg your indulgence for another stupid question.  2017-3 and the discussions around it seems to hinge on actions taken against the Org whose POCs didn't validate.  Is that correct? 

John Sweeting:  I believe so.

John Curran:  I'm sorry.  I'm not sure that's a good characterization.  It's a policy that sets certain requirements.  But it's going to hinge on whatever you guys give us for text.

Matt Petach:  The teeth we've been talking about thus far has really been aimed at saying this Org ID didn't validate its POCs. 

The slide you have here is really talking about which ISPs are putting out SWIPs and who is actually validating POCs and who isn't. 

It's not 30 ISPs that are concerned about the POCs being validated for, it's several tens of thousands -- I don't know how many invalid POCs we have in the database at the moment. 

So I think we're comparing somewhat not quite orthogonal data sets here in that -- we talk about a policy that punishes the people one level down from the people reporting -- we're reporting data on here. 

John Curran:  This is not specifically in response to the policy proposal.  This was just an analysis that we did to try to answer questions the AC posed to us.

Matt Petach:  Which I thought was being asked relative to that policy. 

John Sweeting:  Amy could maybe address what they specifically wanted that data for. 

Amy Potter:  We were trying to figure out whether or not it would be effective to take those teeth a level up and put some requirements on the upstream ISPs, making these reallocations to require their customers to update their POCs. 

So we wanted to see, well, how many reallocations does the average upstream make and all of this fun information.

Matt Petach:  So that answers my question.  Basically this is the follow-on to 2017-3 in that instead of going after the Org at the lower level, what if we went one level up and said who is putting out these SWIPs to people who aren't validating. 

Amy Potter:  Correct.

Matt Petach:  Thank you for clarifying that.  Awesome.

John Sweeting:  So, Matt, there's 530,000 SWIPs -- this is both reallocations and detailed reassignments.  If you take the detailed reassignments out and just go with the reallocations, it takes it down to 82,000.

John Curran:  Closing the microphones on this.  We'll be going to Open Microphone shortly.  And we have a speaker at the end of the table. 

Dan Alexander:  This is Dan Alexander.  Amy captured most of what I was going to say.  Just for clarification and to Kevin's question:  This was just a request of staff from the AC for background information so we could scope out some of these conversations.  Since this information had some interest, it works well in a presentation as well, but it's in no way an all-encompassing SWIP analysis. 

David Farmer:  David Farmer, University of Minnesota, ARIN AC.  Yes, we could all go find those how many ever number of ISPs.  They also know who they are.  There's a lot of people making certain kinds of assumptions in the room, and we're only hearing one side of the story.  I would implore one or two of them to try to get their side of the story in the air, too.  Thank you. 

John Curran:  Center front microphone. 

Owen DeLong:  Owen DeLong, Akamai.  Once again, I will say we are the recipient of a lot of SWIPs, not the originator of them.  And the characterization of validating SWIPed contacts on reassignments as a waste of time bothers me greatly because it's the primary mechanism by which we discover that somebody has named some random individual within our organization as a point of contact that they shouldn't be named as, responsible for space they have almost nothing to do with other than signing a contract once upon a time with an ISP. 

So we'd like to get our legal department out of the SWIP business, and the POC validation process is one of the primary mechanisms by which we're able to do that.  Please don't take it away without some suitable replacement such as POC validation at time of entry, which we'd really like.

John Curran:  Thank you very much.  John, thank you for your presentation.  Very informative. 

(Applause.)

Open Microphone - Thursday

John Curran:  Okay.  Last session is Open Microphone.  Microphones are open for questions for ARIN, questions that haven't come up, policy matters.  We have an Open Microphone session at the end of each day to allow people to express themselves. 

Usually these are people who haven't been to the mic much, haven't expressed themselves, are shy, the more quiet people. 

And, so, okay, first, Kevin, go ahead. 

Kevin Blumberg:  Kevin Blumberg, The Wire.  During the community discussion, I asked a question of the room, which was:  What are we looking to solve with community networks?  And over lunch I was given a great example of what we could do in policy with community networks. 

If community networks don't exist, a community network would, by default, be defined as an ISP.  And in IPv6, that means the minimum size they could get is a /36, which is actually an improvement of what they could get before, which was a /32. 

So having community networks allows micro networks to exist, because otherwise they would be defined as a standard ISP, and the community has said we don't want to give out small allocations to ISPs because they need to give the right size. 

So, yes, there is an absolute benefit, and I'm glad that somebody was able to help with that. 

My concern with the policy I noted, et cetera, last year I wrote a policy that basically said community networks could be ISPs with these lower requirements and get smaller space, et cetera. 

I've written two policies on community networks.  There's a third now.  I have no intention of writing a fourth or a third policy myself. 

I would suggest there's been some good work on the definition, but it could be simplified completely.  Whether it's a nonprofit or not-for-profit or whatever is not the relevant issue.  Providing to a small community Internet connectivity is enough from a definition point of view and allowing it to be an ISP where they can SWIP. 

Not allowing the SWIPs is, by default, breaking what a community network who is providing connectivity should be doing. 

And I know Owen and I disagree on that aspect of it.  This is not a fee-schedule issue when you get into these ultra-small sizes; it's a negligible amount.  But I believe that the community could have a policy that was useful more than just a definition.  Thank you. 

John Curran:  Okay.  Thank you.  We have the right microphone, go ahead.

Daniel Karrenberg:  Hi, my name is Daniel Karrenberg.  I'm an Internet citizen, speaking for myself.  As some people might know, I'm one of the people responsible for the fact that we have five RIRs and all these transfer policy problems. 

But 10 years ago I made a vow never to talk in a policy discussion anymore.  So, this is Open Microphone, so it doesn't count, I hope. 

What I want to say -- and this is more to the community than to the ARIN leadership -- is that from like 40,000 feet up it looks like the business of all the RIRs is changing from managing scarce resources to managing a really accurate registry. 

And if you follow me that far, I think the communities should realize that sort of fiddling and turning knobs in transfer policies or location assignment policies and so on is akin to rearranging the deck chairs on the proverbial Titanic and that now and in the future the RIRs will be accountable for actually the accuracy of their registries. 

So, if you, in your deck chair-rearranging efforts, put up barriers for people to register what they're actually doing, I don't think you're doing the right thing.  Thank you. 

John Curran:  Excellent.  Front and center.  Yes. 

Andrew Dul:  Andrew Dul.  This may be better tomorrow, but I'll have three words now:  Services Working Group. 

John Curran:  Actually, I was going to give a little update to that, but tomorrow I'll do that. 

Center microphone, go ahead. 

Owen DeLong:  Owen DeLong, Akamai, ARIN AC.  The key difference between at least the vast majority of community networks for whom the policy was originally intended and a more generic ISP is that by and large community networks are not dealing with subscribers with routers; they're dealing with subscribers with laptops. 

And they don't generally need to delegate /48s or larger to those laptops.  They are generally delegating something south of a /64, probably a /128, to the laptop, if anything.  And usually the laptop is making up the /128 on its own given 64 bits from the ISP in question. 

So I don't really understand the perceived need to SWIP that, but if Kevin wants to defend that, he's welcome to. 

John Curran:  I actually think both you and Kevin should go to the social, get a drink, find each other, and discuss community networks. 

We have an open topic, but there's nothing before the committee -- there's no proposal here to be discussed. 

Kevin Blumberg:  All I was going to say was we had a policy that wasn't used for eight years because we pretended to know what our community needed or wanted before IPv6 was really deployed.  I want to give the community networks the most latitude without having to go back every year, that's all. 

John Curran:  Understood.  You folks should get together.  And talk to the other people on the AC, because there's a few of them, too. 

Matt Petach:  Matt Petach.  This is completely unrelated to community networks, I'm afraid.  For staff, when you send out final notices to people, you send out the invoice number.  You send a link to the ARIN payment page. 

When you go to the ARIN payment page, you have to put in an invoice number in the exact amount of the invoice, but the final notice doesn't include the amount.  So you have to call up ARIN and get somebody on the phone and have them tell you what the amount is so you can go to the webpage so you can actually look and pay the invoice.  Can we maybe include the dollar amount in the email? 

Paul Andersen:  You're correct because I had this only yesterday.  Or you can log in on the ARIN Online and get it.  You don't have to call.

John Curran:  So, we don't let you pull up the invoice from the link, just by the invoice number.  We use the amount as the password.  Okay, that's colorful in so many ways. 

(Laughter.)

Paul Andersen:  It's a good thing we have a lot of unique passwords, then, in theory, right?

John Curran:  There is a certain truth that there are people that mine URLs and you have to be careful of that. 

On the other hand, we're asking you for money; we should make that pretty easy for you to give it to us.  I'm a big fan of that. 

Matt Petach:  Seems a little harder than it should be right now. 

John Curran:  We'll work on that. 

Matt Petach:  Thank you. 

John Curran:  Anything else on Open Microphone?  I am closing the mics.

Chris Tacit:  Chris Tacit, ARIN AC.  This is very much an ARIN AC question for me.  What I'm interested in is getting input from the community on what areas the community thinks the AC could tackle in a surgical way to simplify the NRPM. 

When this kind of effort has tried to be done in a very large-scale manner, it invariably doesn't go very well. 

So I would like to understand from the community if there are specific areas where they consider that simplification would be good, and how we might carve that up in a way that is digestible to the community.  Thank you. 

John Curran:  Find Chris if you have ideas on NRPM simplification. 

Chris Tacit:  And I'll be at the social with many drinks in hand.

(Laughter.)

John Curran:  Open mics are closing shortly.  Three, two, one.  Open Mic ends.  Thank you, everyone. 

Public Policy Meeting, Day 1 - Closing Announcements and Adjournment

John Curran:  We will now have our day closing announcements. 

So vote now.  Voting is open.  We've actually had some people already vote. These are people who, as Susan said, won't get harassing calls from the staff next week. 

So put yourself in that elite category and go vote.  Okay.  Very important.  If you have any questions, there's an election help desk that will be open tomorrow as well, and -- or you can send us questions or you can find a member of the staff.  Not a problem. 

Okay.  Thanks to our sponsors, Zayo and Google. 

(Applause.)

I'd like to remind everyone tonight's social at Club Auto Sport.  It's going to start at the Fairmont.  Buses leave at 6:45, 7:00, and 7:15.  Return shuttles start at 8:30.  Come back.  Wear your badge or your social badge; you've got them both in your packages. 

Don't forget the meeting survey.  We're going to send you an email, but you can also go now and save time.  It's on SurveyMonkey, ARIN 40 survey.  And we'll enter everyone to have a chance to win an Apple iPad Air 2.  So, please complete the meeting survey.  You'll get a link if you are registered for the meeting. 

Okay.  Reminders.  Breakfast tomorrow, 8:00 AM. Breakfast is the same place it was before.  It's downstairs.  Okay. 

Public Policy and Members Meeting, 9:00 AM, up here. 

Lunch.  Members Meeting open to everyone.  So we'll have the Public Policy Members Meeting in the morning.  We have one more Draft Policy to go through, actually a Recommended Draft. 

And we'll have the Members Meeting going into the afternoon, which is open to everyone.  We hear the reports from all the departments tomorrow. 

All the meeting materials are online if you want to go look.  That's it.  Look forward to seeing everyone tonight.  Thank you.

(Meeting adjourned at 5:00 PM)