ARIN 40 Public Policy Meeting, Day 2 Transcript - Friday, 6 October 2017 [Archived]

Please Note: This transcript may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting. If additional clarification and details are required, videos from our original webcast are available on our YouTube channel.

For an executive summary of Day 2 of the meeting, read the daily digest on the TeamARIN website.

Public Policy Meeting, Day 2 - Opening Announcements

John Curran: Welcome back. This is to – our ARIN Public Policy Meeting will continue for this morning, and then we’ll have our ARIN Member Meeting this afternoon. The ARIN Member Meeting is open to all.

First, thanks to our network sponsors, Zayo, and our webcast sponsor, Google.

(Applause.)

I saw some of you did not clap for our sponsors. We’re now coordinating turning off your Wi-Fi.

One more time, let’s hear it for our sponsors.

(Applause.)

Very good. Much better. Okay. So vote. The elections are open. There’s a help desk outside. Vote now. The elections will be open until the 13th of October.

If you have any questions, run out to the election help desk. It should be very easy. If you are a voting contact, when you log in, you’ll see a button that says “Vote Now” on ARIN Online. It’s fairly straightforward.

All of the biographies and all the statements of support are available online. Additionally, you can make a statement of support even now for a candidate. If there’s a candidate that you believe would be particularly good in the role, go online, make a statement of support.

Okay. Emergency procedures. We’re here. There’s exits. Go out the exits, across the street is a lovely park, we’ll meet you there, should there be an emergency.

We’re meeting here. Breaks are outside. Our lunch is downstairs. There may be other meetings in other parts of this very large complex, but we don’t need to wander into them.

Okay. Rules and reminders. The Chair moderates the discussion of the draft so everyone can speak and be heard. If you find yourself up at the microphone and the view looks familiar, it’s because you’ve been up at the microphone before.

You might let other people who you haven’t seen there go before you, just to make sure we get a chance to get everyone in.

State your name and affiliation when you approach the microphone. There are courtesies in your Discussion Guide.

Okay. So today’s agenda, we have quite a bit: NRO Activities Report; the NRO NC Report; the IANA Review Committee Update; Software Development Update; Open Microphone session; Registration Services and Engineering Department Reports; our ARIN Advisory Council Report; ARIN Financial Report by the Treasurer; and Board of Trustees, and Open Microphone session.

And, then, in this light schedule, we’re also going to fit in one more policy. And this policy is 2017-5. It’s actually a Recommended Draft Policy, which means it could be moved for adoption after this particular meeting. And it’s Improved IPv6 Registration Requirements.

So at the head table I have our Chair, Paul Andersen. I have Board member Bill Woodcock; Daniel Alexander, the ARIN AC Chair; Tina Morris, the ARIN AC Vice Chair. And I actually can’t see the face down there.

Chris Woodfield. My mind goes blank, just unbelievable.

Okay. And he’s our Jabber scribe, Chris Woodfield.

Speak slowly and clearly. We still have a scribe out there. They’re busy helping transcribe this for the remote participants.

Now I’m going to lead right into the meeting. The first report will be myself, giving the NRO Activities Report.

NRO Activities Report

John Curran: Okay. NRO Number Resource Organization. Our goal: To be the flagship global leader of the collaborative Internet number resource management as a central element of an open, stable and secure Internet.

Yes. We’d like to make sure that the Internet numbers are appropriately managed. And that’s what we coordinate towards.

Established by an MoU in 2003. We coordinate the RIR system. We promote the multi-stakeholder model. We fulfill the role. In ICANN, we are the Address Supporting Organization.

You can go to nro.net for more details.

So we have an Executive Committee, made up of executives of each of the five RIRs: myself, Paul Wilson, Allen Barrett, Axel Pawlik, Oscar Robles.

And we rotate the duties of the NRO among the Executive Committee. So this year I’m the Chair of the NRO. And Paul Wilson, Vice Chair; Allen Barrett is our Treasurer.

Then you get two years to relax, and then you’re back into the fray. The Secretariat is hosted by APNIC. Executive Secretary, German, does a wonderful job. We have Susannah, who is also helping him out. And they handle this enormous amount of communication that the NRO does to and from bodies that want to talk to the RIR system.

A lot of this is ICANN, but sometimes it’s other bodies.

We also have coordination groups underneath, which are responsible for helping us align our activities.

So the communications activities, the engineering activities, the Registration Services teams.

When we do things like change the stats file or change the transfer logging, or when we do some sort of other coordinated change across the registries, the engineering functions are coordinated by these teams, the communication, the Registration Services changes, these groups meet to keep us acting like one global registry.

We publish a number of things, which those groups produce, like the Internet Number Status Report, which you heard. Updated quarterly.

We do a Comparative Policy Overview. If you’re not aware of this, this is actually an interesting document. And it builds tables for each of the major policy areas of the number policy in each of the RIRs and compares the high-level comparison of the policies.

So new issuance for v6; additional blocks; transfer policy. You can see each of the RIRs and get a high-level summary of how we differ in policies.

It is a high-level summary. It’s one quick document that gives the 30,000-foot view. Obviously, when you get closer, each RIR has their own particular issues, but it can be very useful.

Within ICANN, we operate as the Address Supporting Organization. The important thing to realize about that is – here we go – the Address Supporting Organization within ICANN, we work with ICANN for two things, predominantly.

One is global Number Resource Policy, and the second one is appointment of people to the ICANN board. Both of those functions are done by a group within the NRO, our NRO Number Council. Within ICANN, that’s referred to as the ASO AC.

So we do work within ICANN and their structure, predominantly through the ASO AC.

Budget. All this stuff takes money. Each of the RIRs puts in an amount of money to offset a percentage of the budget. It’s based on the total organizational budgets of each. And so the ratios of those billed these numbers with AFRINIC 7 and APNIC 23, ARIN 29 percent, and LACNIC 10. And we adjust these each year as our organizations change.

We have general operating expenses, meetings, so on and so forth. We contribute $100,000 a year to IGF, which is the Internet Governance Forum, which gets together annually and has a very significant meeting to talk about Internet policy issues.

We contribute to ICANN to the tune of $823,000 a year, which is what we’ve been doing since the first year of ICANN’s formation.

Because we have an agreement for ICANN to be the IANA Numbering Services Operator through its PTI operation, that money predominantly pays through that. 675.

The rest of it is a general contribution the ASO makes to ICANN, so the dollar value hasn’t changed over the years. But we have it earmarked in two categories.

The RIRs also – financially, we operate the Stability Fund, the Internet Number Resources Stability Fund. It’s a joint RIR pledge.

We all have funds in reserve, $2.1 million right now. If an RIR were to have a catastrophic-level event, financially, this would help. We’ve all pledged money to make sure that all the RIRs have a backstop if it was necessary.

We also pledge technical resources. So that could happen if one of our headquarters were to suffer a cataclysmic event. That could happen if one of the organizations were to suffer some untoward financial event.

But we are all committed to each other’s success and have all pledged commonly so that there’s a backstop for an RIR that has an issue.

IANA transaction: As I said, we have a Service Level Agreement with ICANN. It’s based on the IANA Stewardship Transition Plan. I don’t want to go through the IANA Stewardship Transition Plan, because that’s supposed to be in the past.

But, at a high level, these services were being done under contract between ICANN and the U.S. government, NTIA. That agreement was allowed to lapse.

We had to establish agreement so that the IANA function was being done under our auspices. We have done that, and it was signed at ICANN 56 last year, and the SLA’s working fine.

You’re going to hear later today an update from the SL Review Committee. There’s a review committee made up of three members from each region that looks at the performance report and makes sure that we’re getting the performance we’re supposed to get for our Central Registry, our IANA updates to the central pools.

Given the very small number of transactions, many of the monthly reports are completely empty. That we requested no transactions, they delivered no transactions, and it was 100 percent success.

On the months where there is a transaction, they report the metrics of how responsive they were. And it’s also been 100 percent success, as far as I can tell.

But the review committee formally is charged to review their performance and provide advice about continuing, renewing, raising issues on the contract, for example.

Review committee members are here from the ARIN region. Louie Lee and Jason Schiller are the two members of the community. And there’s a staff member from each of the RIRs. Nate Davis is the staff member.

ICANN accountability. Let’s see. Wow. Back when this whole project was started about the US government stepping back and allowing the entire Internet system – the DNS, the number registries – to be administered not under the auspices of the U.S. government, a lot of people in the domain community said we want ICANN to represent us. ICANN will represent the domain community, but we don’t trust ICANN completely; we want to improve its accountability before it is the one representing the domain community.

And they kicked off a cross-community working group on ICANN accountability. This working group had many deliverables, one of which was changes to ICANN’s bylaws; creation of a new empowered community structure within ICANN.

Well, now we’re in the second half of this work, called Work Stream 2. And there’s still more than half a dozen work groups looking at all sorts of things: SOAC accountability and ICANN’s jurisdiction and staff accountability to ICANN. And these groups are continuing to try to improve ICANN and the ICANN system.

We have representatives who monitor those groups and report back if there’s potential implications for the number system.

ICANN Empowered Community. So as a result of ICANN – the U.S. government stepping back and the fact there needed to be oversight of ICANN, and that the board itself wasn’t deemed a suitable one, the way that the ICANN board was actually put into office was changed.

And now the ICANN board is actually – while it’s recommended by all of the organizations within ICANN, all of the supporting organizations, and the NomCom at large – the actual appointments are done by a body called the ICANN Empowered Community.

The ICANN Empowered Community is effectively five organizations – the ASO is one of them – that serves solely for the purposes of providing a backstop oversight mechanism.

In general, we appoint ICANN’s directors. If there’s a successful petition, we could remove ICANN directors, one or all of them. If there’s a petition against an ICANN action, like adoption of a budget or changing of their bylaws, we can stop that from occurring.

It’s a fairly rigorous process. It’s a fairly extensive process. We need to have procedures for how we do our part.

So if, for example, the community says we don’t like the budget ICANN’s working on and a member of our community comes to us and says we need to petition to stop that, we would need a way of considering that, how to work it out with you, and our Advisory Council, and how to raise that petition to stop this, raise it with the other members of the Empowered Community.

The other members of the Empowered Community are folks like the CCNSO and the GNSO and ALAC and the GAC.

And so we also need procedures in case one of them raises a petition. One of them could have an objection to an ICANN bylaw change, raise a petition, come to the ASO and say: “Dear ASO, we’d like you to support our petition.”

There’s a lot of paperwork here. There’s a lot of procedures. We’re in the process of developing procedures.

We have interim procedures for doing these things, which also involve consultation with the Advisory Council, the ASO AC, but the ASO AC is working on its own procedures underneath those.

We also know these are interim and we may have to evolve them. There’s a bit of overhead in our engagement with ICANN. But it’s necessary to some extent because they wanted a backstop that was external to ICANN, that was owned by the community, and we’re one-fifth of that backstop.

RIR accountability: We’ve actually been looking at our own accountability. If you go online to the NRO, you can find something called the Governance Matrix, which, much like the Policy Matrix, summarizes the major governing functions of each of the RIRs, how our governing boards have done, how we do the budgets, how we handle disputes, how we handle data protection. It’s a summary across all the RIRs.

We also did an independent accountability assessment. We actually all hired law firms to look at us to see whether or not each RIR was accountable to its members; was it appropriately structured; was it set up so that it could be avoided capture; could we have a situation where a small non-representative segment of the community could somehow take over one of the RIRs.

You can read the reports. They’re all online, the summary reports. We feel it’s pretty important. We want to make sure that not only we’re running a good operation, but we’re governing it correctly and we don’t have any undue risks there.

ASO review. ICANN bylaws call for periodic review of each of the supporting organizations. Our agreement with ICANN says the NRO shall provide a review of ASO’s effectiveness within ICANN.

We conducted one in 2011. In 2016, we actually initiated another one, awarded it to ITEMS International.

The final report – we went through a number of consultations. You heard presentations here. The final report came out actually in August. It has 18 or so recommendations talking about how the ASO can be more effective within ICANN.

It’s worth reading. The RIR community has open consultations for implementation of those recommendations. We’re open to hearing thoughts about should we implement those recommendations; are any of them good or bad?

There was an open consultation. ICANN also opened up a consultation on this. And now we’re all – at the NRO, we’re now looking at the results trying to figure out, okay, which of these do we implement, do we do any other changes, and we’ll be looking at that.

When we have a plan of how to evolve the NRO-ASO relationship with ICANN, we’ll come back to the community with a concrete plan and say this is what we intend to do.

Technical projects: RPKI services for all resources. This is fairly interesting. RPKI is a service that allows effectively you to obtain a digital attestation that you’re the rights holder to a resource block and to actually present a signed object about who should be routing that resource block.

And it turns out it’s based on good old certificates. And there’s some standards for those, and the standards for certificates are very cool.

One of the provisions in the standards for certificates is that if a certificate authority should overclaim, should say I’m responsible for all of these certificates, and it turns out it’s actually not, then it’s possible the whole tree will be invalidated.

So it’s a pretty fragile situation. It’s possible, for example, when an RIR transfers an address block to another RIR, that we have to change our lists of all the resources we’re responsible. They have to change the list of all resources they’re responsible for, because we’re removing one block from ours; they’re adding one to theirs. And at the same time all this has to update in a perfect manner. And if we get it wrong, the entire CA tree for an RIR could go invalid.

Now, the RIRs looked at this, and we found this wicked cool, to use a Boston expression, and Geoff Huston nicely wrote it up at the IETF and sent it off to the IETF and said we really need this fixed, the validation algorithm.

They’re still mulling that over. There’s a lot of discussions. There’s even some progress, I’m told.

But in the meantime, we don’t like the fragility aspect. So in the meantime, each of the RIRs have set a top-level trust anchor that says, hey, I’m responsible for all resources.

RIPE says that. APNIC says that. ARIN says that. We’ve all rolled out effectively a 0/0 trust anchor for RPKI, individually.

So when we move resource blocks between each other, there’s no chance one of us will be overclaiming and have our whole CA tree thrown out.

You can read about it online. We did that transition. It doesn’t change anything. Using our trust anchor, it’s all the same.

Everything’s underneath. But you look what’s underneath in terms of resources and manifest, it’s all been updated.

And that may not be forever. Maybe until we have a better algorithm for RPKI; that’s a pretty fundamental change, though, because it requires getting down in the weeds in public key infrastructure stuff.

IANA/PTI reporting requirements, part of the IANA SLA. We have to work with the IANA PTI team, the Public Technical Identifier team at ICANN, to agree on a format for how they report things. And we’ve done that, and it’s worked well.

Internet Technology Health Indicators, ITHI consultation. So ICANN kicked off a project. Their OCTO, Office of the CTO, kicked off a project to try to measure how is the identifier system working in the Internet.

DNS, IP addresses. Are these registries available, reliable? Are they doing their job? Is there metrics that could be useful in just measuring that overall health?

There’s some issues going on within ICANN for the DNS. We had the registration teams within ARIN and the other RIRs all get together and come up with a set of metrics that would apply to the health of the number registry system.

We put that out for consultation. We’ll be reporting back. This is an ongoing project. If you have thoughts on metrics that should be reported, go take a look at this.

That’s a fairly significant – and all these activities obviously are heavily coordinated. That’s why they’re not ARIN projects or RIPE projects, they’re NRO projects, because they have to be the same in all the RIRs.

And then NRO website revamp. The NRO website is interesting at times to find things on. And we’re going to – we actually have improved it significantly. So that’s a good step.

Thank you. That’s the NRO presentation.

Questions on this?

Ruediger Volk: Ruediger Volk, Deutsche Telekom. Sorry for the audience that I’ll be boring you with my RPKI thing.

The RPKI changes that you have done, you claim change nothing. I would question that.

John Curran: Be a little more specific. The changes we’ve done, the NRO changes to change at the top level for a 0/0?

Ruediger Volk: Yes. That changes things because you’re breaking the RPKI architecture that claims to map the delegation tree.

John Curran: Right.

Ruediger Volk: And, more specifically, after you did that, you kind of – you kind of are pushing the problem of figuring out what potential conflicts are done by the different routes to the relying parties.

And that’s something that I do not think is welcome by the relying parties.

On the other hand, yes, I can see that this move kind of responds to years’ long questions about, well, okay, what are actually the expected procedures for transferring resources. That’s a nontrivial problem; and, yes, one could say you have removed that by a trivial thing, but that actually has semantic consequences that are nontrivial.

John Curran: Right. So stay at the mic. So the change was a workaround. It’s a workaround that I agree has semantic changes.

For example, it’s now possible in RPKI that two RIRs are both saying they’re responsible for the same address block. That shouldn’t have been possible in RPKI and now it could.

You have trust anchors that point to two different trees, but those two trees have the same object.

So my question to you is: I didn’t see you in the consultation when this was all happening, but I hear it now. Is it your belief that we should have remained with the existing model of trust anchors and the fragility until such time as it was fixed by the validation algorithm and that we shouldn’t have done this workaround?

Ruediger Volk: Kind of. Kind of. I have been watching this for not just the past six months. And I would say kind of that, okay, a chance for doing something to improve the situation has passed for a long time, and I would question whether a rapid action right now was really required.

John Curran: So you’re saying this action might not have been really required and we should not have done it?

Ruediger Volk: I would rather say so. And kind of actually, unfortunately, at the time when you sent out the message, I had personal circumstances that disabled my participation in stuff to a large extent.

John Curran: So do you think we should roll it back?

Ruediger Volk: Kind of. My understanding is technically we could easily.

John Curran: Oh, sure.

Ruediger Volk: I would not suggest to do so without some serious discussion, which seems to me has been missing for the action that you took because you were referring to a timed-out Internet draft that actually at the time did not get positive critique, except from the authors.

And the communication for the action that you did seemed to be pretty scarce. Just the other day I figured – I heard one of the people who are active in the area that the news was completely new to them.

And I told him, yes, the thing – the communication seems to be essentially John sending a message to the not-exactly-appropriate IETF working group. And the guy said, yes, okay, if it had been on sidrops, I would have noted.

So kind of – I don’t want to let this pass without making a statement about it and raising the awareness. I don’t see a necessity for changing back right now without thinking and discussing.

John Curran: Okay. Got it. I’m going to go to Geoff in a moment. I just want to respond to one thing.

It is true that we informed the IETF after working on an applicability statement that said what we intend to do in the IETF and publishing a draft, we told them not, “Let’s open up discussion about our need to change this.”

We told them, “We are moving to this. You should know that.” Now, of course, we did this four years after the RPKI validation draft said that the current state of affairs wasn’t acceptable.

And we didn’t open the discussion because, well, we had four years to discuss it and there was no progress.

But I’ll take Geoff. Geoff, go ahead.

Geoff Huston: Geoff Huston, APNIC. As someone not unconnected – indeed, very connected with this entire setup – certainly we did indeed try to engage in a useful discussion about working on a hairline of absolute perfection with no margin for error and our degree of discomfort, because that seemed like demanding an awful lot from organizations with humans running the wheels, you know?

And our efforts to bend the technology we knew would take time. And this seemed like an appropriate mechanism that would not harm it, but would mitigate that. Now, we consulted. We did indeed push out draft.

We tried to have a conversation about this. And on the feeling that it didn’t make good, bad – all it did do was make it easier to make things good – this seemed like an appropriate thing for the engineering folk to recommend to the CEOs: Maybe we should do this as a stop gap.

As it turns out, the new validation draft is presenting us with some unforeseen circumstances. As anyone familiar with v6 knows, transitioning from something to something else is never easy.

And even something as, supposedly trivial, as a change in validation algorithms is presenting some really weird side effects; that as we work through, we’re not sure yet. We know where we want to go. That’s easy.

We know where we are. That’s easy, too. Where we are has a different trust anchor scheme to mitigate. We would prefer to be in a different room, but finding the right sequence of actions really is going to require more talk and consultation, and no doubt sidrops will be intimately involved in that. Thank you.

John Curran: Carlos?

Carlos Martinez-Cagnazzo: I want to specifically address two of Ruediger’s comments.

One is regarding why we are doing this. And Geoff already said that. There’s another draft in the IETF that could really use our input and your help if you care about this.

And the second one is the comment about pushing of conflict resolution towards the relying parties.

I want to speak for RIR, for LACNIC, particularly, the resource certificate was never meant to be an inventory of resources. It’s not authoritative.

In our case, the resource certificate was a secondary product of registration database. The resource certificate is not authoritative. If you want to look at our holdings, look at the delegated file. Thank you.

John Curran: Thank you. It is also true that since the point in time when we announced that we’re doing this motion and changed to this mitigation step to make things less fragile, it does seem there’s a lot more attention to solve the underlying problem with the IETF, which is most appreciative.

Okay. Any other questions on the NRO Report?

Thank you. We’re now going to go into the NRO NC. The NRO Number Council, also known as the ASO AC Report.

I’ll have Kevin Blumberg up to give that.

I’ll take a moment. There’s a beautiful sweatshirt here. If you were at the social and meant to donate this to me – oh, come on up and get it. I thought it might be an open gift for me.

NRO NC Report

Kevin Blumberg: Good morning. This is Kevin Blumberg. I’ll try to go fast at the mic this time.

So on the agenda it says NRO NC Report. And we’ve got ASO AC Report. We’re just going to do a little bit of what is the two.

But for all intents and purposes, for this audience, they are the same group. The NRO NC – the members of the NRO NC – are responsible on the RIR side of the pond, and those same members then sit on a body called the ASO AC.

And to clarify, John, it’s the Address Council, not Advisory Council, when we use AC in this area.

Okay. So it’s the NRO Number Council. There’s 15 members; two are elected, one is appointed from each of the regions.

We’ve got a number of observers, staff members, et cetera, that join to listen in on our calls.

Not all the office terms are the same. But it’s done by region. In our region it’s based on three-year terms.

What we do, we advise the ICANN board when we are asked for numbers-related questions. We help elect seats 9 and 10 of the ICANN board.

We have one of our members on the NomCom, the ICANN General Nominating Committee. We meet monthly. We meet physically, annually, in March.

Louie, is this a question or clarification?

Louie Lee: Back one slide. Yes, thank you. Just quick clarification on term of office. At ARIN, the term of office is three years, whether you’re elected or appointed.

This has APNIC information on there. So now –

Kevin Blumberg: Thank you. We jumped slides between the different regions. There’s a lot of similarity. APNIC used many of my slides from the last time we did this. I used theirs. It goes around in a circle. So I did miss that, and I appreciate that.

So here’s the latest information – that is current terms. And I want to stress that. So as an example, thanks to the ARIN Board, I was reappointed yesterday.

That is not on the slide because my term still is until the end of this year, at which point my new term would start.

In the APNIC region, Aftab Siddiqui was just elected. He’s currently in an appointed position. He was just elected, I believe, two weeks ago, give or take, to a term.

So these are the current terms of all of the different regions. And if you are from the other regions, you will have worked with hopefully a number of these people.

So we have a scheduled meeting every month on a Wednesday. Because this is a global organization, or a global group of people, we like to use UTC time, which is wonderful for many regions, not so good for West Coast of North America.

We do have emergency meetings if it’s required. We haven’t done that in quite a while.

Since ARIN 39, we’ve had five teleconferences. And an interesting thing, quorum is not just that we have seven or eight people on a call, quorum is that we have everybody represented from every region. So we’ve got multiple quorum requirements and, unfortunately, in August, one of the regions was unable to attend. Therefore, we did not have quorum, and did not have that meeting.

The main topics for discussion since then have been the ASO review. We’ll talk about that a little later, but there was an entire report done on how not just the ASO AC, but how the entire ASO, operates. It’s done every five years.

This is the second time that review has come out. And there’s a final report on that.

Discussion on empowered communities. John spoke about it a little earlier. As part of the procedures for the empowered communities, the ASO AC has a carve-out in the interim document where we are asked to write procedures on that, and that’s something that we’re working on.

ICANN seat 9, that process has just started. Nominations have just opened. So we’re getting into full swing for that.

And we’re getting ready for ICANN, not 59 – yeah, we’re doing ICANN59 preparations.

So what is the main purpose of the ASO AC? Well, the main purpose is for us to work on global policy. And global policy is not policy that is useful for all of the regions, as an example.

That would be something that’s coordinated between the regions, but not something that is part of the scope of the ASO AC.

The ASO AC is responsible for global policies towards external bodies such as IANA. So sort of up towards IANA rather than down towards the RIRs.

And that is part of the MoU. So when you hear discussions at the mic where people are talking about policy and saying why aren’t we all just getting together and making this a global policy, like inter-RIR transfers, that’s not actually something that the ASO AC would do; that would be something that staff within the RIRs could help coordinate but isn’t part of the global policy.

And depending on which region you’re in or which organization you’re in, so if you’re within ICANN and talking about global policy, that’s what this means, not what necessarily we mean when we’re at a meeting here.

Global Policy Development: I’m going to go really fast through this. Effectively, everybody has to agree on a policy. It comes to the ASO. From the ASO, it goes to ICANN. They sign off on it. Solved.

Last time we did it was five years ago, give or take. So there’s a whole process. Every region is involved. We make sure that the text is consistent among the regions.

You get to write your own text, but it needs to be fundamentally the same and compatible.

No global policies going on right now. The policy proposal facilitator team, that’s the team that would start if something was a global policy, would start the kickoff, has one person from each region that’s on the ASO, and I’m the representative for the ARIN region.

Board seat selection. We discussed, here’s the timeline; as you can see, there’s many steps culminating in our announcement in the middle of May.

And nominations are open. So if there’s anybody that you would like to suggest from the ARIN region, or just in general, that is available.

Okay. Participation. We were in Johannesburg. There’s all different ICANN meetings. Some of them are longer. Some of them are shorter. From our perspective, it’s not as important because we don’t do policy, which is the other difference between us and the other serving organizations within ICANN.

So we’re not there to work on policy of the regions. That is what’s done in these rooms around the world.

So ICANN has many different formats because many of the ASOs do, many of the serving organizations do their policy through ICANN. We do not.

So we’ve got the ASO review. That happened. We’ve met with the CCWG-Accountability subgroup. We joined working sessions where it’s relevant to numbers.

The Empowered Community, the Cross Community Forum on Proposed Fundamental Bylaws Amendments, et cetera. A lot of ICANN fora-style stuff.

Appointments: We appointed Brajesh Jain to be on the ICANN Nominating Committee. And we have a slightly old but very functional and very packed website, aso.icann.org.

Lots of background and history. All meeting minutes are there. And, more importantly, there’s an attendance record dating back years there.

So you can see what we’re doing, when we’re attending, when we’re not attending. And it’s a great way to see when elections come up, next year as an example, how is your current ASO representative, ASO AC representative doing, and we just want to highlight we’re trying to be as transparent as possible with as many things as possible.

As well, the final report is available on the NRO’s website. Any questions?

Alison Wood: Hey Kevin, Alison Wood, State of Oregon and ARIN AC.

You talked about you guys would meet for emergencies. What would constitute an emergency that would call you all to meet?

Kevin Blumberg: That’s a good question. I don’t know if we’ve ever had an emergency. But Louie was the chair for – 10 years, Louie?

Louie Lee: Nine.

Kevin Blumberg: Nine. By all means.

Louie Lee: Louie Lee, ASO AC Vice Chair, Chair for nine years previously. Occasionally we would get a request that – say, for instance, IANA gets a request about ASN, because one of the regions have asked for another block of ASNs, and they want to know: So, how do you interpret this global policy, if the region needs some 4-byte ASN or not 4-byte, or more 2-byte ASN? How do you work up with that? And the region’s running out.

So knowing that passing a policy takes cycles, we may convene quickly, especially if there’s another meeting coming up very soon.

And we decide, okay, we consult with the community, get an idea what the sense of the community is: Is it okay to split it up? Do we actually not consider 4-byte versus 2-byte? That kind of thing.

John Curran: There could be a case for clarification, if we’re asked for clarification of global policy, our normal inclination would be go to the body that coordinated it, which would be the ASO AC.

There’s also now because of the Empowered Community, there’s a chance we’d be asked to support a petition that another ICANN Empowered Community member initiated to remove a Board member. For example, it could be a Board member on the ICANN board designated by our ASO AC.

That decision period could be 7 or 30 days, depending on the type of petition, and that would constitute an emergency meeting, for example, if we wanted to be able to get timely advice out of the ASO AC.

Kevin Blumberg: To add one thing. We have a list of procedures, not just standing rules, but a fairly comprehensive list of procedures that dictates a number of timelines.

So anything outside of that timeline would be considered an emergency at that point.

And based on the coordination of the regions, et cetera, we work in weeks, months, and years, not days and hours.

So as John pointed out, our current procedures that we’re working on towards the Empowered Communities would be in hours and days, and would fall under that sort of umbrella of emergency.

It’s not emergency in terms of necessarily the sky’s falling, but it’s an emergency in terms of the timeline for it.

Any other questions? Chris?

Chris Woodfield: Not from the queue, I’m speaking for myself.

You mentioned that the last time a global policy change was implemented was roughly five years ago?

Kevin Blumberg: Correct.

Chris Woodfield: I’m curious what that policy change was that required it to be implemented globally.

Kevin Blumberg: That was the AS change, was it not, Louie?

Louie Lee: Yeah.

Kevin Blumberg: The IPv4 strand policies. So that is where – space that came back to IANA would just sit there because the last /8s had gone out and there was nothing – it would just continually go there.

So the global policy was a way to come up with an algorithm to hand back those bits equally to all of the RIRs. That was the last policy.

If you have any ideas, by all means.

John Curran: Any other questions for Kevin?

(No response.)

John Curran: Thank you.

Kevin Blumberg: Thank you, everybody.

(Applause.)

John Curran: Okay. Next up, Jason Schiller, to give the IANA Services Review Committee Report.

IANA Review Committee

Jason Schiller: I’m Jason Schiller, ASO AC. And I’m going to talk about the IANA Review Committee Update.

This stuff is boring stuff. If you need to get some email done, I ask you look up when I get to my last slide. That is the most important thing.

So if you get nothing else from this presentation, please, look at the last slide.

I’m going to talk about what is the Review Committee and where are we in the bootstrapping process, the role of the Review Committee, and my last slide will be for discussion.

It was chartered by the NRO EC and based on the CRISP team recommendations. We have 15 members made up of two community representatives from each of the five regions and one RIR staff representative from each region who is a non-voting member.

This is the makeup of the current Review Committee. It matches who was on, who were the elected members of the ASO AC at the time it was created.

So this is actually from our operating procedures, and it specifies the purpose of the Review Committee.

The Review Committee’s function is to advise and assist the NRO EC in its periodic review of the service level of the IANA Numbering Services provided to the Internet Numbers Community.

The Review Committee is a tool for the Internet Number Community to evaluate and review performance of the IANA numbering services provided.

The Review Committee will ensure community involvement and will support and enhance the multi-stakeholder model in a transparent, open and bottom-up process, to ensure that the number resources component of the IANA operations meets the needs and expectations of its customers; namely, the Internet Numbers Community.

We are here so that you folks are getting the services that you need. Current status: We have adopted operating procedures. We’re currently looking at the IANA services performance matrix and its performance standards of metrics. And IANA has made an agreement with the RIRs and has actually started publishing these on their website. You can see in the last six months what the performance of IANA is.

There have been two transactions, one for IPv4 requests, and one for an ASN request. We’ve got four green check marks there: that it was delivered; that it was acknowledged on time; that it was responded to on time; that it was delivered on time and accurately.

Yay. We’re doing a great job. Like I said, this is boring stuff. But I think it’s also worthwhile to thank Elise, who has been the face of IANA for this community for the last seven and a half years, for boring us. Elise, thank you. Please stand up, great job.

(Standing ovation.)

Jason Schiller: We will dearly miss you, Elise, and we hope that you will be back for some more meetings.

The last thing I wanted to talk about is Review Community, community engagement. Again, I’ve got some text from our operating procedures. I’m not going to read it all out.

But the point here is that the Review Committee is here for you folks to tell us how IANA is doing – if they’re doing a good job, if they’re doing a bad job, if you’re not getting services you need, if you have concerns, feedback, observations, praise. We’re here to listen so that we can convey those concerns and make sure they get addressed.

And with that, I will open the mics. I would love to hear your thoughts on how IANA is doing and if there are any issues or any praise.

John Curran: Seeing no questions.

Jason Schiller: I assume no news is good news. Thanks, everyone.

(Applause.)

John Curran: Okay. Next up we have the Software Development Update, and that will be given by our Chief Operating Officer, Nate Davis.

Software Development Update

Nate Davis: Good morning, everybody. I’m Nate Davis, as John mentioned, ARIN’s Chief Operating Officer. I’m going to talk about the Software Engineering – give you a Software Engineering update regarding some of the activities that we have conducted as well as what we’re planning to do.

I’m going to go through this reasonably fast, keep us on time. So some of the topics I’ll be discussing are strategic guidance; how work is prioritized within ARIN; projects that we’ve completed since the last ARIN meeting; some of the forthcoming initiatives; and then, lastly, some stats on the ARIN Consultation and Suggestion Process.

So the Board’s great at giving us guidance regarding what are the things we should be focused on regarding our engineering efforts.

This is actually enshrined in the strategic plan which is available out on ARIN’s website under Corporate Documents – About Us, Corporate Documents – if any of you are interested.

But these are some of the key points here that they’ve provided us. And it’s really to maintain and enhance functionality of ARIN services as sought by the users and supported by the membership.

When Richard gave his discussion the other day, he mentioned the importance of feedback from the community. So, by and large, the things that ARIN works on are, for the most part, things we collect feedback from all of you regarding initiatives and so forth, features that you’d like to see added and so on.

Factors that influence our priorities. So, we have all these requests that come in. We have our own initiatives that we feel that need to be done. How do we prioritize those?

So like any organization, we have a mix of variables that actually influences what work gets done. And to that end, this is a number of the items that influence that.

It’s sort of a priority soup, if you will, and we kind of work through it and figure out what is the best approach given all the influences on how to deliver products to the community.

So, projects that have been completed since ARIN 39. As you know, at each ARIN meeting I report this, and I will project what we’re going to work on in the next year, or what we’re going to work on before the next meeting.

So with that in mind, when I reported back at New Orleans at ARIN 39, all the items that I’ve reported or reported that we would get done, we actually got done up until this meeting. So that’s good news.

So everything we committed to doing to the community publicly, we actually completed. And many of these continue to be ACSPs that we received from the community, and we appreciate the feedback that we get from the community regarding those.

Here’s a number of other things that we’re continuing to work on. What I would probably highlight is our web accessibility and UI/UX work. If you haven’t had a chance, we’re conducting some feedback collection out in the lobby regarding user experience, user input. Please take a few minutes, if you can, to sit down and provide your input to those folks out there.

I would also add that in addition to the web work that Richard mentioned, our web accessibility and UI work is a long-term project, and it’s going to take us some time to complete that. And so that effort will be continuing on for some period of time.

So forthcoming initiatives. Based on the consultation that was completed, we’re going to do the CKI23 POC restoration. We continue with technical debt. For a number of years, as you’ve seen, we’ve been focused on providing functionality that the communities ask for.

John and I, in particular, pressed Engineering to complete those efforts. But at the same time, we haven’t stepped back and done the infrastructure work that we really need to do. And so we’ve been doing that. We’re continuing to do that. But that will take some time for us to do.

And I just want to mix that in so that you’re aware that not everything that we’re working on is completely visible, because we have had to step back a little bit and work on infrastructure projects.

We’ll continue to, again, work on web accessibility and user experience throughout all of ARIN’s website pages.

And, lastly, the Internet Routing Registry. We’ll be beginning in Q2 of 2018 to begin work on the Internet Routing Registry.

Our ARIN Consultation and Suggestion Process. Presently we have 29 that are open; 28 of those require Engineering. The ones that don’t require Engineering, we tend to knock out pretty quickly. Those are ones that can be fulfilled either by CMSD or RSD, they’re changes in processes, updates to website text, and so forth.

As we can, we do try to complete those as soon as we can. It’s typically the Engineering ones that take a little bit longer to work on, as many of you can appreciate.

Some of the ACSPs are not all equal. Some we can get done quickly, as I mentioned; some require some heavy lifting; and, admittedly, we have some that have been on the backlog for some period of time.

Those projects, in particular, sometimes require actual infrastructure changes and they’re significant in the changing of ARIN’s architecture, say, for ARIN Online.

So that’s my update, and I’d welcome any questions.

John Curran: Okay. Center front mic. Kevin.

Kevin Blumberg: Kevin Blumberg, The Wire. You mentioned IRR. It’s been around for a long time. I know you did a bunch of work on it a couple years ago. Could you give us a sort of 30,000-foot view of what are you looking to change with a system that’s been around for so long?

John Curran: Actually, this is related, and I’ll actually combine two updates at once.

So you asked about the Services Working Group. In February 2016, we formed the Services Working Group to help develop plans for these things.

It’s worked fairly well. It was involved in the CKN23 consultation, and it did work on the IRR consultation.

As it turns out, it serves to advise me. That’s the purpose of the Services Working Group, is to advise the President, because I’m the one who has to make recommendations to the Board.

And it doesn’t have as much energy as dedicated work groups do. Like when we did the Fee Review Committee, we ended up with a group that was very focused on one thing: Produce a document that proposed many different schedules.

So I’m going to be looking at this. We have to renew this committee each year in January with the Board, and I’ll be bringing a recommendation to the Board.

In the last two years, we’ve seen a huge increase in the use of the consultation. The consultation Mailing List and the ARIN consultations now get a lot of discussion and a lot of involvement from the community. I’m more inclined for the Services Working Group not to have one; to use the consultation process, but then, if we do a large project, to spin up a dedicated group just for that project temporarily, because it seems to have more energy and more results.

The Services Working Group did conclude a recommendation on the IRR – actually, there was one prepared by staff that they reviewed. We did questions and answers. And as soon as the DMARC consultation is complete, we’ll be putting out the RIR plan.

Now, the IRR plan is basically a two-page plan to refresh our code base for the IRR, integrate the IRR functionality so that it’s aware of the registry – it’s not completely disjoint from the registry, has the ability to load registry objects – and – but not do anything remarkable. It’s not a whole new world view of IRR. It’s an IRR that is more functional and more maintainable than what we presently have.

And so that consultation will be issued about two weeks when the DMARC consultation is done for community comment.

Kevin Blumberg: Just one question. Is the plan to have it within ARIN Online that it’s used, to get to the most people, or it’s going to be similar sort of – use email, carrier pigeon, or whatever?

John Curran: It’s integrated in ARIN Online. So you can select your objects and see where they are and see – actually import, you know, let me see my resources that are and are not announced.

Kevin Blumberg: Thank you.

Nate Davis: Any other questions? All right. Thank you very much.

John Curran: Thank you, Nate.

(Applause.)

RDP ARIN-2017-5: Improved IPv6 Registration Requirements

Favorite time of the day. We are going back into policy now. We have our final policy. Our final policy to be considered at the meeting is Recommended Draft Policy 2017-5, which is Improved IPv6 Registration Requirements.

So because it’s a recommended policy, I have to say a few things. One is that it could become ARIN policy sometime after this meeting, before we all see you again.

So if the AC recommends that it be moved to Last Call, that would happen after this meeting. Once it goes through Last Call, any comments from the community, the AC could then send it to the Board for adoption.

So this is policy that you’re literally getting your last chance at in a face-to-face meeting, potentially. The AC could also decide it’s not ready and bring it to the next ARIN meeting.

But it’s a pretty important thing to recognize, recommended draft policies are different than draft policies. They are potentially policies going into the Number Resource Manual.

Okay. I’m going to give a staff introduction of this so you have the full history.

It was proposed in 2017. It was ARIN Policy Proposal 240. The AC shepherds are Leif Sawyer and Chris Tacit.

Hey, I got Chris down there.

Has not been presented at any prior meeting. Advanced to recommended draft status last month, earlier this month, actually, in September, or last month in September. It is in your Discussion Guide and online.

So some relevant things. It will change the registration – the requirements for IPv6 registration from /64 or more addresses to /47 or more addresses or subdelegation of any size that will be individually announced.

So this changes what has to show up for purposes of registering subdelegations.

It corrects a pointer that’s in the text that’s incorrect, and it adds a new requirement stating that a downstream recipient of a /64 or more may request the publishing of their reassignment information from their upstream provider, and the upstream provider must publish the information upon request of their customer.

Staff comments. The language is fairly straightforward. We can implement it. The change to the pointer is straightforward. There is a question about the language: shall, must, should. If it says “should publish,” then that’s good advice for the ISP, but it’s not something that we necessarily would be enforcing. It’s strong advice.

If it says “must publish” or “shall publish,” then it’s a concrete policy. And it’s a term that, in theory, an ISP who ignored, if we were to receive reports of that, would end up with me having a discussion about that ISP along with Michael about their contractual compliance to the policy.

So that’s a pretty important distinction. Saying something is “must” or “shall” means that this is potentially upon the risk of having the rights to the resource. And this has been addressed in the – these bullets have been addressed in the 18 September revision.

Legal assessment. No material legal issues regarding the proposal.

Minimal impact. We’d have to update our guidelines and our internal procedures obviously. We’d have to do staff training to roll this out.

Now I’ll turn it over to Leif. One more time. How do I say this? Show me the secret.

Leif Sawyer: It says Leif Sawyer, right? Flip – whip your flords around and think “safe lawyer.”

John Curran: I’m incapable of saying those words. Your presentation.

(Laughter.)

Leif Sawyer: It’s all fun and games until somebody loses an eye. Big green button that says forward.

Okay, good morning. As John mentioned, we have a problem statement that was brought up by the original author, Albert, which is to help improve directory registration requirements.

There was a perception that it was an onerous task on the part of companies, ISPs, LIRs, whatever you would like, that submitting registration updates for every single /64 was tedious and a lot more tedious than what IPv4 looked like.

And that seemed unfair to him. So we had this submitted out. And it seems like a good idea. How do we get this to be in balance? How do we make things seem fair between IPv4 and IPv6?

And we went back and forth on this policy. We tried to figure out where that line was, /62, /61. Three bits in IPv4, three bits in IPv6. It seems kind of weird.

And finally we came up that /48 seems to be the standard for deploying to end-user sites. Okay. Maybe that’s the right boundary. That’s where we landed on. And we’ll get a little further into that in the next slides.

Also we pointed out that there were some typos in the NRPM based on cut and paste from older policy, and that is being corrected.

So if this does advance, this will reduce workload for, I guess both ARIN staff and for you, the community out there. You won’t have to send in your updates for every single /64. And that might be a good thing. Personally, everything for me is automated. So I don’t know. There might be people out there still doing it manually.

But, this seemed to get a lot of positive uptake from the community. So that’s what we did. We went forward, changed this, changed the Section 6.5.5.4 for registrations requested due to wanting to make sure we’re filling in the hole that we removed by migrating to the /48, fixing the text.

And here, after the cleanup, is what the policy looks like. It’s also in your Discussion Guide starting on page 11. And on page 12 you’ll see the staff and legal in case you wanted to look back at that.

So as John said, this is a Recommended Draft Policy. And if that’s what the community wants, we can move this forward. And cleaning up the text in the NRPM and making things easier on our community I think is what we’re all about up here.

So we want to talk about that and find out if you are in support of this goal.

We want to find out the “shall” versus “should.” Is that an important issue to discuss and solve here at this meeting before we try and advance this?

So I guess, with that, Paul, you might open this up to comments.

John Curran: Thank you, Leif.

(Applause.)

Paul Andersen: He’s just more nervous now because he’s just learned that that’s also my middle name. So now he’s determined he has to learn how to practice that.

John Curran: And you pronounce it differently than him.

Paul Andersen: Yes, I do, just to throw him off completely.

And with that little trivia, we will open the microphones. As a reminder, we are taking both remote participation and the microphone. This may be the last time you have a chance in a setting like this to comment.

So it is crucial, crucial, that you approach a microphone if you have a comment to make, even if it’s just to say “I support” or “I’m against.” And we will start that with the center microphone.

Jason Schiller: Jason Schiller, Google, ASO AC. I support the policy with “shall.” I also support the policy with the fallback to “should” if that’s what’s required to push it through in this cycle.

I am the originator of this should/shall problem by suggesting the word “must,” that ISPs must SWIP address space to their reassignments if their downstream customer has an Org and requests such, because they have tech contacts and abuse contacts and want those to be honored and used.

My concern with the policy is we’ve basically engineered IPv6 in such a way that ISPs never have to SWIP unless they fall into this bucket of, “I have a downstream customer that’s an ISP,” or “I have a downstream customer that’s going to multi-home.”

If I’m the type of ISP that doesn’t have ISP customers and doesn’t allow BGP multi-homing, I can safely ignore all IPv6 SWIP requirements. And that’s not good for the community, and that’s not what this policy is trying to do.

Unfortunately, if the word is “should” and not “shall,” it makes it optional, and I can in good faith stand up and say I’m doing the minimum that is required under ARIN policy. No harm, no foul.

And I really don’t believe that that’s what the intention of this policy was. So what I am asking today is can we sort out “shall” and “should” here in this room and move this policy forward?

And can we do it in a way that’s positive? Can we not make it “shall” versus “should”? Because that’s going to split the community and that’s going to drive this further down the time horizon, and we’re not going to have a policy change.

If the community is generally in support of fixing SWIP requirements, then let’s have the right word there and let’s figure out today what the right word is.

So I would ask everyone who supports “shall” to come to the mic and tell me that they support “shall” and if they would also support a fallback to “should” if that’s what’s required to get this policy through in this cycle.

I’d also like to hear the inverse, people that support “should” but not “shall.” We haven’t seen any of that on the Mailing List. Presumably there might be some.

If we don’t call a specific question about do you support it with “should” with the fallback, do you support it with “should” but not “shall,” or do you support it with “shall” and a fallback to “should,” if we don’t call that question, the only way that we can find out that answer is by people coming to the mic and telling us.

So, please, come to the mic and tell us.

Paul Andersen: But before you run away, to clarify a bit. The question that will be called, and there will be a question that you will be able to raise your hand up at the end of this process, will be on: Do you support the policy as written? And that is the “should.”

So when you do approach the microphone, if you’re saying you’re supporting the policy, you’re supporting it with the “should.” However, we are re quite happy if you’re on the mic and if you wanted to comment on you would support it with “shall.” That won’t be the question per se, but it would obviously be the input to the Advisory Council as they deliberate.

So just to try and keep the process clean on how we’ll do this. So my understanding –

Jason Schiller: I understand the desire to keep the process clean; I’d specifically asked for a different question to be called. I understand that’s not going to happen.

Paul Andersen: I understand. To clarify, you are against the policy, but you would support it if the word was “shall.”

Jason Schiller: I don’t think it’s worth sabotaging this policy and pushing it to the next cycle. I think it’s a good change. I think we should move it forward. I think we should move it forward with “shall,” but I am not willing to throw away the change just to get “shall.”

Paul Andersen: Thank you.

Matt Petach: Matt Petach, Yahoo!. I note that the current wording in 6.5.5.1 uses “shall.” We’ve been working with “shall” for quite some time and people haven’t been raising pitchforks and storming the gates.

I support the policy. I support the policy whether it’s “shall” or “should.” But I would like to note that for people who are concerned about the strength of “should” versus “shall” or “shall” versus “should,” we haven’t had people jumping up and down about the fact that it’s “shall” today.

So I would love to see it be “shall,” but if it needs to be “should,” as Jason said, I’ll support it either way.

Paul Andersen: Thank you. Remote participant? Oh, sorry. Dan Alexander first.

Dan Alexander: Dan Alexander, ARIN AC. I think one aspect of this, while we’re talking about “should” and “shall,” is if everybody is in favor of this “shall,” there is a follow-up question to that as to what the community expects ARIN staff to do when that’s not happening.

So there is a slightly further context to changing it to “shall,” which does change the scope of this proposal.

Paul Andersen: John Curran.

John Curran: For all practical purposes, “shall” is a mandatory requirement. It’s equivalent to “must.” It is what it presently says for the text.

We have not, to my knowledge, had – actually, I can say definitively. We’ve not had complaints about compliance with this. We would act on those complaints. We literally would approach you and say: We have received a complaint you’re not complying with the policy you requested under; were you lying to us then or are you lying to us now, and what is the resolution of this?

If you put this in as “shall,” just recognize it’s something you all have to expect to honor. It’s that simple.

If you put it in as “should,” then you’re still expected to honor it, but you’ll probably never hear from ARIN about compliance, because it’s “should.” It truly is guidance, not an obligation. A policy obligation would be something that says “shall” or “must.”

Paul Andersen: Thank you. Center microphone, please.

Owen DeLong: Owen DeLong, Akamai, ARIN AC. Pretty much what Jason said. I support the policy as written. I would prefer to see it as “shall.”

And in terms of the follow-on question that Dan asked, what would we expect ARIN staff to do, well, I would expect them to do what they’ve been doing with “shall” in the existing policy.

And I think that’s worked out fine, and I think we can trust staff to continue doing what they’re doing just fine, and I don’t see the big deal about a one-word change to this policy. I think we can make that in the process of sending it to Last Call and that we should do that. So that we – shall do that, maybe.

Paul Andersen: Shall do that, should you decide to? Microphone over here, please.

Bill Woodcock: Like everyone else who has spoken, I support “shall” –

Paul Andersen: I’m sorry, I have to stop you. Your name and affiliation?

Bill Woodcock: I’m Bill Woodcock.

– because having a lot of “shoulds” in there is pointless and wastes all of our time. There’s no reason to do advisory policies that are nonbinding. It takes space and time and – words. Yes. But just do “shall.”

Paul Andersen: Thank you for the comment. Far microphone.

Kevin Blumberg: Kevin Blumberg. I support the –

Paul Andersen: That’s not the far microphone. See, now you’ve all figured the trick out; that I don’t actually see which order. I’m too old to remember, so I just keep going around. So if you want to talk sooner, find a shorter line.

(Laughter.)

Far microphone.

Billy Hyatt: Billy Hyatt, Ozarks Go. I’m a tiny ISP. Probably the smallest one here. I support this policy and I support “shall.”

Paul Andersen: Thank you. Middle microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I support the policy as written. I want to get this ahead.

But I had a question. John, under the RSA, and this has been a concern back and forth on a number of policies over time, where RSA trumps policy. And I understand policy is guidance towards the RSA as well. In good faith, I get space from ARIN. In good faith, this policy is “shall.” Okay. So we’re both in good faith.

And the market changes and a whole bunch of users start coming to me and asking me to SWIP their 64s for whatever silly reason – it’s needed by some online gaming system now so they can track whatever – and we’re not automated, we’re a smaller company, and it’s a lot of work.

In the “should” environment, I can say: No problem. We’re going to charge you a small fee, and if you’re happy paying that fee, we’ll make the change for you.

In the “shall” environment, if I say, “It’s going to be a small fee,” and they go, “Well, I’m going to ARIN, because you shall do this, it’s a requirement,” what happens in that scenario, and what happens in the scenario where I just say I’m not doing it at all, but I’ve got the space in good faith in the first place from the RSA?

Paul Andersen: John would like to respond.

John Curran: Very simple. This is actually an excellent question. So generally what we would end up doing, we’d have a conversation. You’d explain what is available. It’s a fee, but I do it. And we would say okay, and we’d say that’s fine.

And then John Sweeting would come to the next meeting in a Policy Experience Report and say, we get complaints about this, and we go and ask, and people say it’s available for a fee and they’re more than willing to put the route in for the SWIP of the /64 and it’s our understanding this is what the community likes.

So we would generally take the most favorable interpretation to you, because the alternative is for us to take a less-than-favorable interpretation and me to embark on a legal adventure, which I like to avoid in all circumstances.

So, we would end up reporting back to the community that this is our understanding and we’re going along with this as the interpretation.

If you didn’t like it, you could say – more explicit policy, but that would be up to this team.

Now, same conversation, that last sentence you just said, what if we just say, “No. No, we’re not doing this. We’re not complying with this policy,” and it says “shall”?

We’d have a conversation. I’d follow it up with another conversation. I’d ask to talk to your executives, and then you’d get a notice of noncompliance.

You can go look at what your RSA says. The path that that would be leading you down would be a path where we would turn around and say we’re going to remove your number resources and you would have an appeal process.

Kevin Blumberg: For fraud?

John Curran: For violation of the RSA.

Kevin Blumberg: That’s what I’m asking. Historically we’ve heard for fraud for nonpayment.

John Curran: Your RSA obligation to comply with the policies in NRPM.

Kevin Blumberg: Thank you. So at this point, I support it as written. I’m indifferent to “shall.” What I’m not indifferent to is this policy being stalled for any reason because of a change that may not be considered editorial or may create issues. That’s my issue right now.

Paul Andersen: Well, just for clarity, Dan, and I attempt to answer, but what are the options for the AC at this point should they want to change that text? I just want to – Are you able to do that without coming back? I believe so, but I’m not – it’s been a few years now, so.

Dan Alexander: Well, it’s –

Paul Andersen: I forget that little section.

Dan Alexander: It’s something I need to talk to John about as to how comfortable staff is, because it specifically calls this out in the staff and legal, that it’s a different scope.

Paul Andersen: I apologize. We’ve apparently queued up a few remote participants.

How many do we have?

Chris Woodfield: We have two comments in queue.

Paul Andersen: Okay. Let’s address both of them, but just one at a time first.

Chris Woodfield: Okay. First comment in queue is from Marla Azinger. The comment reads: I oppose this policy. /64 is the common v6 allocation handed out in place of what would be a v4 /29 or larger due to the number of addresses available in v6.

Records need to be public. Entering a SWIP of some kind, be it RWhois, which I recommend, or other is far easier than the work that goes into creating and processing subpoenas.

Marla made a second comment to the should/shall question, which is: The word is “must.” That’s comment number one.

Paul Andersen: Okay. Let’s have the other one, then.

Chris Woodfield: Comment No. 2 is from Christoph Blecker of the Walt Disney Company. His comment reads: I support this policy. I would support it with more strongly and would – I would support it more strongly and would prefer it with “shall,” but I would also be okay with “should” as written if that’s what’s needed to push it forward.

And a third comment just came in. May I read it?

Paul Andersen: Yes.

Chris Woodfield: Andy Hadenfeldt from Allo Communications: I support this proposal. I prefer it with “shall,” but would be willing to support “should.”

Paul Andersen: Thank you. So, I’m trying to keep an eye on the clock. We want to make sure we get all the input. From a time management perspective, I would appreciate, if you do plan to speak, to line up just so I have some sense of how much time we need to allocate.

We’re over at this microphone right now.

Rudi Daniel: Rudi Daniel, Caribbean. I support the policy as written. I would prefer “shall.” And I would prefer that we give some consensus to the AC to progress it as “shall” from this meeting.

Paul Andersen: Thank you. Far microphone.

Sean Stuart: Sean Stuart speaking only as myself. I support it strongly preferring “shall” or “must” but accepting “should,” if it needs to, to pass.

As far as fees for nonstandard services from an ISP to a small customer, same as with a single static IPv4 address. If it’s not standard part of the process, charge me a fee.

Paul Andersen: Thank you. I would just ask all the remaining speakers, if you could, try and be as succinct as possible and not try to raise too many additional points. Thank you.

Center microphone.

Andrew Dul: Andrew Dul, CrowdStrike. I support the policy with “shall.” I also support it with “should.” I would prefer “shall.” Unfortunately, I just realized that the v6 policy regarding reassignment or reallocation records actually doesn’t use the word “reallocation” anywhere.

So this policy would seem to apply, I think of where it is in the NRPM, to both reassignments and reallocations, and I think reallocation should always be “shalls.” So therefore I also like that this would be “shall” as well.

Paul Andersen: Thank you.

Austin Murkland: Austin Murkland, QScend Technologies. I support the policy as written, with a preference towards “shall.”

Paul Andersen: Thank you for that. Over back here.

Joe Provo: Joe Provo, Google, ARIN AC, occasional consultant. And speaking with a personal hat, I supported this with “must,” I’ll support it with “shall,” and if we absolutely have to fall back to “should,” then okay.

Paul Andersen: Thank you. Remote participant? Just one of them for now, please.

Chris Woodfield: Not a remote. I’m making my own comment, if that’s okay.

Paul Andersen: Okay. Well, you sneaky guy, you. Go for it.

Chris Woodfield: I also support as written with a preference for “shall.”

What I would recommend, if we cannot adopt without changing it, even if that requires going back to staff, is that we adopt as written and immediately propose a new policy to change the “should” to “shall” subsequently.

Paul Andersen: Thank you. Center microphone and then front.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I’m going to be different. I support “should” or “shall.” I prefer “should.” And this is in the spirit of incrementalism.

We need to move this forward. I’m not sure we’ve – “should” means – “shall” means you’re going to do it all the time with the exceptions that are explicitly in the policy. If we make it – if we make it “shall,” we need to make sure we have all the exceptions we want in the policy. Otherwise John’s going to make you do it.

“Should” means, yeah, you’re supposed to do this and if you have a really, really good reason not to, John gets to consider that.

And so if we want to make this – if we want to make this – “shall,” we need to make sure we have all of the exceptions everybody in the room wants, otherwise John is going to come down on you.

And I’ll leave it at that.

Paul Andersen: Thank you. I’m going to close the microphones very shortly. So this is your last chance to get in to speak on the question that’s been there, or, we should probably talk about other things. So if there’s anything else in the policy that you would like to bring up, just let’s not forget about the rest of the text. But, again, I’ll be closing the microphones in about half a minute.

Owen DeLong: Owen DeLong again, Akamai, ARIN AC. I wanted to rebut the idea that we care whether this is an editorial change or not. The standard for an editorial change is if the AC wants to change something in policy without really bringing it through the formal process, and it’s usually used for cleanups of typos and grammatical errors and things like that; where it doesn’t actually change the meaning of the policy, but it makes it either more clear or more correct or simply adds a period that was missing or something like that.

That’s not what we’re talking about here. What we’re talking about here is a minor change to policy in Last Call. So minor, in fact, that it is a single-word change. It is about as small and minor as a change to policy could possibly get.

It is my opinion that the PDP allows the AC to make minor changes to policy between the meeting and Last Call in the case of a Recommended Draft Policy and that that is what we should, in fact, do in this case. And I hope that we shall do it, but I don’t have the ability to dictate what the AC does.

I believe John wants to rebut my comments after I’m done speaking.

Paul Andersen: I don’t want to get too much into that. I don’t know if that really is – this is just giving the input and then the question for the AC. The AC, I’m sure, will spend numerous hours today deciding whether or not they can, and how that can be changed.

Owen DeLong: Okay. So having said that, I still support the policy as written and prefer “shall” as a minor change going forward. But I wanted to clarify that my understanding of the PDP process is we can make this minor change, not an editorial change, and that editorial is not the standard that applies here in this particular stage of the PDP.

Thank you.

Paul Andersen: You may – just after I say the microphones are now closed, and I would ask all further commenters to keep their comment under one minute, starting with the next, John Curran.

John Curran: So, good news, folks. You can make minor or major changes to this policy and still send it to Last Call.

The sentence that’s operative in the Policy Development Process is very simple: If the AC sends a Recommended Draft Policy different than the one presented during the Public Policy Consultation – i.e., the different than this, okay – then the Advisory Council will provide a detailed explanation for all changes – we change “should” to “shall” or “shall” to “should” – and all these specific changes must have been discussed during the community consultation.

Which we obviously have met adequate discussion of this particular change.

So whatever the AC comes out in that word has been covered by this discussion and they can send it to Last Call. So, not a problem.

Paul Andersen: We won’t get into discussion about it other than to say that, yes, you could see this policy adopted without another policy meeting with “should” or “shall.”

Again, short, please. Far microphone.

Christopher Regan: Christopher Regan, Bronx District Attorney’s Office, law enforcement official. I support this policy. I support “must,” most, if not that then – then “shall,” if not that then “should,” with support of what David was saying, that I think that any sort of exceptions to this policy, if anyone thinks there should be any, should be brought up before this goes into effect.

Paul Andersen: Thank you. Center microphone.

David Williamson: David Williamson, Pinger. Actually have a slightly different question. Let me start by saying I support the policy as written. I prefer “shall.”

But I want to note that PI space in v6, the minimum allocation is /48, which, of course, requires appropriate registration information. So why was /47 chosen when, if you go /48 in PA space, you should have similar obligations to someone who has a /48 of PI space?

Leif Sawyer: So, generally people aren’t issued a /48 individually to then subdelegate down to somebody else. However, there are exceptions written in here that show that you would be responsible to register that block anyway.

David Williamson: Yeah, I just like the idea that there’s some parity there. It’s not important, though. I think as written with “shall” would be perfect. Thank you.

Paul Andersen: Excellent. Michael, can I borrow you at the front for a second? Center microphone.

Kevin Blumberg: Kevin Blumberg, The Wire. I’m not going to get hung up on guilty or not guilty as whether it’s minor or editorial. I have faith in the Advisory Council to deal with this and whatever it may be.

My only caution is that change is change, and in this particular case it is not an insubstantial change. I’m not saying it’s substantial, but it’s not insubstantial. And that’s it. Good luck, everybody. You have your work cut out for you.

Paul Andersen: Thank you. Next microphone.

Brian Jones: Brian Jones, Virginia Tech. I support the policy as written, and also support “shall.”

Paul Andersen: Thank you. Far microphone.

Frank Bulk: Frank Bulk, Premier Communications. I support the policy and prefer “shall.” I think this aligns well with our current intents and practices and how we get address space.

Paul Andersen: Thank you. And the final comment.

Louie Lee: Louie Lee, Vice Chair, ASO Address Council, Google Fiber, a startup ISP.

Paul Andersen: A little scrappy upstart, right?

Louie Lee: Scrappy. I prefer “shall,” but “should” I would support also.

Paul Andersen: Thank you. So, I believe that ends our queue. I always like to double-check on remote participation because there’s a little bit of a lag, but I see none there.

So we will thank our speaker. Thank you for the presentation.

(Applause.)

John Curran: Thank you, Leif.

Paul Andersen: So this is the point, because it’s Recommended Draft Policy, that we will take a poll of the room. The normal one would be for Recommended Draft Policy would be, “Do you support moving the proposal forward as written?” And that would be the standard question.

However, we will be asking two questions at the request of the Advisory Council Chair. So I just want to make that clear so you know what’s coming up. And I would ask you to try to deal with them independently.

We will ask whether or not you support the text as written on page 11 of your book, and then I will ask you if you would support the proposal as written on page 11 with the word “should” replaced with “shall.”

So, we will do the first question. Everyone ready? If you can hear my voice, if you are in this room or in remote, you are entitled to put your hand up for either – nice and strong, so our counters can count. I’ll first ask for those in favor and then against.

So on Question 1 of 2017-5, may I ask you to raise your hand if you are in support of this policy as written.

Please raise your hand nice and high and keep it up until I ask you to lower it. This is our little exercise break here. You shall keep your hand up until I ask you to lower it.

(Laughter.)

Thank you. You should now lower it.

And if you are opposed to the text as written, could you please raise your hand nice and high.

Remote participation, you should be participating in the forum online right now.

Okay. That ends Question 1. So take a deep breath, get those hands ready. We’re now going to ask a second question. I’ll just wait for one second to make sure our counters are ready because I did throw them off with a second question. Okay. We’re just going to wait. I think they just like to close that one out.

Thanks again to staff for a lovely social last night. Give a round of hands to the staff for organizing. That was a great – any time there’s a taco truck, that’s good with me, I’ve got to tell you. One too many, probably.

Just another second. And then we are going to break, a little bit late. A bit of a delay. I apologize. Make sure every hand is counted.

Okay. I apologize for that delay. We are now going to ask our second and final question. This is your last chance. On Proposal 2017-5, I would ask those who are in favor of the policy as written but amending the word “should” to “shall” in Section 4 there, please raise your hand nice and high and keep it until our trusty counters have…

This is your moment. Please, no hanging chads. One hand only. Please keep it up. I know. Okay. You’re allowed to lower it now.

And those opposed to passing this – moving this policy forward with the word change, please raise your hand now nice and high. Are we good, official counters? Excellent. Okay.

Any announcements you have that you can knock off while we wait for this tally?

We’re going for break; there will be probably be some kind of calorie-free foods.

John Curran: No hurry, Michael. You’re between these people and cookies.

Paul Andersen: I make it as a point never to be – but we should know the results before we go – I shall have a cookie.

John Curran: I’m guessing cookies. It could be anything out there. Any idea what’s out there? Cranberry. Okay. I noticed at one of the breaks prosciutto and salami.

Paul Andersen: That was very tasty. All right. Appreciate all your patience. Like I said, we did throw a little bit of a last-minute snag here. The envelope is coming. I will try to read the correct one and not announce La La Land as the winner.

All right. Thank you, sir. Oh, these are new and big. They must think I’m getting old because the font on this is like three times the size it used to be.

All right. On the question of Recommended Draft Policy 2017-5, improved IPv6 requirements with the word “shall,” we had 125 participants in the room, seven remotes. We had 56 in favor, nil against.

On the question with the word “should,” still 125 in the room, seven remote; 47 in favor, two against.

This input will be provided to the Advisory Council for their consideration, and I thank you. This ends our policy block. Thank you.

(Applause.)

John Curran: Okay. Folks, we have a quick break, and then we’re going to come back and end the policy meeting.

So the break is between now and 11:00. Run out there, come on back. I look forward to seeing everyone here at 11:00. Nineteen minutes.

(Break from 10:41 a.m. to 11:03 a.m.)

John Curran: If folks will come in and be seated, we’ll get started. It’s actually a very short segment. We basically have Open Microphone, Closing Announcements, and then we’re done until the afternoon meeting, the afternoon Members Meeting. So, let’s get this done.

Open Microphone - Friday

John Curran: Okay. We’re now going into Open Microphone. This is the final Open Microphone session of the Public Policy Meeting. There will be one at the Members Meeting.

But this is for any policy issues that might have come up that haven’t been fully addressed, any new ideas for policy, any related questions, any questions that have come up related to policy.

We are now in the final Open Microphone session for the Policy Meeting. We will have an Open Mic for the Members Meeting to talk about ARIN operations and governance. But, on the issue of policy, number policy, the microphones are open.

Paul Andersen: Should you choose to use them. Remote microphones are also open.

No one has any great policy ideas?

Paul Andersen: Less is more.

John Curran: Less is more. A policy might be early lunch any minute now.

Paul Andersen: No, keep trucking.

John Curran: Final call on the Open Mic. Any other address policy issues?

I thought Susan was approaching the mic. Any other address policy issues?

Last call. Three, two, one.

Open Mic is closed. Thank you. That ends the Public Policy Meeting.

Public Policy Meeting, Day 2 - Closing Announcements and Adjournment

John Curran: We have some closing announcements. I see my closing announcements coming up. There we go. Very good.

Okay. Vote now. If you have not voted, definitely time to vote. We still have an elections help desk out there. Please take an opportunity to vote.

One more time to thank our sponsors, Zayo and Google.

(Applause.)

Our afternoon break sponsor, Avenue4.

(Applause.)

Okay. We’re going to get a meeting survey. You can use that link, surveymonkey/r/arin_40_survey, or you’ll get a link in your email, if you registered for the meeting, and you’ll be entered – if you get your response in by 13 of October, you’ll be entered into a chance to win an iPad.

Okay. That is the end of the Public Policy Meeting. We’re going to have our next one of these at ARIN 41 in Miami, Florida. That will be the 15th through 18th of April. We also have a number of ARIN on the Roads where we talk about things. Thank you.

Now, we’re going to have the Members Meeting right after lunch. The Members Meeting opens at 12:30. There’s a boxed lunch out there, and help yourself.

But we don’t have anything right now. We’re truly – it’s lunch, the lunch gap, and we’re going to open up at 12:30. It’s going to be a quick two-hour Members Meeting. We go through all the reports, and we will get things done.

So thank you, and we’re done with the policy now. And people who want to stay for the Members Meeting, which is open to all, we’ll see you here at 12:30. Thank you.

(Public Policy Meeting adjourned at 11:07 a.m.)

Network Sponsor

Webcast Sponsor