ARIN 35 Public Policy Meeting, Day 1 Transcript - Monday, 13 April 2015 [Archived]

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.

Opening Announcements

John Curran: Good morning. Welcome to San Francisco, the ARIN 35 meeting. I’m John Curran. I’m the President and CEO of ARIN, the American Registry for Internet Numbers. I’d like to welcome you all to this wonderful city. It’s absolutely beautiful. It’s even warm on occasion, which is a surprise.

We have a very full agenda for the next two days of policy discussions and reports, and then we have our member meeting on Wednesday. It’s going to be a lot of exciting discussion, and I think everyone will like the meeting.

So I’d like to get started immediately, and note that we have our Board of Trustees in attendance at the meeting. So I have Paul Andersen, our Vice Chair and Treasurer. Vint Cerf, who is in the building but not in the meeting right now. Myself. Tim Denton, our Secretary. Tim, where are you hiding, Tim? He’s outside. Aaron Hughes is here. Right, Aaron? Aaron is here. He just was with us momentarily. Bill Sandiford. Yep. And Bill Woodcock I see.

The full Board of Trustees is here. We generally meet at each ARIN meeting. We have our Advisory Council. Lots of people. If you’re in our Advisory Council, please stand up. Please stand up. Please stand up. Thank you.

This is the ARIN Advisory Council. They’re elected by you to work on policy proposals. And they will be here presenting the policies that are under development. You’ll hear a report about that shortly.

We have the NRO Number Council. Our Chair, Louie Lee. Where is Louie? I just saw him. And Ron da Silva and Jason Schiller. Yes. These are the folks who work with their counterparts from the RIRs on the development of global policy.

The NRO Number Council is more commonly referred as the ASO AC, the Address Supporting Organization Advisory Council, and they meet within the ICANN organization and work on global policy. They also work on appointing the two seats that the numbers community has on the ICANN board.

Our RIR colleagues. Many RIR colleagues. From AFRINIC, Ernest and Madhvi. Are you here? Raise your hand. Somewhere. Yes.

LACNIC, Carlos – I’m very sorry. Gianina and Sergio from LACNIC. Yes, yes. And APNIC, Gua – yeah. Guangliang and Paul Wilson. I see Paul. Okay. RIPE, Dmitry, Andrew, Sam, and Axel. Yes, yes, yes, and yes. Very good.

The ARIN management team is here. Myself as President and CEO. Nate Davis, our Chief Operating Officer. Cathy Handley is not here. Cathy has got other engagements this particular week. Richard Jimmerson, our CIO and the interim head of RSD, Registration Services. Erin Alligood, who is in charge of HR and Administration, is hiding over there.

Susan Hamlin, who is Communications and Member Services, and the reason we have a successful meeting. Susan is usually out back somewhere making – oh, right here, look at that.

Mark Kosters. Mark, where are you? Our head of Engineering. Leslie Nobile, who is our Senior Director of Global Registry Knowledge. People will note there was a switch, because Leslie used to have the head of RSD. Leslie works for me, and she’s responsible for trying to figure out how to make good registry data globally. She’s working both on projects within ARIN and with the other RIRs, trying to do some of the analysis that we think is necessary, trying to look at some of the issues that have – worked on matters of accuracy and synchronization.

And then our head of FSD, Val. Are you back here somewhere? Over there. The one who gets numbers out and sends the invoices.

Okay. We have a fellowship program. It’s very active. We’re very proud of it. It allows people from – who aren’t aware of ARIN to come participate in ARIN, have their costs covered, get involved, see what it’s like. We also have mentors that are appointed for each of the fellows.

So our fellows this time around, Jon Aitchison. Jon, where are you? There you go. Kevin Blumberg will be helping out Jon. Andrew Trudgeon from Canada. Andrew, nice to have you here. US, Steve Ives. Steve, thank you. Being helped out by Andrew Dul. Michael Schloh. Yes, Michael, who is being helped out by Milton. And from the Caribbean, Andre Graham. Yes? Yes? Yes. Very nice to have you. Who R.S., Rob Seastrom, is helping out.

I’d like to welcome our first timers. We have a number of a first timers who got a chance to meet the ARIN management team and elected representatives. They learned about ARIN. We do a prize drawing for the people who attend the First Timers’ Orientation, and I have this wonderful Webpass bag which has in it the survey results. I need someone to come up and draw one.

I see Heather Schiller. That’s wonderful. Reach in and grab one. Very good. Thank you, Heather. And the winner who will get a $100 gift certificate to thinkgeek.com, yes, Michael Schloh. Michael.

(Applause.)

We’ll send you that via email. You don’t have to do anything. Thank you. Thank you for attending the First Timers’ Orientation.

Okay. We have remote participants. Remote participants are equal participants in this process. They have access to the webcast. There’s a live transcript. The meeting materials that you see are downloadable. There are chat rooms where they can participate, including a virtual microphone, as well as being able to participate in the show of hands for expressing support for policy.

So I’d like to welcome our remote participants. I know you’re out there.

(Applause.)
If you can’t make it to an ARIN meeting, you can still make it to an ARIN meeting. You have a remote participation option. Okay.

We signed a Memorandum of Understanding between ARIN and NARALO, which is the North American At Large Organization within ICANN. The at-large organization helps to bring people together for participation in policy development. They’ve been doing this in the ICANN community quite a bit. They asked to work with ARIN. We thought that made good sense. We actually signed a memorandum of understanding.

So that community is aware of our meetings. They may be out there in remote participation. You may see more of them here. And it’s just helping us get more base into the ARIN community doing policy development.

I’d like to have a round of applause for the NARALO folks.

(Applause.)

If you are interested in getting involved in ICANN policy and you maybe don’t want to go to every meeting but want to know what’s going on, you can participate in NARALO and they’ll help tell you what’s going on at the meetings. They participate in the at-large constituency’s development of positions and similar.

Attendance stats. From the United States we have 124 attendees. From Canada we have 8. Caribbean, 2. Outside the ARIN region, 26 attendees. We have 21 remote participants.

So out there is a sign, and it’s for our Get6 initiative. Get6 is our outreach campaign to get people, get their websites enabled with IPv6. You can go out and have your picture taken in front of that. It will get posted on social media. You’ll be part of the Get6 initiative. So take a moment to do that at one of the breaks.

Like to thank our sponsors. Webpass, our network connectivity sponsor.

(Applause.)

Like to thank our webcast, provided by Google.

(Applause.)

And our refreshment break sponsors, Fastmetrics, Serverhub, and the IPv4 Market Group.

(Applause.)

There is an app for the meeting. If you want to have a convenient way to know what’s happening, you can download the app. The link was sent to everyone when you registered. It’s actually a very nice little application, and so I recommend people who want to carry it on their phone and want to carry the meeting materials, you’ve got it right there.

Tonight we have a social at Jillian’s from 7:00 to 11:00. ARIN 35 attendees are invited to an evening of pool, games, and networking. There’s going to be more information later in the day. We look forward to seeing everyone. There’s a buffet dinner, open bar, DJ. Should have a wonderful time.

So today we have the AC On-Docket Proposals Report. This is everything they’re working on. The Regional Policy Development Report, which is the summary of what’s happening regionally in address policy. We have the Policy Implementation and Experience Report, which is where the ARIN staff gives feedback as to things we’ve discovered in implementing policy.

We have the Internet Number Resources Status Report, telling you what the inventory of numbers are. We have the IPv6 IAB/IETF Activities Report, telling you what’s going on at the IETF. And we have the CRISP Panel. The IANA Stewardship Transition Update, from the panel that’s working on developing the transition proposal to transition IANA stewardship from NTIA to the Internet community.

Couple of little details. When the meeting is underway and we’re talking about policy proposals, the Chair and in this case the Vice Chair will be moderating the discussions. So everyone has a chance to speak and be heard. Please state your name and affiliation when you approach the microphone each time you speak.

Please comply with the courtesies in the program. It’s just a courtesy. We’re all trying to discuss. We all have different views. Let’s respect one another.

So this afternoon we’ll have a number of policy discussions. We’re going to discuss 2014-6, Removing Operational Reverse DNS Text; 2014-21, Removing the Critical Infrastructure Pool Size or Changing the Critical Infrastructure Pool Size per Section 4.4; and we’ll be discussing 2015-1, Modification to the Criteria for IPv6 End-User Assignments.

At the head table we have Paul Andersen, our Vice Chair; we have Dan, who is the Chair of the Advisory Council; we have Kevin Blumberg, who is the Vice Chair of the Advisory Council; we have John, who is our jabber moderator.

I’m now going to – sorry. Spacing out here. Now going to bring up our network sponsor, who is Charles Barr, who will come on up. He’s from Webpass. Come on up. He founded Webpass in 2003; has decades of experience in product development and industry communications industry. He’s built a start up successfully, and he’s now grown it into a nationwide success.

He’s now involved in technologies trying to enable people and bring them to the Internet. So I’d like to thank our network sponsor and have him say a few words.

Thank you, Charles.

(Applause.)

Charles Barr: Thank you very much for that introduction. Thank you Board, and thank you members.

So a quick word about my responsibility this morning. I’m here to welcome you to San Francisco, to make sure that you get out and enjoy yourselves while you’re here in our city. Ride the cable cars. Get some food. Go out and enjoy the nightlife. And the nightlife in San Francisco will accommodate all desires. Go have some fun out there.

Second thing I’m supposed to do is speak about Webpass and Webpass’ experience. We’re in six cities now: four publically, one just started, one privately. But within a few days we’ll be in six cities. In those cities, believe it or not, it’s all on IPv6. 100 percent native IPv6 to every city.

(Applause.)

This organization makes all that happen. This organization sets the rules for all that activity, and you’re doing a great job. And I know there’s going to be conflict today and I know there always is about 4 and 6 and running out. But rest assured, it works and it works very well. And Webpass supports over 20,000 customers, and guess how many complaints we get about not having IPv4? Minimal. All right? Minimal complaints.

We get Fitmo Sale complaints because AT&T doesn’t use it and we get complaints from VPN. And that’s it. The rest of the 20,000 people have their IPv6, and they’re happy as clams. Most of them are completely unaware it works, but it does work.

That’s my message to you. I want you guys to really realize that because people in this room and the people that are attending remotely are the ones that make that process possible and the ones that make it work. Recognize that we are the leaders. The people in this group are the leaders of this transition. We’re doing a good work. Keep pushing 6. It works. Everyone uses it whether they know it or not.

So just feel good about what goes on in here, feel good about the work this organization does, and feel good about the membership in ARIN. And then go out and have some fun in San Francisco.

Have a great day.

(Applause.)

John Curran: Thank you, Charles. That’s wonderful.

All right. I’d like to get us started right in, and we will start out with the AC On-Docket Proposal Report, and that will be from Daniel Alexander.

AC On-Docket Proposals Report

Dan Alexander: Good morning, all. So there’s 15 of us on the Advisory Council. John had us all stand up earlier, and you can find us at any time during the week. We’re basically here to answer questions, help people out, and to facilitate the Policy Development Process.

When someone has an idea – Richard did a great job yesterday for the first timers laying all this out where we basically take the ideas from the authors, craft it into some kind of language that is clear and concise, and it becomes a draft proposal.

Then it comes to meetings like this and it’s worked through on the Mailing List to the point where we have language that the majority of people agree upon and we think can become actual proposal. And then it gets promoted to that recommended state.

In that state, then we’re able to get the final feedback from the community and actually forward that to the Board saying we believe this is policy ready to go and whether or not they will accept it.

When we do – sorry. When we do send a recommended proposal to the Board, it goes into a last call period, which is that final state of people being able to provide their last minute feedback. And then it goes to the Board to be ratified.

There’s four proposals this week that are in a recommended state. So these four will be discussed. And if everybody agrees – or I shouldn’t say if everybody agrees. If there’s consensus and we think that it’s the right thing to do, these are of a state that can actually be sent to the Board.

There’s two that are being discussed this week that are in a draft state. So these two we cannot send to the Board or we cannot accept after this meeting, but they’re here so we can get good feedback: People think the language should change, if people think it’s a good idea or a bad idea.

There’s two changes, though. The online agenda is correct, but the handout agendas in your name badges, there were two adjustments made where 2015-1 is being discussed today and 14 14 is actually being discussed tomorrow, and that’s – if I understand it right, that’s reflected in the online agenda.

Also during lunch there’s tables set up for particular topics – those are listed here – where if you’re interested in discussing a particular topic that’s going on here, you can seek out those tables, have the conversation, answer – get questions answered, provide your feedback, further the discussion.

Then there’s also – if people feel it necessary or if they really want to, they can seek any of us out and ask for – we have breakout rooms where if we needed to actually try and get people together in a room and have further discussion on any particular policy, that is available to us.

John Curran: Any questions for the AC On Docket Report?

Thank you, Dan.

Next up is the Regional PDP Report. Einar Bohlin.

Regional PDP Report

Einar Bohlin: Good morning. I’m Einar Bohlin. I’m the policy analyst – senior policy analyst at ARIN.

As part of my job I read all of the RIR’s policy lists and I attend some of their policy meetings and at least follow what happens at their meetings, and I capture some information as the year goes by about what kind of proposals are discussed online and at the meetings.

And I’ve done that for a few years. This chart shows that IPv4 was a really big topic in 2011. That’s because of depletion, of course. And then a topic of IPv4 trailed off and stabilized around 35 proposals a year at the different – at all five of the RIRs.

That last column, the light blue one on the right, is 2015. And we’re only into the first quarter – or first third of 2015. So we expect that that would look similar to the last three years.

The topics that are discussed in IPv4 since depletion pretty much revolve around adjustments to last /8 policies or austerity policies and of course tweaks and the topic of inter RIR transfers.

We also have IPv6 proposals, directory services, and proposals that just don’t fall in either of those categories.

Here’s some highlights of discussions that are happening today or recently. In the RIPE region, they’ve advanced their inter RIR IPv4 transfer policy. So we actually expect to begin doing transfers with the RIPE region like we’re doing today with the APNIC region in approximately four, five months I think is the timeframe.

That’s a topic which is being discussed in the LACNIC region. They have a proposal about IPv4 inter RIR transfers. That’s still continuing. In AFRINIC, they’ve adopted and are going to implement the policy which allows anycast users to request to be force based. Sometimes if you do anycast, you only use a couple IP addresses. So under normal IPv4 policy, it’s hard to get a /24 if you’re only using one address. This allows anycasters in AFRINIC to get address space from AFRINIC.

An interesting IPv6 development is inter – not inter, but intra IPv6 transfers. So intra RIR. Organizations in the RIPE region are going to be able to transfer v6 space with each other.

At APNIC in February, there was an interesting proposal about directory – on the topic of directory services. The ARIN community is familiar with SWIP, I think, where ISPs assign IPv4 space or a network address to their customers and they create a record that shows who they’ve assigned it to. It shows the prefix, the organization, maybe their street address, and some point of contacts.

With the advent of CGN and other technologies that more efficiently use IPv4 address space, it’s been discussed that ISPs are going to issue the same IP address to customers, a single IP address, but different port ranges.

So this proposal, APNIC Prop-115, was brought forth and discussed as a way to help organizations do filtering by identifying what the port ranges are that are being assigned to customers.

So if you’re assigning the same IP address to customers and you’re doing perhaps 32 ports, there would be a record in Whois that would say this address space is being assigned with duplicate IP addresses but the port ranges are different on 32 ports per customer. It’s kind of interesting. That is the first time this has been discussed as a proposal, and it’s continuing to be discussed.

Other topic that’s happening is autonomous system numbers. And it looks like these RIRs are trying to make it easier for folks to get autonomous system numbers.

This is a pretty short presentation. Here’s references. Everyone has a site where you can see what proposals are under discussion and what state they’re in and the topic and the exact text. And we also have a document – the NRO has a document called the Policy Comparison Overview, which is a high level summary of all of the RIR’s number policies in one document. And that’s updated quarterly. And that’s everything from me. Thank you for your time and attention.

John Curran: Any questions for Einar? Okay. Thank you, Einar.

(Applause.)

Policy Implementation and Experience Report

Richard Jimmerson: I’m Richard Jimmerson with ARIN. I am the CIO but I’m also the acting director of Registration Services here for the next couple of months. I’m happy to present to you the Policy Experience Report.

The purpose of the Policy Experience Report. We do it at every Public Policy Meeting. At the request of the community we pull these things together. And what we’re doing is reviewing existing policies. We’re looking for things that might appear to be ambiguous to customers, things that seem inconsistent for customers where there might be gaps or there might be unintended consequences of a policy that was passed and what kind of impact that’s having on customers.

We identify areas where new or modified policy may be needed based on operational experience and customer feedback. And I’d like to sharpen the customer feedback piece, because we do get extensive amounts of customer feedback every week. And a lot of it does have to do with policies that we’re applying in the review process.

We get customer feedback over the telephones. We’re getting about 750, 800 telephone phone calls per month in RSD. And we’re talking with the customers of ARIN who are actually requesting resources in accordance with the policies that you’re passing here this week, for instance.
And we get all kinds of different survey data from them over email and things like that as well.

Now, we provide this feedback to community to make recommendations when appropriate. Today we’re talking about four policy areas. One is point of contact validation. We’re also talking about 8.2 transfers, specifically reorganizations. Experience with /24s, now that we’re issuing /24s from ARIN. We received a lot of feedback from the community on that. And also I don’t know if this one’s ever been brought up in a Policy Experience Report before, but we hear more feedback from customers on immediate need than almost anything else across the board if you consider the registration staff, all the way up to CEO of the organization.

Let’s get started with point of contact validation. In the Number Resource Policy Manual, we have 3.6, Annual Whois Point of Contact Validation. During ARIN’s annual Whois point of contact validation, an email will be sent to every point of contact in the Whois database. What we’ve done is we’ve arranged these up and we staggered them to go out throughout the year on a weekly to monthly basis. But during the course of the year, every point of contact in the ARIN database is sent an email for validation. So over the course of an entire year we will cover everyone.

So it’s important to note that the points of contact that receive ARIN validation emails are associated with these three different classes. They’re either a point of contact associated with a direct assignment from ARIN, who is an end user organization that received address space from ARIN; they are point of contacts associated with direct allocations from ARIN – this is an ISP type organization that receives an allocation directly from ARIN; and we have point of contacts put on reassignment records by their ISPs. So as an ISP when you receive address space from ARIN, you make reassignments, you subdelegate address space down to your customers and you record that in Whois. If you do a detailed reassignment, of course, you put point of contact information for your customers on that record. So all of them get point of contact validation.

For POCs associated with direct allocations and assignments from ARIN, these are they receive address space directly from the ARIN organization, generally the customers are accepting and understanding of this process. We get pretty good feedback from them. Occasionally we get calls at the help desk with questions related to the point of contact validation.

But we’re not seeing many problems with direct allocation and direct assignment customers with this policy. However, for point of contacts only associated with reassignment records, generally the customers are unhappy with this process. It generates multiple complaints per week inside Registration Services or through other people inside the organization.

And what we’re finding is the response we’re getting from points of contact only associated with reassignment records is they’re contacting ARIN not to validate their point of contact information but more to ask us to remove their point of contact information from the ARIN database because they don’t want to be in the ARIN database.

And for some of them, they’re finding out for the first time that they’re in the ARIN database, either because they haven’t paid attention to a previous email or they may not be the person that’s interacting directly with you as the ISP, but they’re not happy they’re in the ARIN database.

And their request to us at the time of contact is: Remove me completely from the database. And of course the response from the ARIN staff is: We’re sorry, we can’t remove you. That record was not created by the ARIN staff. That was created by an Internet service provider.

And we ask them to work with their Internet service provider to change the information or remove them if that’s what they desire. So when they get on the telephone with us, they’re unhappy; by the time they get off the telephone with us they’re angry. And it’s generating lots of complaints inside the organization. Nearly half of the telephone calls that we receive in Registration Services are points of contact associated with reassignment records in the ARIN database.

We’re getting about 600 hostmaster emails per month related to point of contact validation. And most of these emails are asking us to remove them from the ARIN database. And what we’re doing is responding to the customers and we’re letting them know that we’re not authorized to remove that information from the database. We help facilitate communication with their Internet service provider, and it’s creating a very serious customer service issue for the organization.

So considerations for potential policy changes. These are all questions. Perhaps not performing annual point of contact validation for points of contact only associated with reassignment records. Perhaps having ISPs perform annual point of contact validation for their reassignment blocks. Or having ISPs notify customers at reassignment of their contact obligations and annual validation. Those are some options.

I’m going to go through some other Policy Experience Reports here, and I think we’ll take questions at the end of those. Sorry, Louie. I saw you getting up. But I want to make sure that I get through here on time and we respect the future speakers.

NRPM 8.2, Mergers and Acquisitions. This is the second one I’d like to talk about. Here’s some of the policy language from 8.2. You can see the full language on NRPM if you go online. ARIN will consider the request for number of resources in the case of mergers, acquisitions, and reorganizations under the following conditions. It does state reorganizations in the policy text; however, the title says mergers and acquisitions.

The first bullet under mergers and acquisitions – there’s several bullets, but the first one states the new entity must provide evidence that they have acquired assets that use the resources to be transferred from the current registrant.

And that applies to everything being described above it, if you’re just looking purely at the policy. The problem it’s not clear to some customers that reorganizations are allowable for transfers. They’re not seeing it in the title line. They’re calling us; they’re confused about that.

And customers are also confused by the requirement in Bullet No. 1 that I just described on the previous slide for cases of reorganization. There’s a sense that perhaps there’s not a policy that covers them, and they’re calling the Registration Services staff to ask about that, and we’re reassuring them for reorganizations that we understand that merger and acquisition type activity has not occurred.

But if we’re getting telephone calls at the Registration Services help desk about this, we’re concerned that there are many organizations who are just not making the telephone call or not submitting their transfer requests.

So there may be a need to do some clarification there.

Recommendation: Add “reorganizations” perhaps to the policy title and perhaps clarify that Bullet No. 1 in policy does not apply to specifically reorganizations.

Third item like I’d to talk about is experience with /24s. So this community has extended the smallest allocation and assignment size from ARIN to be a /24. This happened just recently, but we’ve had a lot of experience with it over the past couple of months. And here’s what we found. So ARIN’s minimum allocation size is a /24. Existing requirements and criteria remained in place for both ISP and end user organizations.

I’ll describe this in the future slides, but these two circumstances have made it easy for end user organizations to obtain a /24 from ARIN. This was probably intended by the policy community. However, these two circumstances have made the requirements for ISPs more difficult to meet than for end users. And perhaps that was not intended. So I’m going to talk a little bit about that.

So I’m going to show you three policy – applicable policy areas. You can find the full text. This is just excerpts from it. But for experience with /24s, initial allocation to ISPs. We have ISP requirements. All organizations must satisfy the following requirements. One of those is this, use of a /24. The efficient utilization of an entirely previously allocated /24 from their upstream ISP. This allocation may have been provided by an ISP’s upstream provider and does not have to be contiguous address space.

So the policy is stating that an ISP organization must demonstrate full utilization of a /24 before they can get a /24 from the ARIN organization.

Here’s the second policy set. End user assignments, utilization rate. Basically they need to show us that they have a 25 percent immediate utilization rate and that they expect to have 50 percent utilization of that /24 within one year.

So the end users are having quite an easy time coming in and getting /24s from ARIN, and I think that’s great, to think that ISPs would like to perhaps be judged under the same criteria when the request comes in.

Here’s another policy that keeps on coming up and cited to us from our customers. We have 4.2.3.6, reassignments to multi homed downstream customers. Excerpt of the text: This policy allows a downstream customer’s multi homing requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements.

Note that this policy allows upstream ISP organizations to use multi homing needs as a – for a customer as sole justification for a /24. But this policy does not allow ARIN to do the same. This is for upstream ISPs.

So status of /24 requests. End users seem okay with the policy. ISPs are complaining that the policy is simpler for end users. They’re calling us on the phone and they’re doing this. Customers, both end user and ISPs, are complaining about the nonapplicability of the policy that allows upstream ISPs to use multi homing as sole justification for a /24, and we are hearing from customers that many ISPs are now unwilling to reassign them a /24 citing either unavailability – the ISP doesn’t want to give their own /24s out – and the fact that ARIN now issues /24s and they’re directing their customers to ARIN.

We’re seeing a whole new set of customers coming to ARIN now because of this, and we’re doing a lot of outreach and education with them to help them get their /24s from ARIN.

So some consideration for potential policy changes. One, allow ISPs to request /24s with the same ease as end users. How you would choose to do that I don’t know, but it’s a potential policy change. And the second, allow multi homing to serve as sole justification for an IPv4 /24 from ARIN for both ISPs and end user type organizations. Basically taking that policy that allows upstream ISPs to use multi homing as sole justification and allow ARIN to do the same.

Those are some potential ideas. And I just wanted to pass along the experience we had with customers on /24s.

And the last item that I’m bringing is immediate need. Now, immediate need is a policy that many of you have used in the past or many of you have asked about. But we hear about this quite a bit. And I think our CEO hears about this quite a bit even. If an ISP has 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 or smaller than ARIN’s customary minimum allocation, to that organization. These cases are exceptional.

Here’s some examples of cases ARIN has approved immediate need. Customer contracts with justification for services turned in – turned up within 30 days along with other supporting documentation. Basically the customer comes to us and says we’re acquiring a new market area and these customers are all getting turned on in the next 30 days. That can be considered immediate need. Or someone comes to us for the first time say I have this contract and these customers are going to be turned on inside the next 30 days, and they provide other supporting documentation. That has been considered immediate need.

There’s some other cases, but this is typically what we’ve approved for exceptional cases for immediate need.

Example cases that ARIN has not considered exceptional, the very common one is a customer cites the need to stage network equipment and they provide invoices to prove the purchase of the equipment to serve future customer needs but not within the next 30 days.

So they will come with – we have many large customers and even some of our smaller ones, they’re doing large network buildouts, but they don’t have customers that will be using any of those services in the next 30 days. There are only a small number of customers.

So we’re approving some address space to cover some infrastructure and address space to cover the customers that they’ve confirmed that they’re going to have in the next 30 days, but they’re looking for a much larger assignment or allocation. And this is creating some confusion and some consternation with some of our customers about the immediate need policy.

Considerations for potential changes. Continue current practice of immediate need to be based on clear customer impacts or other exceptional circumstances. Basically where we have it now. Make it explicit in the policy that immediate need may be based on numbering new equipment that has been purchased, taking away the requirement that we currently have that the customers are there within the 30 days. That’s potential thing that we could do. And I think a lot of customers that have reached out to us would be interested in that. Or eliminate the immediate need policy altogether if it’s not serving the original intended purpose.

Those are just some ideas for immediate need.

Those are the four policies that I brought to the attention for this meeting, and we’re happy to take any questions you have on them. Middle microphone.

Louie Lee: Louie Lee, Equinix and Chair of the NRO Number Council.

For your POC validation for the reassignment customers and the list of suggestions of what to do, are the emails going out pointing them to their ISPs? Does it have language to say that if you have questions about your entry in here, go to your ISP?

Richard Jimmerson: I’ll pull the email we’re sending, and I’ll send it to you. I can send it to the Advisory Council.

Louie Lee: I’ll say if it doesn’t have it, then have that language put in. And since you are pulling it from a record, you can also list the ISP’s name from the parent record. Just – they’re still going to come to you, some of them, but some of them will actually read it and go through the ISP first.

Richard Jimmerson: Thank you, Louie. Middle microphone.

Andrew Dul: Andrew Dul, ARIN AC. On the POC, are you notifying the upstreams when they have the list of POCs that are dead?

Richard Jimmerson: Are we notifying the upstream when we have a list of POCs that are dead? Almost everything that we send point of contact validation on ends up invalid because the people are not validating their point of contact information, especially on the reassignment side.
So we might be – if we did that, we might be reporting up that all the reassignment point of contacts are – the majority of them are dead.

John Curran: Right now there’s no reporting to the ISP to my knowledge.

Andrew Dul: That might be something we could think about.

And on the utilization for the /24s, what’s the current rules you’re using for full utilization?

Richard Jimmerson: The policy says fully utilize /24. Typically what we’re doing is looking at the fact that they’ve received a /24 from upstream and that they’re typically above 80 percent on all that utilization.

Andrew Dul: Using the 80 percent number there. Thanks.

Richard Jimmerson: Robert Seastrom.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN Advisory Council, speaking on my own behalf.

Three things. One is on the POCs, do we need any policy change to enact the third bullet point down there, or is that strictly operational?

Richard Jimmerson: Having ISPs notify customers of reassignment of their contact obligations and annual validation, that’s something that could be done in an automated fashion.

Rob Seastrom: I would advocate for that, but I would expect no better results than we’re already getting.

For the /24s, very simply, I’ve long been an advocate of making end sites and ISPs have similar requirements wherever possible. It seems that’s the easiest way out of this, is to apply the same requirements. Obviously that needs a policy change. I would support that.

Lastly, the immediate need. Are you running into problems where people are coming along without sufficient documentation to make their case? One of the things that is not well stated in the policy but has sort of always been the understanding that ARIN usually dispenses resources in reaction to your track record.

And what you’re doing here is substituting documentation for your track record. And I have talked to people who have complained: Oh, I put stuff in with the immediate need policy and ARIN came back to me and told me I couldn’t have it.

I said: Well, let me see your submission. I’ll tell you if I can see anything obviously wrong with it. And it turns out to be two pages long when printed out.

Well, it’s pretty obvious what’s wrong with it is that they’ve said “give me” and ARIN has said no. Are you seeing that as a systemic problem? Is this language that needs to be put into any policy for it; that that’s what you’re doing and that you need to provide more – err on the side of providing more documentation than you think ARIN needs?

John Curran: So the circumstance we’re running into with this immediate need is partly to supplying documentation but they’re supplying documentation to say: I’ve purchased equipment and I wish to number it. And so they can show that they have the equipment, but they can’t show that they have the customers.

The immediate need policy was, when adopted – you can go look at the text surrounding it – it’s always been considered to be for exceptional cases that involve staff judgment. And so we don’t have guidance, but the guidance has been if there isn’t a customer impact, if it’s not clear that the business is going to be impacted, then we don’t just – we don’t approve exceptional cases. It’s not a case of lack of documentation, it’s a case of lack of impact to the business.

Rob Seastrom: So the problem is that everybody thinks they’re an exceptional case absent that language.

John Curran: And people can very quickly buy equipment and suddenly have a lot of need if you think all the equipment needs to be numbered with all its addresses today.

Richard Jimmerson: Middle microphone.

David Huberman: David Huberman, Microsoft. Immediate need. Immediate need has historically been very important. And the easiest example to give to the room to show how important it is is you purchase someone else’s customer base. They have a thousand customers using a /22. You actually are buying their customer base – which happens, especially in, say, the cable co’s – and you need a /22 to replace it so you’re not taking someone else’s address space.

Immediate need fits perfectly there. It’s been used many times over the year for that. We can’t eliminate it. What I’m hearing Richard and John say here is the age old thing – RFC 2050 actually exists, which is utilization is about proven, things that are facts that are in evidence, not marketing projections.

I purchase a bunch of equipment and I set up a DHCP pool and I’m ready to put in a /25 into that DHCP pool but I have no customers who actually are going to pull from that. I’m hoping to get those customers.

Because of the guidance found in 2050 in 1996, ARIN has always not counted preprovisioned addresses as utilization, and therefore these cases fail immediate need. If that’s something that this community feels is a problem, I think the fix is actually found in Richard’s earlier comments, which is about loosening up assignment – allocation guidelines for ISPs.

If you can come in and get a /24 based on, say, 25 percent, 50 percent, if that’s the way we went, you’d be able to get space, fill up a pool, and wait for customers to come. If there’s a larger scale issue than that, if a /24 is insufficient for these cases – and that’s not clear from the slides – if someone’s looking for a /20 or a /19, then they simply don’t meet the policy. They have to use space from some source, be it ARIN or reassigned from an ISP, and then show that utilization is justification for more addresses. Just like everybody else.
So I’d really not like to make any changes to immediate need. Just my opinion.

Richard Jimmerson: Thank you.

Center microphone.

Jason Schiller: Jason Schiller, Google, ASO AC. With respect to the POC validation, I believe this is working as intended. Please keep asking. I’m not opposed to trying to encourage ISPs when they make a reallocation or reassignment to let them know that they’re required to put in some POC information and what that’s going to be.

I would love for ARIN to do some outreach in that direction and work with that issue.

With respect to M&A, I believe the intention of that policy was that for corporate reorganizations not to need to show an acquisition of assets. I think that’s a relatively easy fix. Somebody should run a policy proposal, please.

With respect to immediate need, I have a slightly different problem with immediate need than has already been discussed. When an ISP needs addresses, they can be slow started. They get a small chunk. They use it up. If they use it up quickly, they double and they keep doubling until they can’t use it up within the window. And that makes good sense to me.

We don’t really have slow start for end sites. And in the case of a large end site where you actually have equipment that you’re ready to number and you ask for addresses for that equipment, but the actual logistics of getting the equipment numbered is going to take you more than 30 days, you don’t actually qualify for the addresses that you need.

So you basically get into the situation of, well, how can I throw people at this to get all of the readdressing done within 30 days or how much of this are we going to cut away and do it in portions and do the first 25 percent and then come back and do again and again and again.
So, yes, I agree in the case where you’re deploying equipment and you’re going to have customers and you are projecting to have those customers more than 30 days away, that’s certainly a problem. But in the case I’m talking about, there’s no customers that you’re waiting for. All of the computers exist. They’ve all been drop shipped.

You just have to send people out and plug them in and configure them and you’re going to start that process as soon as you get the addresses and you’re going to run it to completion and that process is just going to take more than 30 days.

John Curran: So we have flexibility to handle cases like that. The report on immediate need has been based on people coming to us saying: I’ve purchased new equipment for customers that are forthcoming.

Jason Schiller: My experience has been if I’m going to start a numbering project that lasts more than 30 days, I’ve had difficulty getting enough space for the entire project.

John Curran: Under immediate need policy.

Jason Schiller: Yes.

John Curran: If you want to have less trouble getting that for these exceptional cases, you need to create policy so they’re not exceptional.

Jason Schiller: Okay. With respect to /24s, I’m not sure I understand the complaint about not being able to use multi homing to get a direct /24 from ARIN. It felt to me, when we discussed this policy previously, we didn’t need to consider multi homing anymore because the policy under which an end site could get a /24 was sufficiently easy. If that’s not the case, we probably need to revisit it.

Richard Jimmerson: Just real quick on that one, Jason. The feedback we’re getting from customers on that is that they’re going to their upstream providers to get the /24 like they typically did under this policy, and the upstream providers are now telling them: I will not give that to you. I understand you need it. However, I’m holding on to my own /24. ARIN now assigns those. Please go to ARIN and get that.

And so those customers are coming to us requesting the /24, trying to use that sole justification of multi homing, and we’re telling them that’s not sufficient. And they’re going back to their provider and being bounced back and forth between ARIN and that provider. That’s the experience piece why we put that one there.

Jason Schiller: I think the way you solve that is you let them know how easy it is to get a /24 and what information you’re looking for.

Richard Jimmerson: We will do that, but some of them don’t even have 64 hosts. Because the policy calls for 25 percent, 50 percent. And if you can’t show us that you’ll immediately put 64 host addresses into use, you don’t meet the criteria. So this is a class of people that fall between I used to get from my upstream because of multi homing; however, I’ve only got /20 hosts.

Jason Schiller: Then with respect to bringing ISP and end site, how easy it is to get a /24, I’m not sure you really can align these things. How end sites and how ISPs measure utilization are very different things. As an end site, you have subnets for different uses for different purposes, for different reasons. And each of those subnets needs to be more than 50 percent full.

So that’s where the 50 percent number comes from for end sites. With ISPs the 80 percent number is you have reallocated or reassigned addresses, 80 percent of your addresses, to downstream customers and those downstream customers justify the space.

So that doesn’t mean the address space is actually 80 percent utilized. It’s actually much lower than that, because not all of your customers are using each of their address space to 100 percent efficiency.

Richard Jimmerson: Understood.

Jason Schiller: I think these things really are apples and oranges and it’s very hard to compare them.

Richard Jimmerson: I’ll go to the jabber room. I think we’ve got a jabber question. No.

Kevin Blumberg: I had a question. So Kevin Blumberg, The Wire, ARIN AC. In regards to immediate need, do we need to play with relativity a little bit and slow down what 30 days is? Where is 30 days specifically mentioned anywhere? Immediate need is – where is that defined?

Richard Jimmerson: In the policy. It says utilize within 30 days of the request. There’s the policy language.

Kevin Blumberg: Immediate need. Okay. Thank you. And so that’s the question. Do we just need to slow that down? Would that solve most of the problems if it was 45 or if it was 60 days?

Richard Jimmerson: It might.

Kevin Blumberg: The second is in regards to POC validation. I actually had this issue come up very recently where an ISP that we had used 20 years ago, 15 years ago had left a bunch of records in place, and we got sent a POC validation on an unused address, took a look at it.
If these were to be deleted on request of the POC who is registered as the admin, the tech for this reassignment, would it still not show up in WhoWas after the fact?

Richard Jimmerson: I believe that WhoWas carries direct allocation assignments and reassignments. So I think it would show up.

Kevin Blumberg: So the admin contact of that reassignment, as an example, is saying get me off, get me out of here, and you’re saying you’re not willing to do that?

Richard Jimmerson: We’re saying we’re not authorized to do that and we’re inviting them to contact their upstream Internet service provider to remove that record or modify it. Because we are not authorized as the ARIN staff to modify the reassignment records that you create as the ISPs other than POC validation, but we can’t go delete them without your authorization.

Kevin Blumberg: I guess my issue is that ISP in many cases put that information there without the knowledge or consent of the party in the first place. So it seems kind of circular for ARIN not to be dealing with this.

Richard Jimmerson: Thank you. John, you had some comments.

John Curran: Note that changing the time from 30 days to 45, 60, 90, 24 months doesn’t change if the need is based on equipment, not customers. It’s still not a demonstration of customer need, it’s still equipment. So the particular case that brought this forth wouldn’t actually change. It may help other circumstances.

The more generous the immediate need policy, the more ARIN requests have to be reviewed for exceptional circumstance. You really wouldn’t want it to be that the normal request path was the exceptional circumstance path.

With respect to POC contacts, we could change the mail going out to reassignments to have a reply to field, like the reply to of the tech contact of the ISP. And this would mean that when someone had a problem, they would hit reply and you folks would get it. So there’s lots of possibility here, but we just need to know what you want us to do.

Richard Jimmerson: Before we continue with the microphones, I’d like to do a time check.

John Curran: Way over.

Richard Jimmerson: If you’re not at the microphones right now, we’re closed. We’ll have to take it offline. We have five minutes.

Rob Seastrom: Short question of clarification for David who is conveniently standing right behind me. When you say you would oppose changes to the immediate need policy, do you mean changes to the rules and framework of the policy, or that you even – or that you even oppose changes that would be solely a matter of documenting and clarifying existing practice? And I think I know the answer to that, but I’d like to hear from you.

David Huberman: David Huberman from Microsoft. I’m not sure I fully understood your question. I’m sorry. Documentation – my experiences were a little bit different than what you expressed. Documentation has typically been able to be provided.

Rob Seastrom: I mean documentation and – I’m sorry, I didn’t mean documentation in terms of what’s submitted to you; what I mean is in terms of making the policy statement in the NRPM more fully express the operational practice at ARIN.

David Huberman: I have no objection to making the existing immediate need – the spirit of the existing immediate need much clearer language wise in the NRPM. My objection is to changing what immediate need means.

I just wanted to respond real quickly to Mr. Schiller, because his experience is very common. Can you please go to the slide that shows 4.3.3 for end users, how to acquire a /24 or really any space? Right there.

Here’s the problem that, in Mr. Schiller’s example, he’s experiencing.

RFC 2050 and NRPM, for the entire lifetime of ARIN, has espoused the belief that end users should get a one year supply of addresses. You come once a year.

If you are going to get a one year supply, why do we say you have to have 25 percent immediate utilization rate? That’s the problem. People have been lying about this since the dawn of time. So…

Richard Jimmerson: Last question from the middle microphone.

John Curran: Just to be clear, David, that 25 percent was for end users to come directly to ARIN to get addresses, because historically the idea was that those end users would first be getting addresses from somebody else as part of their Internet connection and it was only when they knew that they could justify 25 percent of the block coming from ARIN that we would give it to them.

When you replace that with come directly to ARIN and don’t think about what you have from your ISP, then the 25 percent doesn’t make sense, you’re right.

Richard Jimmerson: Last comment.

Owen DeLong: So going back to the POC topic, it is my considered opinion that – Owen DeLong, ARIN AC – it is my considered opinion that if someone can show that they are in fact the POC in question and inform ARIN that they do not wish to be associated with a particular resource in the database, regardless of what the person who put that resource in the database with that POC on it wants, says or did, ARIN should be willing to remove it and in fact should begin investigating how that POC came to be attached to that record.

John Curran: Right. If we receive a formal request to remove someone from a reassignment record, we will remove the POC, if they’re no longer associated with the organization or they say they’re in error. We will do that. But we don’t get many of them. Generally they’re an organization is getting service and they’re no longer the right contact. And that’s not our job to update. But if it truly is you’re not part of that company, you’re not part of that contact, yes we will take you off.

Richard Jimmerson: Thank you very much.

(Applause.)

John Curran: Lots of good stuff for the AC and for you folks to think about. The policy process is open to everyone. If you have a great idea for policy, based on these discussions or what you hear, find a member of the AC. You can talk to them or you can submit it directly. The process is online.

We are going to move aggressively on ahead. And because I want to make sure Cathy has enough time to speak, I’m actually going to ask Cathy Aronson to come up and give the IPv6 IAB/IETF Activities Report.

IPv6 IAB/IETF Activities Report

Cathy Aronson: There’s something super poetic about this. It’s the most time I was ever allotted for this report, and now it’s the same amount of time I usually get. Awesome.

(Laughter.)

Cathy Aronson: Okay. So just to brag a little, this is from my hood. It was in January. It was minus 10. We had a lot of fun.
Anyway. Onward. This is just the standard blurb. I’m actually going to change the template for this next time, so watch out. I’ve changed a bunch of things in my talk this time. I hope you find it useful.

Okay. So we have a few highlights. Because I thought I had more time so I added some rants at the beginning. So somebody told me that IETF was like watching paint dry. So I Googled it to get a picture because I thought it would make a funny slide, then I found out that there’s a man who gets paid. His job is to watch paint drying. I thought it was funny. Anyway, it has nothing to do with the IETF.

So this is a fabulous T shirt. Pepto pink from Hawaii. Same shirt except this says version 2.0 that was made in 1989. And as no good deed goes unpunished, these guys volunteered to do it again. They got all these great questions from people like can I have the artwork so I can get it in a real color.

The men’s small was too big for one guy. So he wanted to return it. Anyway, they donated $1,600 to the Internet, Open Internet, something or other. Anyway, it was a lot of work. And they’re just fabulously pink. Anyway. Okay.

I thought I’d update you on this. I think I told you guys a while ago that in China they’ve decided that if you spend more than I think 40 hours online a week you have an Internet addiction. I think that covers everyone in this room.

(Laughter.)

Think about it a little bit. And there’s a boot camp that you can go to to break your Internet addiction now. And I thought for sure I should probably just mention that briefly.

Because you know who you are.

Okay. So what I started to do, I don’t know why these are animated like this. So for each group this time I took a little excerpt from the charter so that you might know what the group is about.

So instead of me babbling something about it, IEPG is a group of operators. We meet on Sundays. Most of the IETF doesn’t know we do that. But it’s probably the most interesting part of the week for me. I don’t know why these are animated. I’ll completely change – and I don’t know why it’s doing this. Sorry. Okay. I’m changing the template next time.

So the IEPG, like I said, it’s the most interesting part of the week for me. Some of the quotes are fabulous. In routing there’s no God but it’s miraculous. Awesome. This is from the November IETF. Some of these are in order; some of these are out of order. But there was this route leak and Geoff Huston gave an interesting presentation about the routes that got leaked and how long they stayed around. And it was really interesting. So you might want to check that out.

I obviously don’t have enough time to give this presentation, but it was totally worth watching, and some of you probably have seen it.
This was actually really cool. The BGPDump tool was really well received. And you can like code to it and there’s – I don’t know why I put IPv5. I don’t know. It happens. I type fast when I take notes. IPv4 and IPv6. But it does a lot of stuff that you can use to look in the routing table, which is really cool.

And then Chris Grundemann talked about the IETF help desk he’s been doing at some of the Regional Internet Registries, which has been really well received. And people are starting to learn how they can participate, which is really cool, because we want to get a lot more operators in the IETF.

The animation is awesome. So let’s see. I probably can skip over most of this. There are some – there’s some interesting work being done on different kinds of attacks in the BGP routing system, which some of you might want to look into.

Let’s see. More on extension headers getting dropped. There’s a whole lot of work being done looking at how if you use extension headers your packets get dropped and where they get dropped and how to figure it out and maybe people should just stop dropping them.

Let’s see. Where are we? Geoff Huston – this was a different IETF – this was in Dallas. Not nearly as exciting as Honolulu – where they’re looking at this new – it’s not new, but different kind of encryption for DNSSEC and how many DNSSEC devices out there look at ECDNSA, which is this other encryption that’s a lot smaller. If you use that encryption, the packets would be a lot smaller and then it would be more efficient. So they’re starting to do research like who accepts it, who drops it.

The really scary thing is a lot of the name servers, if they don’t accept it, they just issue the response as if it wasn’t encrypted, which is kind of scary, because if you want it to be encrypted, you should expect if it’s encrypted with the wrong encryption method that maybe you drop it instead of just responding like it wasn’t encrypted.

So, anyway, that’s pretty interesting work. I don’t know why it’s doing that. Some more stuff on IPv6 Path Probing. And what’s funny is they used SHIM 6 for the test but really actually no one uses SHIM6 – oh, they’re having a conversation – and more stuff about operators at the IETF.

So this one, every IETF I think there’s a working group I go to and I think, huh, I wonder what that’s about. So this is actually a lot more interesting than I think a lot of us – there’s a couple of people who commented, thought it was going to be, because I thought human rights on the Internet? I don’t know. I’m not sure I can get my mind around that.

But it’s actually all about freedom of expression and association on the Internet. And it’s a really interesting research group. And I liked it a lot more than I thought especially because it was the last meeting of the last day and we were all pretty tired.
But, anyway, it’s interesting to read about and maybe participate in.

So 6man working group. This is – all the question mark slides are like a little excerpt the charter, if there is a charter.

6man is sort of keeping v6 working, the architecture of v6. And there’s some other v6 working groups that do different things.

So let’s see. They did a whole analysis of the design. They did a design team report, and they’re outlining different issues that need to be solved in protocol. So there’s a document that they’ve produced that has all these inefficiencies. They have duplicate address detection, various routing advertisement issues.

And here’s the link to where those are. So if you want to read about it. I like that you can do DAD when you wake up thing. I think that’s really cute. I don’t know. Quotes are really good when they’re taken completely out of context. And asking how before should since 1984 is pretty fabulous.

Anyway, you can think about that for a while if you’re not reading your email. Let’s see.

(Laughter.)

And there’s some other drafts that they’re talking about. I thought I would include just in case you were interested. It’s not Pv6; it’s IPv6. Sorry.

So I’ve never been to the SUPA. It was a BoF, so it was the first time. I thought I would check it out. I’m not entirely sure I still understand it. But it’s a simplified use of policy abstractions, which sounds really awesome. This is again one of the little things I’ve added about what is that group and what are they trying to do.

So they’re talking about policy driven service management. And I think eventually – I don’t know whether it will be a working group, but it’s some food for thought.

So then we had a technical plenary about smart objects. So they’re talking about non-IP based devices and maybe what we should do about them on the Internet.

So there’s some drafts that are happening, RFCs that are happening about that. Different kinds of smart objects. And some of them have a really long life. Some of them have to sleep for a really long time. So it’s the same old thing that there’s working groups dealing with sleepy devices and devices that are out there for a long time.

So in Honolulu, we had another ISOC briefing panel. We didn’t have one in Dallas. I’m not sure why. But it was one free lunch I didn’t get. Bummer. But it does come with free lunch. You can’t beat that.

Talking about having an Internet wide identity. So the way that you can be recognized no matter where you go on the network. And what that would look like, which was pretty interesting. And how to make it secure and maybe there are some places you connect to that you don’t really care if it’s super secure, but then when you’re doing your banking you want your ID to be really secure. So that’s what that discussion was about.

V6ops is different than v6man meet. V6ops is basically operational guidelines for the shared v4/v6 Internet.

So looking at immediate deployment issues. The really cool thing about v6ops in Dallas is there were actually people who were operating v6 networks who got to talk. I’ll talk about that some more, super awesome like operational experience.

So this is just a few of the drafts that they’re talking about. I think the more interesting stuff comes later. But 6 to 4 being deprecated, a transition technology. And there’s a quote from that.

So this is super funny, I’m sorry. It’s really not very technical. But we were talking about this draft, and I don’t usually put people’s names, but Lorenzo works at Google, which makes this extra funny. So he was like: How did you find it? The other guy said: I Googled it. Super cool. And we all just started cracking up because it was pretty funny.

So there’s a lot of work being done in Japan with v6 only networks right now. And this is one of the drafts that has to do with some deployment that’s going on in Japan. They’re really, wow, doing a lot of work with like trying to make v4 work over a v6 only network and trying to figure out – found a lot of corner cases and issues. Here’s some more drafts. I started to kind of do this at the end, when stuff I knew I wouldn’t have time to talk about.

So there are a lot of problems still with v6 only networks. Some v6 only devices need v4 to get going, which is kind of not good. There were some examples I gave before where maybe you have a v6 only smartphone but it needs v4 to upgrade its software or needs v4 to talk to the server or whatever, and there’s still a lot of that going on.

We had a huge discussion about what you call an unnumbered interface in IPv6. I never thought about that before, but what do you call an unnumbered interface? Administratively unnumbered? Or it could be that it is an interface that has a link local address unnumbered still because it has a number?

So that wasted a lot of time, and somebody proposed the term sheepskin, which I don’t understand at all.

So these are the real operations experience, which was really fun. And this woman who talked was actually the ISOC fellow who not only came to her first IETF but had enough guts to get up in front of the room and give a talk. She was awesome.

So they have a lot of people to give connections to and a very small amount of address space. So they’re looking at doing IPv6, but a lot of the content there is still IPv4. And so that’s a really interesting presentation to check out.

This is another fellow from Japan who is doing MAP E, which is an encapsulation with a v6 – v4 over a v6 only network, which was really also an interesting presentation. Again real operations. Super cool. So this is another one in China, China Telecom. There’s actually a draft about this one.

I don’t know if I’ve been to this group before, the DNS privacy exchange, but I was in a DNS mood. So this is what this group is about, mechanisms of confidentiality. So can check that out.

So I don’t know how much time I have left. Am I good?

John Curran: Give you as much time as you need.

Cathy Aronson: Except I’m between you and the food. So I’m trying to be nice. I already know that I’m between them and food.

Let’s see. Privacy exchange. I always get to one of these slides and I say why in the world did I put that in here. Here’s a few more drafts they’re talking about in trying to figure out their way forward in that group.

So DNS operations, operational guidelines for the DNS. But this is a little chartery thing I’ve added. The charters are sometimes six pages long. So you might want to – I picked the excerpt that makes the most sense to me. But I tried to put the link. So I like this. This happened in Dallas. So just last month.

I didn’t know this but .onion is a special use domain that isn’t actually in the DNS as we know it but it’s how Tor nodes find each other. So I had already heard about .home and the ones that kind of happened by accident setting up a home network, but this is actually on purpose. So they’re talking about whether we need to make special accommodations in the DNS so that these queries don’t end up going to the root, because they’re not really in our DNS. So, anyway, .onion, who knew.

Of course, our own Lee Howard talked about the reverse DNS. And we talked about this before, it takes a gazillion years or some actual number to populate the reverse DNS and a lot of things fail if you don’t have the – in v6 and a lot of things fail if you don’t have the reverse DNS.

So there’s still some more work, and if you want to talk about that with Lee, I’m sure he’d love it. He’s nodding his head. He has a target now.

There’s a document on DNS terminology. I love this. I can still use belt and suspenders, and the other guy said I don’t really want to get in the way of that because it might not be good.

Then there was a whole discussion about queries that you might not want to answer. So maybe it’s okay if you answer certain queries but maybe the equivalent, if somebody asks you the equivalent of what’s in your wallet, you might not want to answer. Maybe if you get a DNS query for certain things, you might not want to answer.

So there’s some discussion about that.

So I know quotes taken completely out of context are super entertaining. That’s why they’re here. This was a whole metaphorical discussion about what we should standardize and what we shouldn’t. But, nonetheless, taken completely out of context they’re super hilarious. So you can just check that out. I type really fast. And I was like, oh, my God, did they really just say that?

So they’re also talking – with .onion, they’re also talking about other reserve top level domains like .mail, .home, and .corp, where you don’t really want home networks to come online and go to the root for some printer that’s in .home in their house. So they’re talking about how maybe we’ll fix that in the DNS.

And one of the suggestions is using ALT as a top level domain. So like with the news feed, you know, all the stuff that was under .alt, dot whatever, was like kind of hidden under there and they’re talking about maybe putting these under .alt in the real DNS so that you know that query doesn’t need to leave your local network.

We’ll see how that goes. You’ll just get back an X domain and it wouldn’t go all the way to the root.

It’s not animated. It’s just a short slide. So there’s a survey of DNS cache issues in China which is interesting to check out. Here’s some more drafts. Again, it’s just a lot for two meetings. It’s a lot of information for one little used to be 40-minute presentation.

So this is another DNS group. There’s a lot of them. And this is the charter excerpt from that. So scaleable DNS service discovery.
And they’re talking about maybe using TCP and setting up long lived queries and various different things with Homenet like having more information embedded.

Okay. So these are really interesting to check out. The IRTF is the Internet Research Task Force, which is sort of a parallel organization to the IETF, and every year there’s these prizewinners that win for their research projects, and some of these are pretty interesting.

I thought Sharon’s presentation was really interesting. She talked about some RPKI issues which I was kind of thinking maybe you guys might be interested in this because we’re kind of RPKI-ish here.

So will the RPKI eventually be used to take down routes. There’s a lot of questions to be answered. And then there’s another fellow who talked about this stuff here. There’s two more. These were presented in November, because the process starts now, I think they’re nominating now and then in November they get awarded.

And there was this other one, too. SDN. Somebody is actually using SDN to manage a network, which is pretty interesting. Their tools are pretty interesting.

Dynamic host configuration. So this is basically all the care and feeding of DHCP and DHCP like devices, so things that automatically give you an address and information about your gateway and stuff like that.

There’s a lot of discussion these days about anonymity and making – well, this is a really good example. Like if the trash cans in the neighborhood like have scanners on them and they can track your Wi Fi signal – I guess that happens somewhere – they can track where you are. And if they can attribute the Wi Fi chip or whatever, you know, they could attribute your phone to you, then they can track you with these Wi Fi scanners. So when you’re searching for a network as you’re walking around town, like our phones do if you leave it on, they can go, oh, that’s Joe and he’s walking down California Street. And that’s kind of creepy.

So they’re looking at how to make DHCP more secure and anonymous. And here’s some other drafts that are going on in DHC. I don’t go to GROW much, but when I have time, I like to pop my head in because it’s global routing operations and I used to do a lot of routing. So I kind of like going in there and seeing what’s going on.

So this is some recent numbers about – I guess this was November, because it was Honolulu IETF, the routing table for v6 is about 19,000 routes. Lee is standing up; maybe he has something to say.

And the information about de aggregation, and they’re talking about using extended BGP communities to do geographic addressing, which just makes me upset and annoyed in a way I can’t explain. But, anyway, there’s some route leak information at this draft at the bottom.

IANA plan. It’s the IETF version of CRISP-ish. They’re looking at how to fit in with the IANA as this transition happens. So they have a draft and they’re working through it.

If you want to check that out, there’s an IETF draft. It might be in RFC by now. Because they didn’t have a meeting in Dallas, just in Honolulu.

Software defined networking. So this is the overview slide. They don’t have a charter. They feel they don’t need to be bound by a charter.
In the thing it says about the working group. Constrained by a charter something like that. Not constrained by a charter.

It’s interesting, and I don’t know if any of you use SDN. Anybody? Everybody awake? There’s a little kind of, sort of.

Quite a bit of work being done. It was basically people presenting how they’re trying to use SDN. So these are different architectures that people are configuring to configure their MPLS or overlay things on their network, that sort of thing. Some software defined monitoring.
There’s a company that’s using SDN to do stuff like, well, maybe I want to reboot this router at midnight and maybe I want to move all the tunnels off of it over here so I don’t cause an outage, that sort of thing. A lot of work being done with that.

Some SDN drafts. Not being constrained by charter. I apparently needed to put that twice. Sunset v4 is basically a group trying to identify issues with v4 that need to be fixed to make v6 only networks work kind of.

It’s been sort of on a hiatus for a while. So this was a kind of restart the working group session, tried to figure out what’s needed. Maybe how they move forward. But the goal of the group is to gracefully make v4 go away.

So the whole session that I went to was discussing the current – the few current drafts and how to move forward with them. I’ll skip over a few things. We had a plenary in Dallas. So this CODEMATCH thing, if you have interns or grad students trying to get folks involved, basically to do some coding of RFCs, to get college credit, to actually implement some of this stuff and see for real if you can take an RFC and actually write an implementation from it that would interoperate or whether there’s more needed in the process.

So if you know anybody – like stop laughing. If you know anyone that needs like a grad school project, this would be – it’s been really well received and a lot of enthusiasm. It’s really pretty cool.

And like they say at the IETF, “there’s cool” – the bottom quote. I won’t say it at the microphone. Can you guys read it? It actually came from the IETF hack a thon slide.

Anyway, the Internet Area, this is again my new slide of what it is. So this is basically where all the Internet stuff that doesn’t fit in this particular working group goes until it finds where it needs to go or some of the drafts just stay in this working group.

And so these are some of the things that they’re talking about. I’m pretty much going to glance over this.

And IP Performance Metrics is another group I went to, which is kind of testing the performance of IP across various mechanisms – various networks and devices and that sort of thing. But it’s basically another group that benchmarks equipment and IPPM benchmarks IP and figures out how to make IP work faster.

So these are some things that are going on there. Like I said, I’m going to – Homenet. Homenet was a really, really long discussion about which routing policy protocol to use in the home which made me have a really interesting hallway discussion with a man who is really into this.

I don’t know whether they call it Babel or Babel, but it’s not like a – it’s not a former routing protocol yet, but people are really enthusiastic about it. But by the time it’s a routing protocol, like Homenet, homes are going to have networks and they’re not going to be using that. But so there was a lot of talk about which routing protocol.

The last time it was the argument about whether we should have one or two or three or none. Now we’re talking about which one. One or more than one. Anyway, there’s a lot of – I think the ship is going to sail before these guys finish a spec for Homenet.

This is another one of those special use domains I talked about before, .home, and what do we do about .home because it’s being used and the queries are going up to the root. That’s that in a nutshell.

Let’s see. So they’re still trying to decide about which routing protocol. Anyway.

I’m going to gloss over most of these. But NETCONF is mechanisms to configure network devices. And then there’s Source Packet Routing, which is trying to solve how do you choose the right address when packets leave if you’re multi homed, that sort of thing.

And I really wanted to talk about – I guess somehow I missed it. So there was a discussion about how a lot of RFC names aren’t super useful, like YMBK, which means you must be kidding, apparently. Somebody pointed out that even though the people in the discussion had been coming to the IETF for a lot of years, they didn’t know there was this atomic feed that gave you like every draft and every RFC that comes out and like what the title means.

So you can actually sign up. So I wanted to make sure that I included this, because that’s really an easy way to get the information and go, oh, I know what that title is now, maybe I want to read that one, instead of getting YMBK and not knowing what it means.

These are some of the general references I usually have about the IETF, and then this is probably not readable but super funny.

Does anybody have any questions?

Lee Howard has something to say, I just know it.

Lee Howard: Lee Howard, Time Warner Cable and v6ops working group Chair. I wanted to say thank you. Love seeing this. It’s been a while since I’ve been at this meeting, but I’ve seen you at the IETF meetings for a while. It’s nice to say I’m putting both sides of your job together there.

It’s good. There’s an effort among some people at the IETF to be reaching out more to operators, the operator community. The ISOC has done a couple of IETF help desks at some of the network operators groups. And I kind of wanted to volunteer as an IETF active participant that if anybody has questions about how things go on there, has feedback for what we do at IETF or v6ops in particular or my reverse DNS draft, how you can participate, I’d be happy to talk and be a friendly person. And I’m sure you would, too.

Cathy Aronson: Yeah, of course.

Okay. Aaron.

Aaron Hughes: Aaron Hughes, ARIN Board. One of the things you brought up was working groups related to v6-only environments and IETF working group areas around that. Have you heard any discussion about some sort of uniqueness for 32-bit unique identifiers for protocols that aren’t going to change, like OSPF or BGP?

Cathy Aronson: Maybe Lee has –

Lee Howard: Yes, there’s been some discussion specifically about that. I know that there are lots and lots of places where there are protocols that use a 32-bit identifier. And it says in the RFC 32-bit identifier, but everybody uses an IPv4 address, because that’s a handy 32-bit identifier.

There are a couple of places where text is being changed. There’s some – I think there’s an MPLS dependency where you use an IPv4 address. Even though I don’t think it’s technically required to be a v4 address, in practice that’s what it always is. So that’s being updated.

I don’t think there are any other particular cases like OSPF, as an example, we looked at said, well, it’s not wrong, we can change it if it needs to be, or we can just provide operational guidance saying don’t use a v4 address. What should we say?

Cathy Aronson: Doesn’t ISIS still use a CL IP address? So maybe we’ll have this around for a while.

Anybody else?

John Springer: We have a remote comment from Frank Bulk: Thanks Cathy.

Cathy Aronson: You’re welcome.

John Curran: Thank you, Cathy.

(Applause.)

John Curran: I had expected we would be this way with timing. So we’re going to go directly to break. The break runs until 11:00 a.m. Please be back in here promptly. We will have a panel on the CRISP team update at 11:00 a.m.

See everyone shortly.

(Break.)

John Curran: Welcome back from the break. I’d like to kick off the next hour panel. This is the CRISP team providing an update on their activities. So we have – let’s see. We have Bill Woodcock, Michael Abejuela, John Sweeting, and then we have John down at the end who is doing the jabber remote.

So I’m now going to turn it over. Let me hand it over to you, Bill, or do you want to hand it to John?

Consolidated RIR IANA Stewardship Proposal (CRISP) Panel

Bill Woodcock: Really quickly, just sort of what this is about for those of you who have not spent the last few months in late night conference calls. The Consolidated RIR IANA Stewardship Proposal, CRISP, team is consolidating input from the entire numbers community. So these are two voting and one staff member, the three of us, from the ARIN region and similar composition from each of the other four regions.
This is putting together the proposal for the transition of the numbers component of the IANA functions contract from the NTIA to us. So instead of ICANN being a contractor to NTIA, they will, we hope, wind up being a contractor to the numbers community.

So with that, we’re going to spend the hour approximately as follows. John is going to give an update from the CRISP team. So this is the sort of NRO slide deck explaining where we’re at, ten minutes. Michael is going to give ten minutes on the drafting of the service level agreement, which is the core of the new contract. I’m going to talk about the potential challenges, the difficulties that we may run into over the next couple of months.

John Curran is going to talk about an external legal opinion on ICANN accountability that ARIN commissioned but is not at this point an ARIN recommendation or finding or anything.

And then we’ve got 15 minutes for Q&A. In addition, because the slides will go up on the website and so forth, I’ve included at the end of this as slides all of Cathy Handley’s FAQ on the CRISP process for those of you that are interested in looking into it further. That includes a lot of URLs that help you dig further in. So John.

John Sweeting: Just quickly, before I get started, Michael wanted to give an update on the composition of the CRISP team, I think.

Michael Abejuela: Just as recognition and thanks from the three of us and actually the ARIN community, we wanted to thank Alan Barrett for his service on the CRISP team. As some of you may know, he has an exciting new opportunity, but he has since resigned from the CRISP team, but he was serving as Vice Chair and really worked very hard with us in getting that proposal on time. So we do want to thank him and recognize him.
And also we wanted to announce that Nurani Nimpuno is now the Vice Chair. She has been elected as of our last meeting. So we look forward to her serving in that role on the CRISP team.

(Applause.)

John Sweeting: Also since German Valdez is in the back of the room, I’d like to give a shoutout to him for all the support he’s given to the CRISP team. It’s been outstanding.

(Applause.)

Now we’ll move right along. As Bill said, the CRISP team was put together to represent the numbers community and put together a proposal in response to the RFP that was put forth for the transition of the IANA stewardship. So before – this is a quick diagram of the essence of the proposal.

Before there was a three-party relationship with NTIA having the oversight of the ICANN and IANA function with the RIRs being the customer, the end user there. What we’re looking at afterward, after the proposal is accepted and it’s all implemented and everything, would be a customer/provider relationship with the RIRs having oversight but also being the customer of the IANA function, but with oversight over ICANN.

So components of the proposal with the IANA function. Stability and reliability, replacing the role of the NTIA with the RIRs as the representatives of the Internet numbers community, establishment of review community, and clarifying the intellectual property rights.

So as the CRISP team, we were actually put together – we had the overview in Baltimore. We had our first – I think our first official meeting was like December 3rd. And we had to have this proposal done by – finalized and submitted by January 15.

So there were quite a few calls over the holidays with the different – with everybody from the CRISP teams participating, which in itself was a pretty big miracle, actually, to get this all done in that short of time.

But what we did is we had – the five RIRs had their own regional list, and we also had the NRO list to get the input for the proposal.
And out of that input we put together the proposal, submitted it out to the community, got their feedback, changed some things up, put it back out, and finally on January 15 submitted the final copy of it to the ICG, actually.

Some of the parts of it were for the ICANN to continue as the numbering services operator with an orderly transition to any different operators should the need arise, with the RIRs establishing a service level agreement with the IANA numbering services operator.
Also there was a review – we recommended for an establishment of a review committee to review the performance of IANA numbering services and advise the RIRs, and there was a pretty – I wouldn’t say heavily debated, but a good conversation around the intellectual property rights related to provisioning of IANA services.

Bill Woodcock: The IANA name.

John Sweeting: Basically the IANA name.

So one part that really we spent a lot of time on was the SLAs – were the SLAs. We started out – I think we got a little bit wrapped around the axle because we started out trying to define the SLAs, and then in discussing it and having input from the community we came to the realization that we really – the CRISP team was doing the proposal, not the SLA negotiations itself. So instead we came to the agreement that
we should put these SLA principles within the proposal.

There’s 11 of them there. Separation of policy development and operational roles. Description of services. Obligation to issue reports on transparency and accountability. Security performance and audit requirements. Review of the operation. What happens in failure to perform. Term and termination. Continuity of the operations. Intellectual property rights and the rights over data, over data that IANA currently owns or has the rights to. Dispute resolution. And cost-based fee.

The review community, we started out – there was a pretty good discussion on the review community too. What it boiled down is we ended up saying there should be a committee that will do this review; that it’s each region has equal representation and that the process of selecting those representatives would be driven by the RIRs based on open and bottom-up principles.

So basically we’re thinking that this review committee would be put together something like the ASO AC or the CRISP team. The RIRs have a lot of experience in doing that. So that’s why we said we’d leave it up to them to do that.

The other operational communities. Intellectual property rights on the IANA trademark and the IANA.org domain name. There was clarity needed on these issues in case of the change of an IANA operator. And you can see there, the last paragraph of Section III.A.3: The transfer of the IANA trademark and IANA.org domain to the IETF trust will require additional coordination with other affected communities of the IANA services; namely, protocol, parameters, and names. It is the preference of the Internet numbers community that all relevant parties agree to these expectations as the part of the transition. It’s not really a hard, fast requirement, but it is the preference that this be agreed to as part of the transition.

Community engagement. As I said earlier, there was the global Mailing List, which is open to everyone. There’s also a website that has all our meetings, all our recordings of the meetings. There’s an FAQ there. This slide presentation is there.

This slide presentation, like I said, was put together for the CRISP team by German from the NRO, and it’s kind of the presentation that will be given for CRISP team updates at each and every RIR meeting that gives an update.

We did not ban – like we didn’t say you couldn’t put – you couldn’t give input on the regional list, but it was put out early on that we would prefer all the input to go on to the global NRO list so that it could be discussed globally.

But there were a few things that ended up on the regional list that then the CRISP team representatives brought to the global list for discussion. There wasn’t a lot of that. Mostly people that wanted to have input during this went to the global list and put in their input.
But at each of our calls, each RIR went through any input that it received, whether on the list or actually just running into somebody and discussing it. All that was shared on the CRISP calls.

And the CRISP team, the consideration of the feedback shared on that list, we have a spreadsheet of the issues maintained, directions that were clear to the community, and further comments, clarification, questions could be made if needed.

Some of the feedback that was received. There was 377 posts on the global list with 53 unique posters. And the Mailing List archive is published on the NRO website.

Support expressed for the proposal. One poster requested adding more detail on some of the proposal components. But the suggestion failed to receive support from other posters. And there was two comments to the global ICG forum expressing concerns.

And I believe on those the ICG came back and asked the CRISP team for clarification, and we provided – we went back to the community to get the clarification on those comments, on those concerns. And there were no objections to the proposal components.

ICANN public feedback. So during the ICANN 52 public forum, ICANN Chair Steve Crocker said in regards to the ICG proposals from the numbers and protocol community – parameter communities, the ICANN Board felt there was nothing fundamental in them that we have a problem with, full stop.
So basically it was the fact that the numbers and the protocol parameters community, we both submitted our proposals on time by the deadline of January 15th, 2015.

By the way, Bill will get into a lot more on that when he’s doing this part of the update.

Some of the things that reached consensus were principles of the SLA, the community will be continuously engaged during draft into the SLA, high level principles in the review committee selection process, the IANA intellectual property rights clarification, and minor editorial suggestions and clarifications.

Things that did not reach consensus was specify a particular jurisdiction/dispute resolution mechanism, specify a particular selection process for the review committee, and incorporate the SLA text as part of the proposal. Which I mentioned earlier.

For more information, the CRISP team – on the CRISP team itself, you can find on that URL, the proposal on the next one. And then, like I said, there’s an FAQ that as we’re getting questions more from I believe ICG and other upwards, the clarification we’re providing that we’re getting feedback from the community to provide are listed on that FAQ.

Bill Woodcock: Just a clarification about the process moving forward. Our report goes to the ICG along with the reports of the IETF protocol parameter community and the CWG names community. The ICG then is intended to integrate those all together.

The numbers community also has representative to the ICG. So because it’s really important that this entire process be done openly and transparently, what we hope is that anyone who has any objections to what’s happening or anything that they think can contribute to the quality of the eventual document, that they bring those comments back either through the ICG or through the CRISP team in public on the Mailing List so they can be dealt with and responded to publicly.

John Sweeting: That’s it for me. I’ll hand it over to Michael here to talk about the SLA drafting progress.

Michael Abejuela: Hello, everybody. I’m ARIN’s associate general counsel and also the staff representative from the ARIN region on the CRISP team.
From the CRISP proposal, one of the follow on activities was the Mailing List and drafting of an SLA. So the RIR staff members from the different regions have been undergoing efforts to put together a draft SLA that has been really guided by those principles that John just went over in the proposal.

The next step for us – because we have been in the efforts of drafting, the next step is for us to finalize a submission to the RIR CEOs, which we intend to do by this Friday, Friday of this week. And then once that submission is given to them, then they’ll be reviewing it. So hopefully we’ll be having a release to the public for comment in the near future.

One thing that is an expectation and suggestion is that if there’s anything in the SLA that’s drafted that may be even ambiguous as to consistency with SLA principles in the proposal, that those be specifically called out in an effort of transparency. So the community, when reviewing that draft, will be able to see that.

It’s not confirmed, but the expectation is that the RIR CEOs will rely on the CRISP team to then manage and help coordinate the feedback from the community on the draft SLA.

So the big component here is trying to make sure that everyone is aware we are drafting it consistent with the SLA principles, as much as we can. We’re focused on that, and it’s being driven by those principles from the proposal.

If there’s any kind of consistency issue, that will be called out to the community and the community will have ample time to discuss, comment, and review those principles.

So other than that, that is where we stand. Hopefully you’ll be seeing a draft of the SLA from us sometime soon.

Bill Woodcock: I’ll get into the more controversial part of this, which is the potential challenges, things that might still happen in the process that will have to be worked through.

So sort of summarizing those. So we’ve got two major areas. But things like the intellectual property issues and so forth, I would view those as kind of minor things that will get worked out and are not going to be a big deal in the long run.

The termination clauses are something that ICANN has expressed discomfort with at least verbally. And so we want to understand ICANN’s position better on that so those can be negotiated through.

That breaks down into four issues, three of which is explicit in our principles and one which is implicit. The first is question of termination on reasonable notice, and the second is how to discipline the SLA. The third is some sort of periodic competitive selection or renewal, and the fourth one that’s – so those are all three things explicitly called out in the principles.

The fourth thing is that the numbers community needs to contract with an IANA services – sorry, IANA functions operator. The IETF needs to and the names community needs to. But there’s no implicit requirement that those be the same contractor on the other side.

And so that, of course, is something that ICANN would prefer to be the sole contractor to all three parties. So that’s kind of a potential issue. Although it’s not specifically to do with us.

The other major area is the CWG, the names community, has not yet submitted the document that the January 15 deadline applied to, so that the ICG has not been able to move forward because they don’t have all three documents.

And ultimately this is a more difficult problem for us. It’s not just a matter of us and ICANN sitting down at the negotiating table and then working it out, because this is a different community. And if they don’t do their part, the whole process can’t move forward.

And so they’re sort of deadlocked on this ICANN accountability issue, which John will talk more about later, and the names registries that – what’s tricky there that is not tricky for us on the IETF is the name registries have kind of a bi-directional relationship with ICANN.

So moving forward. So this entire process is supposed to be happening openly and transparently, which means that negotiating positions need to be expressed in writing on a Mailing List, so forth, in order that we can work through them, because, I mean, obviously ICANN is a company and they can do things – they can speak for themselves in a way that we as a global community can’t just sit down and have one person speak to the global community.

So we have to discuss everything in order to make it happen. So what we understand from discussion with ICANN legal team is that they are reticent about the termination clauses.

And so that appears to be sort of in conflict with what Steve Crocker said that the ICANN Board said about not having any problem with the proposal as it sits.

So I’m going to run through what our principles as expressed in the proposal were and what the current situation is to kind of give you an explanation of why we believe that our principles are sort of commercially reasonable contracting terms.

So we have heard it asserted through quite a few different channels now that ICANN does not believe that the NTIA or the US Congress will approve a contract that allows for the selection of other parties. And we, the CRISP team and the ARIN representatives to the CRISP team, don’t think that that is a credible argument, and there are four reasons for that.

First, the USG itself has never considered ICANN to be a sole possible source for these services. Second, this is the US government that just turned over the country code 1 numbering plan to a Swedish company in favor of – over Neustar, which had been doing it for the last 10 years or so.

And, third, this argument implies that ICANN could itself never become a non-US organization. And there’s a lot of international pressure on ICANN to make it itself a less US-centric organization. And it’s probably not – this is all kind of speculative, but it’s probably not credible for ICANN at this point to make a firm commitment that it would never become a non US organization.

And, fourth, we’ve solicited direct input and not received it from NTIA that they actually have a problem with this.

So moving forward, we’re really dependent on this transition.

Bill Woodcock: We’re trying to keep the questions to the end.

So really what we’re trying to do here, because we’re a global community, is use the open source development process. More eyes on the process yield a qualitatively better result. What we want is for all of you to be looking at what’s happening here and making the best suggestions you can as to how this process could be and its result could be as good as possible.

We want the best possible outcome for the community here. So the first of these principles, either party may terminate the agreement with reasonable prior notice. That’s the language of the principle. So it’s up to the RIR legal team to turn this principle into an SLA term that can be included in a contract.

Now, if we look at what the contract that ICANN currently has says, it is with the US government, the NTIA. It says the government can terminate in whole or in part if that’s in the government’s interest. It doesn’t say unreasonable notice. It doesn’t say in whole only. It doesn’t say there will be negotiation about what part is continued and what part is not.

And it says at the government’s sole convenience. So we believe that the term that we are proposing is more reasonable than what ICANN is currently laboring under.

The next one, if the IANA numbering services operator fails to perform as agreed, there will be specific consequences. One of those consequences may be termination of the agreement. Again, this is very vague because this is a general principle that we are expecting to get negotiated by the RIR and ICANN legal teams.

Here’s what they’re under right now. Obviously this is pages and pages and pages that I’ve distilled down to the salient points. Basically government can terminate in whole or in part if they see that a problem has not been cured in ten days. So that’s a very hard requirement on a very short timeline.

Right now they can require the contractor, ICANN, to remedy by correction or replacement at no cost, blah, blah, blah. If that doesn’t happen, they can themselves select at their option a different contractor to fix the problem at ICANN’s cost, which is not anything we’re asking for.

That’s, again, a fairly harsh term.

Then they can terminate in the event of default, blah, blah, blah. And also they can terminate if the contractor fails to provide adequate assurance of future performance. That is, the government can terminate if they think that ICANN can’t prove that they can do a good job in the future.

Again, a pretty harsh term that we’re not asking for.

And then the cherry on the top, which is if it’s determined that the government improperly terminated this contract for default, it will be deemed a termination for convenience.

Periodic competitive selection. We have two references to that. One is in Principle 7 RIRs will be able to periodically review the agreement and evaluate whether they want to renew the agreement.

And the other is up near the top of the document, says the Internet number community believes that ICANN should remain in the role of the IANA numbering services operator for at least the initial term of the new contract. That is, we are not asking for competitive selection at the outset.
So here’s a history of the competitive selections that have occurred so far during the period of ICANN’s existence and the agreements between the US government and ICANN.

The ones where there was a contract generally are ones where there was some sort of competitive selection. The ones without anything in parentheses are typically ones where there was a extension or renewal that was not competitive rebid.

Of particular note here is the March 10, 2012, where there had been an RFP put out with a due date of – I believe it’s a due date of December 19, 2011. And NTIA found that none of the responses to that RFP, including ICANN’s, met the minimum requirements.

So then ICANN had to go back and make a better proposal and compromise reached, so on and so forth.

So the last one is that these three functions – the number community, protocol parameter community, and name community – each one is going to be independently arrived at. So there isn’t necessarily a tight coupling between those.

But we all acknowledge – at least the IETF and the numbers community acknowledge that in the event that one or more of those were to go different ways, there would have to be a lot of coordination to make that happen.

That is not something that anyone would undertake lightly, because it might have some pretty grave unforeseen consequences. So that’s not a direction anybody wants to go.

However, none of the three of us can bind the other two to doing the same thing that we do. Therefore, this is just kind of an inherent issue that has to be acknowledged and recognized and that the sort of grave consequences of it foreseen to keep people from going off and doing their own thing kind of arbitrarily.

So let me move to the other issue. The CWG being deadlocked. The CWG is a Cross Community Working Group for the names community. That’s their equivalent of us, of the CRISP team.

So they did not meet their January 15 deadline, and they still haven’t delivered a final document to the ICG. The complaint that we are hearing most from them is that they want to see and incorporate the results of the Cross Community Working Group on enhancing ICANN Accountability Work Stream 1. This is a separate parallel process to the one we’re going through that is intended also before September 30 to have a set of recommendations on how ICANN could behave more accountably, how ICANN can be more accountable to its constituency.

So we looked at that and said, okay, that’s great, that’s a parallel work stream, they’re doing their thing, we do our thing. Our thing is not dependent on that.

The IETF came to the same conclusion we did. So we didn’t see that as any sort of blocking factor. We said that’s a parallel process. The CWG, on the other hand, said they wanted to see the output of that before they could finalize their thing. And so that’s kind of where we’re hung up, because that Work Stream 1 hasn’t even posted a due date yet for when they think they’re going to be done with their thing. So we’re kind of hung up.

Now, not as an apology or anything but more as an explanation, the names community has a more complicated situation than we do, because, unlike us, a lot of the names community is made up of new gTLD registries who have a bi-directional relationship with ICANN in a way that they were created through an ICANN process.

And as we’re seeing, for instance, right now with the .SUX TLD, their whole business model is kind of dependent upon them dealing with ICANN process, and that can be yanked out from under them.

I’m diverging very much into sort of personal opinion, right, which is not needed.

But they’re in a more complicated situation than we are. And I think we all acknowledge that. Okay. So I’m not going to bother to read through any of this, but really basically Fadi talked a lot about this situation during ICANN 52. And so there’s a really good talk up on YouTube that – where he explains a lot of these issues and says what the hangups have been.

And so I’ve copied parts of the transcript of that onto this slide and the next one, which you’re welcome to read at your leisure later. Basically this slide, he’s explaining the relationship –

John Sweeting: I don’t know if everybody in the room knows who Fadi is.

Bill Woodcock: Sorry. The CEO of ICANN. So the ICANN CEO at the last ICANN meeting in Singapore was explaining why this process was hung up.
He was relatively frank, and there were people who criticized him for that, but he was also really cogent and on point and explained it in a way that I think is very clear.

So part of this – remember, this is a transcript of what he said verbally, not from notes or anything. So it’s a little messy. But he’s explaining the relationship between ICANN and NTIA and Verisign.

So at the same time we’re doing this whole process to renegotiate the relationship between ICANN and NTIA to being one between ICANN and the community, there’s also this second contract between ICANN and Verisign – sorry, between NTIA and Verisign. Sorry.

So when the NTIA/ICANN contract goes away, that leaves this other shoe to drop.

What he talks about is VeriSign has agreed now to work with ICANN to be a contractor to ICANN to provide the root zone management services, which previously they were a contractor to NTIA.

So Verisign has been justifiably, understandably nervous about how this all works out. Because, unlike us, a global community, they are a single company that is very vulnerable to changes in this area.

So second half of this. He’s explaining that CWG has not yet reached conclusion and that they are sidetracked on this accountability issue and that there is an accountability track and they should go there. And the IETF delivered because the IETF focused on outcomes and the numbering guys, that’s us, delivered because we focused on outcomes – operations.

So one of the reasons why we don’t think that accountability is that big an issue is because there are very specific legal protections under California State not-for-profit corporation law that say how it is that not for profits incorporated in California are responsible to their constituents.

And with that, I will turn it over to John to talk about the work that we had prepared in this area.

And coincidentally, the CWG also commissioned work in this area, and I know of at least one other corporation with an interest in this area that commissioned work, and they all came to the same conclusion.

John Curran: Right. So the reason I’m up here is – actually drop back one slide so people can see the URLs. If you look at these two URLs here, the Team ARIN URL with the ICANN bylaws regarding designators PDF and the ICANN bylaws regarding changes ICANN bylaws designators.PDF, those two URLs point to a legal memo that ARIN commissioned and a set of changes, edits to ICANN’s bylaws that came out of that legal assessment.

Now, we have our own bylaws at ARIN, and we have plenty of things to do. And I actually have no particular need to go digging into other organizations’ bylaws, but, as it turns out, what happened in this process is that in looking at the ICANN accountability, we do have an issue there as an organization.

ARIN with the other four RIRs participates in ICANN via the ASO, for example. ICANN ratifies our global policies that are used by the IANA. And so it’s necessary that we have a functioning ICANN. It’s a good thing for everyone.

And there’s been more than a dozen proposals of potential changes to ICANN’s bylaws to make it more accountable to the community. This is work being done by the CCWG and the CWG, the Cross Community Working Group and the Community Working Group.

One of them has so many changes, in fact, that it’s 30 or 40 pages just to describe all the potential changes that might be necessary to ICANN to make it fully accountable in the way that many people feel is important.

Well, as it turns out, the more changes you make, the more difficult it is to figure out how they interact. If you create a review mechanism, an appeal mechanism, if you create a multi tiered Board, if you create a membership structure and a designator structure and delegate structure, you literally need to have the lawyers standing at your right shoulder to explain which takes precedence in any given circumstance and which one can be invoked next.

Along these lines, it was – one of the things we talked about at the ARIN Board is that it might be good to understand what’s the minimum solution set. In other words, if we really wanted to make sure that there was some mechanism other than NTIA to hold the ICANN Board accountable to the community it serves, what’s the minimum that could be done?

And in the process we said, well, let’s hire a law firm that knows about California not for profit public benefit corporations and have them look at it and come up with an answer.

And they came up with a three page memo, and their three page memo said it’s already there. And that’s what the two documents say.

The way the ICANN Board is elected is that it actually is appointed by bodies. The Nom Com appoints eight people. The ASO, which we talked about earlier, appoints two. The ccNSO appoints two. The GNSO appoints two. The at large community appoints one.

As it turns out in California law, unless you do something explicit, the ability to appoint a Board member includes the ability to recall and remove the Board member. And that’s not very clear in ICANN’s bylaws. In fact, ICANN’s bylaws create a right of removal for the Board to remove members. Turns out, that’s actually not possible. The party that appoints a Board member turns out to be the only one who can remove it.

So there’s some interesting issues there. And we had a legal memo done and we had it written up.

So it turns out if the community already has the way to recall the Board, as long as that doesn’t change, like no one changes the bylaws, then there is accountability. So you only really need to make sure that the bylaws are not changed, and that can be done by making sure that to change the bylaws you need the written approval of those who appoint board members.

Bill Woodcock: Bylaws can’t trump state law.

John Curran: Right. And the last part is you just need a way to get people in a room to talk about accountability. We can do the now. We can get the Nom Com, the ALAC, GNSO, ccNSO, get us all in a room and say let’s talk about what ICANN did last week, is that true to the community.

But it’s actually probably better to have a structure for that. So you add a paragraph that says all of the people who designate Board members can get in a room to talk about a particular event that disturbs them and hear why it went the way it did.

It doesn’t change anything because they all have to go back to their organizations individually to remove Board members, but it turns out there’s actually a pretty good structure that’s existing in California law for these corporations to provide accountability without a lot of changes.

We did the legal analysis on this, and ARIN paid for it. We shared it with the other RIR organizations. It’s not a recommendation. People ask me about that. No, it’s just legal research. We did share it with the working groups that are working on this problem, the CCWG and the CWG and the legal teams within those groups.

Now, as for recommendation, that’s a hard question. Remember, our use of ICANN is very light. Those organizations live within ICANN in some cases.
The DNS community has a wider tapestry of problems they might be trying to solve. So I’m not sure it’s appropriate for us to say we know the right answer.

I think it’s appropriate to say we know an answer and it’s a simple answer, and if we deviate from the simplest, we should know why. But that doesn’t mean we necessarily have walked in their shoes or know their problems.

In any case, because it has been submitted, it will be something that gets legal review by the two law firms that the accountability teams have hired. And it will come out eventually as one of the items for public comment. These will all – the CCWG is going to public comment in about two weeks, and they will produce a set of options or traces for public comment.

At that time, ARIN, or the RIRs as a group, could decide to make an actual recommendation. But we did want to make sure at least the legal advice that we commissioned in terms of one option was in there, and it has been submitted.

The two URLs are here. And as I said, it’s not usually the type of thing we do, but in this case, if we hope to see progress in the ICANN accountability so that that third pillar can make progress to get us to close, sometimes it’s necessary to help out and give a little push.
So the only other thing I’ll say is regarding the process. So the NRO EC has directed that an SLA be drafted by their legal teams using the CRISP team principles. All the RIRs have their legal teams working on this together.

If for some reason we’re going to depart from what the principles are given by the CRISP team, then it’s our recommendation at ARIN that it be done in an open manner; that the suggestions for changes to the draft that comes from the legal team be clearly shown so you folks can look at it.
I don’t know whether or not any changes are going to be necessary. I can say the terms that the CRISP team provided are pretty clear, but we’re not the only ones in the room.

It is essential, however, that no matter what happens at the end of the day the community has an ample time to review, comment, and discuss the draft and that when we get down to the final point of saying this is our relationships and our agreements, that the final end product doesn’t have anything that the community has not seen and been through a public consultation process.

It has to be something that you know we’re agreeing to, because, quite frankly, these agreements are going to be what structures our relations between parties for decades to come. So we want to make sure everyone sees them before they actually get put in place.

That’s all I have. Thanks.

Bill Woodcock: On to the Q&A. I believe Milton was first.

Milton Mueller: I have some very important supplementary information in terms of some of the issues you raised in your discussion, but just as a preamble I’d like to say that I think the CRISP proposal is great and I think you should stick to your guns totally when you’re dealing with ICANN legal.

If you could go back to your very first slide, I think there was a diagram there that I think John was talking about that just shows a very simple structure.

So I think the key correction I’d like to make in your analysis of the situation, which otherwise was spot on, Bill, is that the CWG, the names community, is not deadlocked on – because it’s waiting for the CCWG to finish its work. They’re deadlocked because they cannot decide or agree on whether they want an external model of accountability or a purely internal one.

If they go purely internal, then, yes, almost everything they do is dependent on the CCWG. But there is a proposal – imagine that IANA function there in that bottom box is put outside of ICANN as a legally separate affiliate, which is still wholly owned by ICANN but it has its own semi governance structure. That’s what they’re talking about now.

We’re hoping that that can bridge the differences between the internalists and the externalists, if you will.

And the reason that’s very relevant to you is because in effect the names community – some of us, anyway – are very interested in creating the same kind of contractual relationship between ICANN and IANA. We’re interested in getting the policy morass away from IANA, and we think that legal separation is the way to do it.

Now, the key point that you made, which I think I can help you with, is that you said that NTIA was – or that ICANN was telling you that NTIA and congress would not accept this kind of separability that you’re going after. And I can tell you that that may be true – well, you don’t think it’s true of NTIA because you’ve gotten –

Bill Woodcock: We’ve not heard it from NTIA.

Martin Mueller: You’ve not heard it. But I can tell you definitely that it is not only not true of Congress, it is directly the opposite of what Congress is actually publically saying.

So let me just cite two documents there. The Senate Commerce Committee, with which I have met and other people involved in this have met, has made it very clear that they’re very interested in separability.

There’s a letter from Senator Thune which specifically says that this is something you have to do for us to get approval. And then recently Sidley Austin legal team includes a former member of Congress, Representative Boucher, who’s known as a progressive guy, very interested in Internet issues – when Sidley Austin team released a discussion draft proposing this legal affiliate relationship and an internal solution as the two options, he intervened with a statement saying: Congress will insist that you go with the legal separation option.

So to me it’s very disturbing that ICANN legal – first of all, that ICANN legal is telling you something different from what the Board is telling you, but then I’m used to that. But, secondly, that ICANN legal would be telling you something that’s obviously not true.

Bill Woodcock: Again, this is stuff we’ve heard verbally from several different sources, but we would like to have everyone’s position clear, transparent, public, on the record.

So we can’t speak for ICANN legal. Right? We need, in the absence of that clarity right now, for them to put their position on the record so that we can have a public response to it and a public discussion around it.

So, again, all we can tell you is what we’ve heard and why we think this might be an area of problem. But until they say something on the record, we can’t really do anything with it. And so that’s sort of our – what we believe is the next step in that area.

If ICANN legal has issues that Steve Crocker was not aware of, then we need ICANN legal to bring those issues to the fore. We have an open and transparent process in which that can be done, and that can even include behind closed door meetings with the RIR legal team, as long as the issues and positions and outcome are all made public.

Milton Mueller: Well, I know that this final comment will be more relevant to the names community than to here, but I just think it’s extremely important to separate the accountability of ICANN’s policy making process from names from the accountability of ICANN.

And the idea that this little 4 percent of ICANN’s overall budget that constitutes IANA is going to be adequately overseen by a policy process – by removing Board members that are appointed basically for policy making reasons, I think that’s a pretty wild idea.

Bill Woodcock: I think I speak for all of us when I say we all believe that the accountability issue is a serious and substantive issue and that there is a track for discussing it and that this is not it. And neither is the CWG.

And so our problem has been that this very important issue is being discussed in a different place than was anticipated when we all put together the timeline under which this was all going to get done.

So this difficult conversation is taking place in a – we’re past – we’ve passed zero on the countdown. So the place – the accountability working group, where that was supposed to take place, has more time. So we think the conversation should move from CWG to there. We’re in the in any way discounting the importance of that conversation.

Milton Mueller: What I’m saying is you can slice the accountability problem in half. There’s the accountability problem of IANA which is relatively easy to fix particularly when you have a contractual relation, and there’s accountability problem of policy in ICANN which is a very big problem.

Bill Woodcock: Thank you very much, Milton. Jason and then Rob.

Jason Schiller: Jason Schiller, Google and the NRO NC, ASO AC.

Section III.B makes some reference to asking the NRO NC to undertake a review of the security and stability of the RIRs and their mechanisms and make recommendations for improvement.

No one has formally asked the NRO NC to do this work. I would love to do this work for you. We’ve asked the NRO EC if we should undertake this work. They have not come back with a specific statement of work.

So my question is what is the CRISP team and what is the ARIN Board doing to make sure we can fulfill this?

John Sweeting: What was the first part?

Jason Schiller: Section III.B makes a recommendation that the NRO NC look at the stability and security of the RIRs, review the matrix and make some recommendations.

John Curran: This is the – a CRISP team proposal includes a suggestion that the RIRs review their own accountability mechanisms. That is on the open agenda items for the NRO EC. I know that in the case of ARIN we haven’t made a recommendation one way or the other. The ARIN Board is due to discuss this topic tomorrow morning.

So we’ll come back and we’ll make a recommendation. And it could be that we have the NRO EC do it. It’s not what the NRO EC was originally set up to do, but it’s certainly possible. We can convene an independent team much like the CRISP team to do that.

There’s a lot of different ways of getting that done. But the RIR executives haven’t had time to confer with their organizations and come to one view. It is known to be an open item. It was recommended in the CRISP team we need to come up with some way to review our own accountability.

I will note that materials for the accountability review, we have already started on. So there is already out in the NRO EC website an RIR accountability matrix which is getting more and more detailed by the end of the day.

Jason Schiller: What I heard was ask again later.

Bill Woodcock: Not too much later.

John Sweeting: Tomorrow afternoon.

Ron da Silva: Ron da Silva, Time Warner Cable, also NC and ASO AC. First of all, John, thank you for sharing the synopsis on the legal opinion for the California stuff. I think, for clarity, I had a question under that review: Is it a particular constituency that can remove their respective Board member, or is it a mix up or some –

John Curran: Each his own.

Bill Woodcock: These are called designators under California law. The ASO is a designator of two Board seats. No one can remove those two Board members without your approval or action, and you can remove them at any time for any reason.

Ron da Silva: Thank you.

David Conrad: David Conrad, ICANN, speaking only for myself. It’s not like anyone would want me to speak for them.

(Laughter.)

On the topic of termination, my understanding, which may and probably is wrong, is that Larry Strickling at the State of the Net conference back in January had indicated that he’s open to essentially any model but in order for a model to be accepted it has to demonstrate the same level of accountability that ICANN is working to implement.

So the question then would be assuming that ICANN is not the IANA function operator at the choice of the RIRs, what – or rather how will the RIRs demonstrate the level of accountability, and that’s across all of the five RIRs, that is currently at least in theory going to be proposed by ICANN in the future?

Bill Woodcock: Let me take a stab at that, then maybe my colleagues can elaborate on it. I think the first thing is that, number one, this is not an issue at the outset. All five RIRs are clear that we have full confidence in ICANN and that ICANN has done an excellent job.

I would like to point out, David is a modest person. There was a time when ICANN was unable to meet even the most basic SLAs. They hired David to fix that problem, and he did an excellent job. Barbara also was a big part of making that happen, making ICANN go from being an organization with very long lead times after which you had to poke them again and figure out where the ball had gotten dropped to one that operates like an operational organization with a ticketing system and time to respond and so forth.

So that situation is one that we have full confidence in at this point.

So the question is: How could we have full confidence in another organization and how could we demonstrate to NTIA that we had a process to guarantee that? Is that essentially – no, okay.

David Conrad: No, I believe, and I’m going on hearsay here, but my understanding is that ICANN has this – in theory. One may argue whether it’s in reality – but in theory has this vast array of accountability mechanisms to prevent capture, to prevent double dealing and all that sort of stuff.

If ICANN is not in the picture, if the RIRs decide to go and wander off and do something else, implement the separability, in order for any proposal to move forward, according as I understand to Larry Strickling, the RIRs would need to demonstrate the level of capture prevention, double dealing prevention, the whole nine yards that goes into the accountability stuff.

Bill Woodcock: So the implicit notion here is that NTIA knows what we need more than we know what we need. And this is the inherent problem with a three party situation, where ICANN is responsible to NTIA for services provided to us.

We are a large global community who have a professional interest in the outcome. We are adults. We can figure out what we need.

Now, that’s a separate issue than demonstrating that to NTIA’s satisfaction. And so, yes, there is an inherent difficulty with moving from the three party to two party situation. We have to show them that we’re adults to their satisfaction.

I think we have some structure here. We have the review committee structure defined that is intended to hold the contractor to the SLA and to sort of evaluate ongoing performance.

I think any RFP in the future that entertained competitive bids for this service would have to be evaluated very carefully as NTIA has done in the past and has not in fact awarded this contract any bidder other than ICANN.

So I don’t have a good, clean answer for you, because this is kind of hearsay, hypothetical, future, whatever. I agree that it’s a messy area and I think once we’re through this kind of issue that’s caused by the three party thing, we’ll have a much simpler two party arrangement where we as the customer and ICANN as the service provider can hammer out what we need, once NTIA is out of the picture.

But I don’t have a good clean answer to your question. I agree it’s messy and difficult.

Michael Abejuela: I think the only thing we can say as we’re drafting this and we have this proposal going forward, any type of accountability structure we’re relying on – let’s just say this. The way the SLA is being drafted is that obviously we contemplate that ICANN seems to be the operator that we would be going with, at least for an initial term, and that we’re drafting it to that sense.

However, the SLA itself in any kind of proposal contemplates whether there’s the possibility of another operator. So any kind of mechanism – essentially, if we can say that ICANN is accountable, then we need to say that any other operator would be accountable, and I don’t know if that really makes sense that way.

Bill Woodcock: David, I acknowledge this is a difficult rat hole. We’ve got four other people at the mics. So Rob.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC, speaking on my own behalf. Could we get back to John’s final slide just before the Q&A.
My mom says you should find something you’re good at and do it for a career. So I’m going to belabor a point and pound something into the ground, because I’m sort of good at that.

And I apologize to Michael for directing most of my comments at him, because he’s the lawyer and lawyers negotiate. And so my comments have to do with the last paragraph up there involving review comment and transparency.

I have a copy of the final proposal open at my seat. The section for SLA principles, they’re all high level. You spoke of getting a draft to the RIR CEOs by the end of the week. Will we get to see it then? If not then, when? What exactly is the process that you’re using to get those from high level principles to points? I kind of want to see what the lawyers are up to and not have any surprises.

Bill Woodcock: Since you directed it to Michael, let’s have Michael go and then John.

Michael Abejuela: The first question, the answer is no. It’s not that we will be releasing it to the community by Friday. What it is is that we’ll be having a draft that we submit to the RIR CEOs, because it’s essentially we’re doing this on the behest of the RIRs. We are the staff of the RIRs.

And now it’s them to release a draft for community consultation.

Rob Seastrom: Friday was a rhetorical question obviously. If not then, though, when?

Michael Abejuela: That is to John to respond, I think.

Steve Ryan: The great thing about lawyers is they have clients.

(Laughter.)

John Curran: So I’m one of those clients. And I just want to be clear. Once we get the draft that comes back from all the RIR legal teams, which we’re hoping to get very shortly now, then each of the RIR CEOs will look at it, review it, try to figure out whether or not it’s got anything that is substantially wrong with it, and then we’ll also discuss with our Boards can we actually enter into this, because ultimately these organizations will be committing to this.

And then, once that happens, we’ll send it out, including anything we’ve added above and beyond the drafting.

Now, at least that’s ARIN’s recommendation.

How long will this take? I don’t expect it to take more than a week or two. The hardest part has been ramping up to this drafting and getting everyone – because everyone’s written different sections – and getting them all together.

So I would anticipate we’re looking at the end of the month for having something that you can all look at. That would be my rough guess.
One more little administrative detail. We are breaking at 12:15. So at some point the microphone queues are going to close, but Pete can handle that. At some point, this all ends.

Rob Seastrom: Stay up there, John. So what I want on behalf of the community, and I’m hoping that I have colleagues who pile in behind me at the microphones, is not just full transparency but transparency that goes above and beyond and is completely beyond reproach and no surprises whatsoever.

And I would like a commitment for that from you.

John Curran: Could you tell me what you mean by that?

Rob Seastrom: What I mean is no last minute stuff. No things that get tacked on at the last moment and then go through. Nothing that hasn’t been subjected to the full public review period.

John Curran: I’m going to say it’s my recommendation to the ARIN Board that the final end product contains nothing that has not been through a public consultation process.

I note that if five organizations have to sign this, not to mention it’s got another party on it, like ICANN, that there will be editing going on right up until it’s ready to go.

Now, obviously the consultation cycle and the editing cycle need to be synced up, but I don’t know whether or not – when you say everything will go through the full consultation cycle, what you mean. In other words, if a sentence is changed, do you want 90 days and all five RIR communities to review it again?

Rob Seastrom: I suppose that’s how substantive the change is.

John Curran: That’s why I put the final sentence: The final end product contains no component that has not been through the public consultation process. I don’t know, it may be a five day consultation. I don’t know. But you can’t commit that everything restarts the clock every time or you have a nonterminating situation.

Rob Seastrom: I understand. Thank you for the clarification.

Bill Woodcock: Owen and then Paul.

Owen DeLong: Owen DeLong. I have two questions. I’m going to ask the first one. Can we go back to where you were talking about ICANN not necessarily remaining a US organization. I’d like to compare and contrast that the ICANN Board is compatible because of California law.

Bill Woodcock: Again, so I agree that the accountability issue is really important. Speaking really speculatively here. We recognize there’s a lot of pressure from the international community on ICANN to demonstrate its international nature and that it is not captured by the US government.
As people who work closely with ICANN, we understand that this is a more adversarial than capture sort of relationship much of the time.

So I don’t see that as much of a worry. Personally, I think California law is really good for this sort of thing, and I can’t really think of anywhere better. But that’s separate from – I mean, if I were a lawyer in Tokyo or an Internet service provider in Moscow or something, I might have different opinions about that.

And the international community is the community that ICANN serves. The international community includes the US community but not exclusively.
We were just kind of speculating here that it would be politically very difficult for ICANN to say we will never become anything other than a US entity.

So assuming that, then this agreement that NTIA wouldn’t approve an agreement that said that you could transfer to something that happened to not be a US entity doesn’t really apply to ICANN either. That was all that was going on there.

Owen DeLong: I got that. But then it strikes me that under that circumstance, depending on the fact that they’re currently subject to California law is the underpinning of accountability is tenuous at best.

Moving on to the second question, I want to make sure to verify how we know the end result and implementation will be what the community agreed to during the development of the CRISP team proposal.

Michael Abejuela: The one thing that we will say about that is we are drafting it with an eye and guided by the CRISP team principles. Now, the one thing to be very aware of is that if there’s anything that is somehow inconsistent or needs to be consulted on, that that will go through the public consultation process.

I think that’s what’s been said is that we do have the CRISP proposal and that has gone through the whole community consultation, and we are guided by that, but if for some reason in this whole process there’s anything that needs to depart from that or have some sort of inconsistency, the key thing here is that it won’t be done without proper community consultation.

Paul Wilson: I’m Paul Wilson from APNIC. I thought I’d mention here that last month APNIC had a meeting like this one where the CRISP proposal was discussed, and we were the first in the cycle of RIR meetings, and we’re the first in the last cycle. It’s a good six months between our meeting where we considered this whole question and our next chance to see the new CRISP proposal.

So the point of that meeting was very much, I think, what Owen was looking for, which was a review by the community that what was actually under development and what had been put forward was consistent with what had been imagined by the community members in the first place.
We had a fairly wide ranging discussion because a lot had happened in that six months. And we looked at – I think really what the meeting looked at was the kind of negotiatability of some of the questions or some of the conclusions in the CRISP proposal compared with the sort of more vague discussions that might have happened in the first place.

I mean, it was a wide ranging discussion, but the end result and the Chair of that session who was in fact one of the CRISP team members drew the conclusion and expressed the conclusion that the APNIC community was completely satisfied with what the CRISP team had put forward. So I just thought I’d mention that here.

On another issue, the issue of negotiating the SLA, and this goes to the discussion before about – again about what the community is expecting. The CRISP team has asked the RIRs to sort of coordinate or conduct that negotiation.
And I guess there are different viewpoints about how that works, how that should work. Some people seem to have assumed that sort of the organizations concerned will go away and negotiate substantial aspects of this agreement and come out of that black box and declare what the result is.

But I think from the RIR point of view and also from the ICG point of view – by the way, I’m one of the NRO delegates, designates to the ICG – the assumption is definitely of a bottom-up community process, absolutely, and so – I mean, that should be the guiding principle here.
On the other hand, though, and from an RIR point of view, when we’ve got a negotiation that involves the organizations themselves having to get together and get together with the other party as well, I think the RIR Boards have got a very strong concern about their responsibility and making sure that that negotiation preserves the stability of the – the fiduciary responsibility, the stabilities of the RIRs, et cetera.

In terms of the issue of the contract at will, that seems to have been the express desire of the communities, but I would say that – and this is a personal opinion only – that the termination at will may not be seen to – assuming that it actually is a mutual provision, you don’t get something like that one sidedly.

Bill Woodcock: Let’s clarify. Right now it is at will and it is one sided. What we’re asking for is bi-directional on a reasonable notice.

Paul Wilson: I guess without drilling too far down into that, what all of the provisions behind that would be, there is a stability issue there where if we are submitting ourselves to termination at will, you’ve obviously got a question there that comes to the stability of the system and the stability of the RIRs and the fiduciary responsibilities of the RIR Boards.

But that said, I think the RIRs are very well versed in a bottom-up process. And as John tried to say earlier, I don’t think any of the Boards will be – this is a personal view – I don’t expect that any Boards would be coming up with a surprising result that was obviously going to be surprising to the community out of a negotiation on something like that.

There will have to be a maximum level of bottom-up transparency.

On separability, I wanted to finally just quickly mention my personal view on that, which is the lack of separability between IANA and ICANN was not one of the express conditions of the NTIA in announcing this transition.

So that I don’t think was just an omission. I think if you look at the history of the NTIA’s contracting of the IANA function, there has always been an assumption of separability there. We’ve gone through several cycles where IANA functions could have been separated out and contracted everywhere else.

I think what’s being proposed here is no more or less than that, than a continuance of that situation. So there’s an assumption that’s been part of the environment so far. And I think the assumption – it’s reasonable that that assumption continues.

But I think maybe there’s been some misunderstanding. We need to be very clear what we actually mean and what the circumstances would be behind that, the possible circumstance where things would be separated.

Bill Woodcock: Thank you very much, Paul. I’d like to remind you we closed the mics after Paul and Vint. We have two minutes left in the session. So if you have something really short and pithy after Vint, we can do it, but let’s not go any further than that.

So Vint.

Vint Cerf: Thank you very much. It’s Vint Cerf, Chairman of ARIN. I wanted to make an observation about some comments that were made earlier regarding the parties involved. There’s actually more than two or three parties involved. The real honest answer is that this is a fairly complex multi-party negotiation that’s going on.

It’s not just ICANN. It’s not just NTIA. It’s not just ARIN. But it’s all of the RIRs and it’s the US Congress.

And I think that pragmatics are going to have to be a part of our analysis and understanding and development of either strategy or tactics or both, if we want this whole thing to resolve.

We can’t ignore the fact that there are parties that don’t normally make up part of our universe who have an interest in this and have the ability to interfere and intervene. So as you think your way through all the public exchanges that go on and the proposals that are in place, just keep in mind what the actual real setting is for coming to any kind of a successful consensus.

Bill Woodcock: I think honestly that’s really been the driver for the transparency and openness principle. Whenever you’re in a situation this complex with this many parties, many of whom are unaware of each other or each other’s interests, the only way to hammer it all out is to get everything out in public where everyone can see it and discuss it.

Vint Cerf: So I don’t disagree with this preference, but I must say that there are some parties in this debate that don’t normally behave that way.

Dmitry Burkov: Dmitry Burkov, RIPE NC Board. Just a few of comments on CRISP. I’m going to appreciate the CRISP job, but it looks to me the CRISP team escape some sharp questions and sharp corners. And the result goes to what was the initial goal of IANA transition. If it’s just as you can read on the slide, is just internal US deal, who cares. If it’s about how to find the global consensus, currently we have not any solutions or proposed solutions out of scope. Thank you.

Bill Woodcock: Okay.

Mike Joseph: Mike Joseph, Google. Quick question, then. There’s clearly an importance on the SLA document and contract that’s under negotiation across the RIRs. So what would be the mechanism under this new policy and contractual regime to change the SLA document and contract in the future?

There’s obviously – obviously all the specifics for accountability and compliance are called out – are to be called out in this as yet unwritten and unadopted policy. So how will this policy iterate?

Bill Woodcock: I think there’s a debate going on right now sort of between the CRISP team and the NRO EC over whether the CRISP team or the future review community or what – what exactly the ongoing sort of future work, how that will be instantiated.

Essentially the CRISP team operates at the will of the NRO EC. Right? Kind of. But also the CRISP team or something like it is necessary to fulfill that role relative to the ICG.

The initial document is done. We could fold up the CRISP team right now. But then how do we do the oversight of the remainder of the process up to contracting. You could fold up the CRISP team then, but probably only if the review committee is fully established and ready to go to make sure the SLA is being adhered to. Then what do you do when you decide the SLA needs to be changed.

So this is an ongoing conversation. I think we would all be much happier if we had a little more surety, and I think we look to the NRO EC to provide that.

John Sweeting: Basically asking how the contract will be changed? So maybe Michael has some –

Michael Abejuela: Is that the question you’re asking, is how the terms of the SLA would be changed?

Mike Joseph: There’s a process right now to draft the SLA. But we envision there will be a need to change the SLA. What’s the framework in place or will be in place to review, periodically review, and make modifications to the SLA?

Michael Abejuela: Because I want to make this short and concise, the draft SLA has not been finalized yet. However –

Mike Joseph: I get that.

Michael Abejuela: However, contemplating basic contract principles, a lot of times the terms of the agreement can’t be changed without the ascent of all the parties involved. In this case we envision that it’s – ICANN is the IANA numbering service’s operator and then the five RIRs collectively.

So I imagine, if we are going down a reasonable path, that no change would happen without full consent from all the parties. At that point, though, with the RIRs, obviously then we have the five RIRs would have to sign off on that, and I imagine because we have an open bottoms up process, they would not be quick to make any such change without consulting the community in that sense.

Mike Joseph: That’s good to hear. I think the final point is I think it’s important that we make sure there’s some regular review and forum by which those changes can happen, because ICANN’s probably not going to suggest changes to the SLA document in our favor.

Bill Woodcock: Right. Term 7, RIRs will be able to periodically review the agreement and evaluate whether they want to renew the agreement.

Mike Joseph: We just need to make sure we actually periodically review the agreement.

Bill Woodcock: And we need a process to ensure the community input into making that happen, and that hasn’t been enacted by the NRO EC.

John Curran: Out of time. Thank you, everyone. Round of applause for our panel.

Two things to note. Lunch table topics. When you go out, there’s tables set up that have cards on them that identify certain topics. If you want to talk about those topics, find those tables. When you don’t want to find those tables, find any table.

(Lunch break 12:22 P.M.)  

John Curran: If people will come in and get seated, we’ll get started. Welcome back. We’re resuming the ARIN 35 Public Policy Meeting. I’m John Curran, President and CEO of ARIN.

This afternoon we have policy discussions. Policy discussions include 2014-6, Operational Reverse DNS Text; 2014-21, Modification of the CI Pool Size; and 2015-1, Modification of the Criteria for IPv6 Initial End User Assignments.

At the head table, I have Paul Andersen, Dan, Kevin, Andrew, and Vint Cerf. Not that late, though. I’m going to ask that Rob Seastrom – I’ll do the introduction and then have Rob come up. We’re in the policy block. We’re going to go through each policy. I ask people to be polite when you come to the microphones.

I’m going to introduce each policy. I’ll then ask the Advisory Council shepherd to present, and then we’ll have a discussion. So first up, Recommended Draft Policy 2014-6.

Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text

John Curran: Okay. The history. This originated as ARIN Proposition 198 from January 2014. The shepherds are Robert Seastrom and Kevin Blumberg. It was presented at NANOG 60, ARIN 33, NANOG 61, 62, ARIN 34, and NANOG 63. Getting a little long in the tooth now.

It was advanced to Recommended Draft Policy in March 2015. The AC did that at its meeting. Its text is online and in your Discussion Guide.
The proposal would remove Sections 6.5.6 and 7.1, removing reverse DNS language from the NRPM. It would not change the DNS service we perform.
It’s removing the text that’s in the policy manual. We do occasionally have people asking how reverse DNS services can be set up. And we do explain that process.

We explain it can be set up for them if they’ve received a direct allocation from us; otherwise, they need to work with their service provider.
There is occasions where we point to the language in the NRPM. But we don’t need to point to the language in the NRPM to answer these requests.
In case the language is removed from the NRPM, the staff will create a resource for the ARIN public website that describes how our reverse DNS services are provided, including who is able to establish reverse DNS service for the different types of registration records.

Does not create legal concerns. The implementation would be minimal in terms of resource impact. It would occur within three months of ratification by the Board of Trustees. We have to update the guidelines describing reverse DNS services and we’d have to have a little staff training.

At that point, I’ll now bring Rob Seastrom up and he can do the AC presentation.

Rob Seastrom: Thank you, John. I’m Rob Seastrom. I’m the shepherd for this proposal, which – is this not working? There it goes. There we go.
2014-6. This is the proposal formerly known as remove 7.1. And the reason it’s formerly known as 7.1 is that a lot of the previous discussion on this proposal has centered around, hey, you’re removing IN ADDR for IPv4, why are we not removing it for IPv6?

If we believe that one ought to be gone, perhaps both of them ought to be gone. These are technical operational details. It’s not numbers policy.
To the extent that we document this – and I personally am of the opinion that it ought to be documented – it belongs in a stand alone document that is more detailed, more approachable and more easily evolved than having it be part of the NRPM. Particularly because it’s not numbers policy.
So the revised proposal treats IPv6 and v4 as the same. Gets rid of reverse DNS language in the NRPM for both. And the policy statement is very simple. Remove two sections from the NRPM.

Questions. Microphone.

Mike Joseph: Mike Joseph, Google. I support this policy, but I lament the lack of a services document which ARIN has previously committed to publishing.

Could staff comment on the status of the services document?

John Curran: So on Wednesday morning, there’s a fee and services update. Part of that involves having a discussion of a services working group which has been sent to the ARIN Consult Mailing List.

If we can get agreement to have a services working group, then this is one of the documents that they would prepare.

Rob Seastrom: Anybody else? Microphones will be closing soon.

Vint Cerf: I’m trying to figure out whether I can hear myself or not. Hello, hello, are you there? Does the absence of any discussion mean there’s general consensus at this point? Am I seeing people are nodding or shaking their heads?

Do we hum here? Okay.

Rob Seastrom: I’m ready. Go ahead, sir.

John Curran: Thank you.

(Applause.)

John Curran: On the matter of Recommended Draft Policy 2014 – put the other slide up. People need to be able to see what they’re going to be doing a show of support for.

Here we go. Okay. On the matter of ARIN 2014-6, we’re going to ask a show of hands for the community for everyone in favor of this policy. Saying you’re in favor means you want to advance to the next step, which probably means that the AC would send it to the Board.

And everyone opposed. And so I see my tabulation engine is out there. Other RIRs put a lot of money into systems and phones and gadgets, and we have good old fashioned people. I see my good old fashioned people are ready.

So on the matter of 2014-6, Remove Operational DNS Text, all in favor, raise your hand now.

Nice and high. If you’re a remote participant, participate in the jabber room so your support can be counted. Nice and high. If your elbow is bent, you’re not holding your hand up correctly.

You may put your hands down. Okay. Everyone opposed to 2014-6, raise your hand now.

Remote participants, remember to jabber if you need to. We’re closing this shortly. Thank you everyone. Okay. The tabulation is being done. Give it a moment.

This gives us an opportunity to entertain you during the polling, unlike those instant automatic systems. Amongst other things, this is an opportunity for me to talk, to sing, all sorts of opportunities.

John Curran: You have heard me sing. There’s a video of me out there. I had to sing to get my gong back, if you remember correctly, in Vancouver. It was bang a gong by whoever they were.

On the matter of 2014-6, Remove Reverse DNS Text, number in the room, 83, plus remote, 10, for a total of 93. In favor of the policy, 29 in the room, three remote, for a total of 32 in favor. Against, 0.

This information will be provided to the ARIN Advisory Council for their consideration. Very good.

Recommended Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4

John Curran: Next policy. Okay. Next policy is Recommended Draft Policy ARIN 2014-21: Modification of the CI Pool Size Per Section 4.4.

This originated as ARIN Policy Proposal 213 in October of last year. The AC shepherds: David Farmer and John Springer. It was presented at the PPC at NANOG 63. It was advanced to Recommended Draft Policy in March 2015. The text is online and in your Discussion Guide.

The policy changes one section of existing NRPM policy 4.4 to extend the current reservation size for critical infrastructure and exchange points from /16 to /15 equivalent.

We currently do have a pool. It’s /16 total space spread out among a number of pieces. A total of 35 /24s have been issued from that pool for CI and ISP, since the policy was amended and implemented in March 2013.

That leaves 221 /24s available in that block. Again, this is a critical infrastructure block which is reserved for purposes of specific application, critical infrastructure, exchange points similar.

There are currently 381 free /24s in the two /8 ranges used for CI and ISP micro-allocation. So that’s in terms of the total space. CI micro-allocation. This policy could be implemented as written. This policy does not create a material legal issue.

It would have a minimum resource impact. It’s estimated that the implementation would occur within three months after ratification by the ARIN Board of Trustees. We need to have an internal guidelines updated and staff training.

And now the presentation by the AC, by David Farmer.

David Farmer: So we’ll move along here. I found the right button. Here’s the problem statement. Basically states that IXPs were having a bit of a growth in the North American region and want to make sure we’ve got resources to make that growth happen. Pretty much a restatement of what John just said, except for John’s numbers were when the staff assessment was done.

There’s been a couple more done. At least by my math it’s 38 now. Maybe I failed basic math. I don’t remember. But we’ll see. Discussion on PPML. There has been some support. No opposition in the emails on PPML.

At the PPC at NANOG there was both some support and some opposition. Not a whole lot of discussion.

So continuing the summary: Even if the free pool runs out prior to this being implemented, there will be some pieces coming from IANA and that should easily be more than a /16, so we can still do this.

This is the actual changes to the text, as John said. Basically substitute the /15.

Discussion: So is reserving an additional /16 equivalent, necessary and justified? We’ve done 38. There’s 218 left equivalent to /24s. But then again a /16 in the scheme of all of v4 isn’t that much, so we need to know what you all think of it.

Lee Howard: Lee Howard, Time Warner Cable. So in the current environment, when we consider the context of saying that we’re running out of address space, telling me that we’ve used 15 percent of a designated pool doesn’t seem like runout to me.

I started to do some binary math and I didn’t get there very well. So you say an additional /16 isn’t that much in the overall scheme of things. How many /16s does ARIN have left?

Lee Howard: 55. A /16 is a lot. In fact, we’d be setting aside, sounds like, 2 percent. That one I could have managed.

(Laughter.)

So, I mean, that’s a lot of address space to be reserved for something where we’ve only used 15 percent of the current set aside. Thanks.

Bill Woodcock: Isn’t 2 percent more than 1/55th?

Rob Seastrom: It’s 1/50th.

Bill Woodcock: Anyway, sorry. You said 2 percent seemed reasonable, but 1/55th did not. Anyway, as someone who deals with exchange points professionally, in my day job, I would say this does seem to me to be justified because all of the network operators have some v4 space and some v6 space and more v6 space going forward and can do 4 to 6 NAT, so on and so forth.

And exchange points that are created a year from now or five years from now do not have that option and have to be able to support dual stacking on every address that they allocate.

In addition, there may be – sorry, there will be additional exchange points that cross the boundary of needing more than 256 addresses, and so we’ll need to migrate into /23s.

Or even, hypothetically, in the future, /22s. So I would say looking to the long term it’s going to be 15 years before we no longer need v4 at all, unfortunately, probably. So this pool has to last 15 years.

This pool is not supposed to run out when everything else runs out. It’s supposed to run out when nobody cares about v4 anymore.

Martin Hannigan: Martin Hannigan with Akamai Technologies, also the cofounder of Open IX, IXP standards body, although I’m not representing that opinion here today.

I am representing the opinion of my employer. Also I’m a member of the France IX Board of Directors, the Toronto Internet Exchange Board of Directors.

I’m on the AMDIX U.S.A. Advisory Board, as well as the RBAIX Advisory Board, et cetera, et cetera. Connected to over 100 IXPs in the world.

I like to think I might know a little bit about what I’m talking about. I support this policy. I actually authored it, and I think Bill made eloquent justification for it with respect to time.

These measurements are red herrings, basically. If you look at the whole pool, this is really noise. And I think this is pretty important. I think if we’re off an order of magnitude, we can always come back in seven years and adjust this and be just fine.

But I think it’s better for us to be in a position to have too much than too little, because when we figure out that we have too little, it will be too late.

Thank you.

Mike Joseph: Mike Joseph, Google. Why wasn’t this policy expired from the NRPM last year when it was scheduled to do so?

John Curran: That one looks like, for me – hold on – the implementation of the policy. You mean the CI pool policy?

Mike Joseph: The /16 reservation was scheduled to expire last year.

John Curran: Give me a moment. I’ll let you know.

Scott Leibrand: The original policy proposal that we adopted had something in the rationale or implementation timeline that said something about after a certain date, then the space would be available for ARIN to use consistent with community expectations or something like that.

John Curran: Understood. I’ll research it. But I’ll respond. But it’s going to take a moment.

David Huberman: David Huberman, Microsoft. In 2004, we had an ARIN meeting in Reston, Virginia. It was very memorable for me because first it was the first time I’d ever been chastised for using the word “IP” to refer to an IP address.

And that same person, Scott Bradner, got up to the microphone quite a few times at that meeting and said just give the space away already, we can’t get, meaning fully get to v6 as long as we’re grasping to the last bits of v4.

That was 11 years ago. And I don’t care if it’s 2 percent or nominally 2 percent, this to me has a persuasive technical need. And let’s give away the v4 already.

Kevin Blumberg: Can I ask a clarification, David? When you said “give away the space,” you’re saying put it into this pool so that it can be used because it’s not actually giving it away now. It’s actually storing it.

Okay. Thank you.

Martin Hannigan: I think it was July 10th, 2012, where I submitted the proposal for this or the last modification to this where it actually – the policy term was marked permanent.

John Curran: I’m pulling that now. It’s the 2012 2 modification. I’m going through the change log. Just give me a moment.

Heather Schiller: You won’t find it in the change log. It’s in the rationale of the original proposed text. If you check your email, I sent it to you.

John Curran: Right. The question is whether or not the subsequent changes made it permanent.

That’s why I have to go through all the change logs for 4.4, to see whether or not the reserve changes that occurred afterwards in 2011 and ‘12 revised that.

Jason Schiller: Jason Schiller, Google, NRO NC. It was made permanent. However, the permanent policy still references the term which is not specified only in the policy but it is specified in the original rationale which was 36 months.

John Curran: Right. That’s been interpreted to be permanent.

Jason Schiller: For the term which is unspecified.

John Curran: For the not defined term.

Jason Schiller: Yes.

Mike Joseph: But the only definition of term is the one that says 36 months. It’s still in the NRPM. The actual text of the NRPM references removal of this language.

John Curran: As a policy term, 36 months following implementation in the 2011 4 reserve pool. There’s no policy term shown on the subsequent modifications such as 2014-3.

So there’s a policy term for the base policy, but we’ve since revised that section twice with no policy term statement in the subsequent revisions.

Mike Joseph: Except that the policy statement remains in the NRPM through those revisions.

If you look at the NRPM today, it reads: If at the end of the policy term, agreed undefined in the NRPM, but we can infer what was meant by that, then there is unused address space remaining in this pool. ARIN staff is authorized to utilize this address space in a manner consistent with community expectations.

John Curran: Correct. But since policy term is no longer defined, and we have actual discussion going on right now about extending, right now the community expectations would appear that this pool should remain.

Now, if I did a Policy Experience Report, it would say you have an undefined term, and until you define it, we’re going to keep the pool in place.

It would be up to the community to suggest policy to change that.

Heather Schiller: Heather Schiller, Google Fiber. I believe the term was never defined in the NRPM. It was always defined in the rationale or the justification for the policy.

And the original justification said 36 months; hence, Jason’s question. Moving on from that.

John Curran: Let me respond, though. The fact that it’s not in the policy text means it’s available for you folks to define now if you wish to do it.

Otherwise, we’ll continue with community expectations, which appears to be continuing the pool.

Heather Schiller: My suggestion is to do away with the whole thing.

John Curran: You should submit a policy.

Heather Schiller: I will probably do that very shortly. The other thing I wanted to point out, there’s other problems in this text.

This is no longer a micro allocation. /24 is the minimum allocation window across the board. So the heading for this section should also be revised. I disagree with the comment that this block should be intended to last 15 years.

I don’t understand why – so I agree with the relaxed allocation criteria for critical infrastructure. I understand that they may not meet the same requirements that an ISP or end user would in order to qualify for a /24.

At the time this original policy was passed, the minimum allocation window was a /22. Hence, the section of the policy was called micro-allocation for critical infrastructure.

Now that the minimum window across the board is a /24, I don’t understand why we have to have a special reservation for this address space. Here comes everyone to tell me why.

John Curran: Heather, may I ask some questions?

Heather Schiller: Hang on, because my point is, like, yes, you can argue that critical infrastructure is just that. It’s critical to the Internet infrastructure, workings of the Internet.

But why are they a special class? And by that I mean there are for profit companies – what is it that we’re doing – like why are we protecting – they are.

Owen DeLong: Not all exchange points.

John Curran: Hold on. One person at a time.

Heather Schiller: But a lot of them are for profit companies. Not just exchange points. But gTLD operators, other operators.

So, like, there’s – so I’m looking for more explanation of why this should be considered a protected class when we don’t do this in any other – there’s no other address type that we do this for, any other business type that we do this for.

John Curran: Heather, remain at the mic. So regarding the title, this is a Recommended Draft Policy. Would you consider changing the title after the meeting to be a change that’s substantial, or would that be editorial?

Heather Schiller: It’s – I guess it depends on what you change it to, but it’s probably editorial.

John Curran: The only other question is you’ve now expressed concern about whether we have this whole category of reservation. I guess that didn’t say clearly whether you were in favor or opposed to extending the current block per the policy.

Heather Schiller: I said the first thing, one of the first things I said was to do away with it altogether. So I’m opposed to extending it.

John Curran: Okay. Thank you.

Bill Woodcock: Could I respond really quickly? Just a really specific point of fact.

My recollection is that we removed gTLD operators from this category quite some time ago and gTLD operators proposed creating a separate category, and that did not achieve consensus.

Heather Schiller: They’re still in there.

Martin Hannigan: Wow, IXP haters, I’m surprised. But just to correct a few facts. I think it’s less than 2 percent of IXP are commercial, which is 1/55th.

(Laughter.)

You have the DCIX and Equinix and CoreSite and basically you have the vast majority are nonprofit, mutual, community-based organizations.

I think you can look in PeeringDB and you can scan the I think 229 or so, including the PCH directory, which they don’t exactly match.

And I can almost guarantee you everything on the PCH directory is commercial as well. We’re probably talking in the neighborhood of 400 IXPs globally or something to that effect.

Second, I’m amenable to the title change. Second, I think it’s editorial. Third, I think that at least whenever I submitted a modification to this policy, that term one and the subsequent one, which I’ve done a subsequent times now, I always filled out the templates.

I’m happy to share the email that says policy permanent. Always. Always. Always. After the first time. And fourth and finally, the one other adjustment I’d recommend making to this policy, which I believe is again editorial as well, it’s just a clarification, recently we had a misinterpretation of what the numbers were supposed to be used for at an IXP. The company accidentally got numbered into the IXP address space. And I think it should be made clear it’s for peering, not for Web serving.

I still support the policy. I think the intent is good. It’s good for the Internet. Don’t forget critical infrastructure can also be economic as well. You’re talking about some pretty big dollars in traffic here. And I really don’t think we want to fool around. Thank you.

Owen DeLong: Owen DeLong, Akamai, ARIN AC. As Marty said, most exchange points are not commercial. There are many examples throughout the world of exchange points that are noncommercial.

But commercial or not, exchange points represent – they do represent a special class of address need. They represent the point where service providers interconnect and exchange traffic for the good of the Internet, for the ability of the Internet not to become isolated islands.

And the biggest trend in the Internet of late has been the increasing density of interconnection among providers fostered by and facilitated by the creation of new exchange points, to a large extent.

Enabling that is critical to continuing the betterment of the Internet. And as much as I would like to see v4 go away sooner rather than later, I think everybody knows my position on that subject fairly well at this point: It’s not going away anytime soon, and it’s certainly not going away from being a vital resource for building a functional exchange point anytime soon.

And, in fact, the exchange points will need to be able to do dual stack on every address for much longer than anybody else will need to do dual stack on their networks just by the nature of how interconnect works.

And so for that reason I support this policy, and I encourage others to support it as well.

David Farmer: Back mic.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC. Former operator of a really small exchange point that failed, because we didn’t have very many participants. But you would have never known without starting it up and trying.

To answer Heather’s question as to why you need the policy to allow justification of the space, which is slightly different from requiring the pool, now that the minimum allocation is /24, is that if you look at the easiest way into getting yourself a /24, you need an Internet exchange point with 64 participants to do it, if you call it an end site. And that’s sort of impractical day zero.

So we need that policy for being able to justify it at all. This is not something that’s practical to send people to the transfer market for. I spoke in favor of the transfer market when I was working for a gTLD operator for gTLD stuff.

I said there’s plenty of money. We can ante up and we use these all over the place with anycast. This is not one of those situations.

Therefore, I’m in favor of the proposal as written. Thank you.

Heather Schiller: I just wanted to be clear that I am not suggesting that we remove the allocation criteria for CI. I think that should stay in place. So they would still qualify for address space.

John Curran: That’s not the proposal on the table in any case. That’s the, Heather, future policy proposal being written, to allow CI but have it done in the normal address blocks.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. We have a /10 of reserve space right now to allow companies and individual end site companies who are doing v6 to get v4 for their needs, for their critical infrastructure. Critical infrastructure is actually mentioned in there.

And then we have this much smaller block of reserved critical infrastructure space predominantly now for IXPs with some very, very specific requirements. And it’s different.

But we have a /10, folks, that is being held for the possibility that at some point some company is going to need a v4 for their transitionals.

With IXPs it’s truly critical infrastructure not just for one company but for the Internet as a whole. And I fully support this proposal.

Jason Schiller: Jason Schiller, Google, ASO AC. I just wanted to follow up on the point that Heather was making, and that point was simply I don’t understand why we still need this separate pool when – because we no longer need micro-allocation because the minimum is now a /24.

I also wanted to point out that Prop 177 was originally the identical text that we’re looking at today which was expand the reservation to a /15 and remove the sunset term clause that is unspecified.

And we were discussing that because of all of the new gTLDs were now critical infrastructure that could use this block. And at that time we decided rather than expand the critical infrastructure block, we would continue to maintain that new gTLDs could qualify for up to two /24s per new domain name and that they would get this fulfilled not from the critical infrastructure block but from the free pool.

So there’s precedent for saying let’s not expand the free pool, let’s let them get it from – I mean, let’s not expand the critical infrastructure block, let’s get it from the free pool.

The other question –

John Curran: Pause. So you’re against the policy proposal?

Jason Schiller: I’m opposed.

John Curran: And you’ll submit something that suggests something else?

Jason Schiller: No, but I’ll prod someone to submit something.

John Curran: That’s just as good. Keep going.

Jason Schiller: The other question I have is there’s some people that have suggested that one of the reasons for having the critical infrastructure pool was not because we needed a discrete block from which we could pull smaller than the normal sized allocation or assignment from for filtering purposes, but because we wanted it to be a protected class for a long, long time, 10, 15 years, and that doesn’t seem to jibe with my recollection, especially considering the comment of we can review this in a term of 36 months.

And even today we heard Marty come to the mic and say if this is too much we can review it in seven years. And if that is going to be part of the reason why the policy passed in the first place, and part of the reason why this policy may pass, we should not remove the term limit out of the policy. We should expressly keep that in. So we should fix it.

John Curran: I’m sorry. So that’s again a separate policy proposal you’re talking about.

Jason Schiller: That’s a recommendation for a revision to this policy proposal.

John Curran: Right. Looking forward to having that submitted.

David Farmer: Anyone else who hasn’t commented please make your way to the mic, because we’ve had several people comment multiple times so far.

Lee Howard: I wanted to respond to something that somebody else had said, and it wasn’t a math problem. It was that – I’m a big fan of IXPs. They’re critical infrastructure. We’re talking about reserving address space for new IXPs for something like five, 10, 15 years from now.

Well, you know what, someday an IXP is going to be started, founded that won’t have any IPv4 addresses and it will be an IPv6 only IXP. And that will become what all new IXPs are, and that’s a good thing. I hope it doesn’t surprise anybody that we’re running out of IPv4 addresses and we’re going to be using IPv6 instead and not in addition to.

John Curran: Lee, I can’t discern whether that’s an argument why you want an extension of the block or why you don’t want an extension.

Lee Howard: So I therefore continue to oppose this proposal as written.

Martin Hannigan: So this ought to be a yoga class. There’s a lot of stretching going on in here.
So I just wanted to dive a little bit deeper kind of under the covers with respect to infrastructure and why this actually is critical infrastructure.

So if you think about IXPs at least in North America and you think about datacenters, IXPs have historically been, for lack of a term that is easy to explain, occupancy engines. Typically they create critical mass in datacenters.

What’s happened over the last decade in the Internet is that critical mass has been concentrated in too few places and we have diversity problems today.

One of the objectives of some of the work that’s happening in the IXP community is to address the diversity problem through building new IXPs and interconnecting them across different buildings and whatnot. That takes address space and that takes time.

I can’t tell you how much time that’s going to take. I can tell you right now that if you go to the, for example, Open IX website and look at directory, you’ll see a map that shows where all the certified datacenters are that are supporting these new IXPs. And you’ll see that, for example, there are other new IXPs that have come on the radar. They’re both open IXPs and not open IXIPs.

There seems to be, since the time that term “36 months” was written, it’s a whole new world. It’s basically a new planet. If we had known now what we know back when I wrote that term into the policy, we would not have done that. We would not have accepted it.

I think we should most definitely do this, and I support this policy. And, I mean, if anybody has any additional questions on the economics and the diversity issues, feel free to see me at the break or later on tonight. I can explain them in depth.

I could stand here for eight hours and go into great detail, and Vint is waving me off, so thank you.

David Farmer: Close the mics, please. The mics are closing.

Heather Schiller: So I think, again, I’m not saying that we shouldn’t have a special allocation criteria for critical infrastructure. All I’m saying is I don’t think that we should extend the – I don’t think we should have a reservation, I don’t think we should extend it, and that these organizations should be subject to the same market as everyone else, that it’s – acquiring IP space, IPv4 space once ARIN runs out will be a business expense for all organizations.

I don’t think we should be creating or propagating a protected class for that.

(Applause.)

John Curran: Thank you, David. Okay, back on the cover slide if we could. We’re going to do a show of hands. This is a Recommended Draft Policy. The AC is considering what to do with it.

So what we need to do is we need to get the polling engine set up. I see them in position now on Recommended Draft Policy ARIN 2014-21: Modification of the CI Pool Size. I’m going to ask everyone in favor and everyone opposed, please remember to hold your hand nice and high.

Recommended Draft Policy ARIN 2014-21: Modification of CI Pool Size. All in favor raise your hand now. Nice and high. Nice and high. Remote people, do your remote thing. Apparently the remote people hear me about 30 seconds later. We actually have to give them a bit of time. We’ll hold your hands up for 30 seconds, come on, nice and high.
Okay. We’re good. Thank you.

Okay. On the matter of ARIN 2014-21: Modification of the CI Pool Size, all those opposed, raise your hand now. Be counted. One hand, please. One per person. Thank you. Remote participants, do your thing. Okay. Thank you. We’re now tabulating. They’re bringing out the calculator. They’re coming in with the results.

Vint Cerf: Do we need a drum roll?

John Curran: On the matter of Draft Policy 2014-21: Modification of CI Pool Size, the number in the room, 103; the number remote, 10; for a total of 113.
In favor in the room, 21; and remote, one. That’s 26 in favor. 25 in the room, one remote, for 26 in favor.
Against, sorry – against in the room, eight; one remote. So 26 to nine.
This information will be provided to the Advisory Council for their consideration, and thank you very much.
(Applause.)

Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

Scott Leibrand: This one is a little newer than the last one. It hasn’t been through eight meetings so I get to present it without a lot of intro and get your guys’ thoughts on what changes, if any, should be made before we hopefully bring it back as a recommended draft.

So the problem statement here is fairly simple. There is a class of users who would like to get IPv6, who would like to get addresses directly from ARIN, but who are currently excluded from getting addresses directly from ARIN. If they were to get addresses, IPv6 addresses from their upstream, and then need to renumber, their costs of renumbering would be significant, because they have many, many sites. It’s 13 or more sites. And yet they are currently prohibited from getting addresses directly from ARIN.

So the assertion is that without direct assignments, these organizations would be either likely to delay IPv6 adoption or to use NAT66 or other techniques that give them some portability on their addressing and they don’t tie them down to a renumbering event.

So to address that, these slides – or the proposal is very simple. It is to add this Section E that says if you have a contiguous network that has a minimum – excuse me, I need to slow down because the typists or transcriptionists don’t like me talking very fast. So I’ll try.

If you have a contiguous network that has a minimum of 13 active sites within the next 12 months, then you would qualify under this clause to get an address block. And under the other existing part of the address manual you would get a /40 in that case if you had the 13 sites. If you had more sites than that, you could get a larger block

So the rationale here is also pretty simple; that if it’s going to cost you a whole bunch to renumber and that cost is commensurate with what it costs everyone else to carry your route in the DFC, it’s possible for you to get direct assignment from ARIN.

There is a recognition in this policy, in this Draft Policy, that those DFC costs are non zero. So to attempt to minimize that, in order to qualify under this you have to have a contiguous network so it’s at least possible for you to announce your entire block as a single aggregate.

And again that 13 site minimum threshold would require that this only apply to people who have a whole bunch of sites across that network and not just somebody who has one site. Somebody who has one site can qualify under one of the other sections under there which are pretty well established and seem to work pretty well.

So as an example an end user who would not qualify under the existing policy would be somebody who has a 50 location IP VPN, maybe a retail chain that has 50 or more stores, something like that. Those stores have 10 on average staff per location, 500 people total. They have on average 20 devices in each location including all of the point of sale terminals and everything. They have two subnets on location, a voice subnet, a data subnet.

They’re not multi homed because really they rely on one network to get all of their sites connected anyway. So trying to multi home everyone wouldn’t make any sense. And they’re currently using RFC 1918 space because that’s the generally accepted best practices way to do this. And they’re using NAT and v4.

So the other options that such an organization would have under the existing policy would be to get multi homed. If they’re running IP VPN they don’t really need multi homing for their transit if they don’t have multi homing for their transport. So whatever. It’s just wasteful. And the other option would be that they get an IPv4 direct assignment. They probably would qualify for one based on those hosts and location counts.

But that would basically require them to stop using NAT and use something less efficient, which is public space, and do a bunch of unnecessary work to get IPv4 addresses from ARIN before they would be able to use those to qualify for an IPv6 assignment. So that is also considered wasteful. This policy would fix that corner case.

So the discussion question for all of you is: Do you support making organizations like this have an easier time of getting IPv6? And do you think that the thresholds and constraints in this policy are appropriate or too loose, too strict? Are there any other use cases you can think of that this proposal doesn’t cover that need to be covered as part of this before we get to recommended draft state?

Do you have any other questions, concerns, suggestions? Open the floor. Lee.

Lee Howard: Lee Howard. At the IETF we recognized that renumbering was hard and there was a working group called 6renum. And we published three RFCs. 6789 talks about how to structure your enterprise networking addressing to make it easier to renumber so this isn’t quite as painful as it might otherwise have been.

I recommend everyone to see it, RFC 6789. I thought it was pretty well written. Having said that, I can still deny the antecedent and think this is a good idea. So I support this. I think we should do this.
I don’t have responses on the other three lower questions.

Alain Durand: Do you have an estimate of how many organizations will come and enter this proposed policy?

Scott Leibrand: No. We think it’s a small number because nobody’s been beating down the doors to date as far as not being able to get addresses. But there’s also the concern that – one of the things I didn’t go into much is that while there is a possibility of many of these organizations getting addresses, they have to do it under the clause that says providing a reasonable technical justification indicating why IPv6 addresses from an LIR or ISP are unsuitable.

That is a way that some of these companies can get addresses now, but it relies on ARIN staff making a judgment call, which I know John gets up every time we discuss this, they don’t like to make judgment calls when they can avoid it.

And in the longer form rationale there’s also some discussion of the fact that these organizations would like to have some certainty in policy that they can go get addresses and know that they qualify as opposed to not knowing whether they go to ARIN and qualify or not.

It’s probably true that some of the organizations that are currently qualifying under F would better qualify under E and so we would add that and it would have an effect in those cases but only in the sense of making life more certain for them in the application process.

I would suspect that we’re probably in the single digits per year number of organizations who would be completely unable to get addresses without E. Remember also that the number of organizations that to date have needed this is smaller than the number of organizations that will need it in the future because we’re moving to a world where v6 matters more than v4 and where you can’t just go ahead and get the v4 to qualify for the v6 for free.

So there’s very much a desire to sever the IPv6 policy from any dependency on IPv4, and the reason that we’re having to do this is because we didn’t say if you qualify for an IPv4 block then you also qualify for a v6 block. We said if you have an IPv4 block you qualify for a v6 block.

So that in the future is going to matter a lot more than it does today. So I think it’s a small impact. It’s probably not going to be much impact on the DFZ, but it’s going to become more important over time.

Alain Durand: That actually is my worry, is either as a potential impact on the v4 free zone, if a large number of companies try to get space and if this policy – instead of putting NAT66, for example, like they do in IPv4, might be suggestion to put some kind of a timestamp on that policy and see how things change over the next few years.

Scott Leibrand: That’s one option. The other thing that staff has done in the past is recognize that if there is a policy that is creating a serious, urgent problem that it can be suspended and give the community time to consider how to address it.

So I suspect that if it does ramp up to be a significant number over time, it will not do so so suddenly that we won’t have enough time to deal with it through one of the existing mechanisms.

But I take your point that that is one potential concern. I don’t put a lot of weight on it but others might value it higher.

Alain Durand: In the current rate of adoption and enterprise, I agree that’s not really an issue.

Scott Leibrand: Thank you.

Owen DeLong: Can you go back to the questions? Owen DeLong, Akamai, ARIN AC.

To answer your questions, yes, I support the policy as written. The constraints in this draft seem fine to me. I don’t think the third one matters because if there are, then we can come up with another Draft Policy to address them. And I don’t have any other questions, concerns or suggestions.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC. One of the things about this policy is No. 3, to me, actually really is an issue. We have a very, very specific use case that is being added. 13 sites plus contiguous is a very specific use case for a very specific kind of enterprise deployment, that a very specific kind of Internet provider is going to provide to a company.

One of the things we’ve talked about over the years is are we making policy for a very, very small segment and not a group or a larger group? And so what I would ask is we have from the scene that in the ISP side, it’s easier to get space, v6 space, which is actually contradictory to how it happens in v4.

If you are a existing v4 holder, there is no discussion. You just get the v6 space. But if you’re a new entrant, then the current policy is significantly harder to get.

We’ve made v4 a lot easier to get, but we’re actually still on very old thinking when it comes to v6. So my question for the community in this room is: Can we lower the bar on that, on E, to encompass more use cases? Because right now I believe it’s a very small group of people that it’s going to help.

Scott Leibrand: Kevin, can you comment on whether you support or oppose the policy as written?

Kevin Blumberg: I support the policy. I would like to see it expanded to allow for more use cases.

Scott Leibrand: And do you think those use cases are sufficiently close to the current problem statement? They should be rolled into this as opposed to have their own separate policy proposal?

Kevin Blumberg: Yes, it’s purely a numbers game. The No. 13 –

Scott Leibrand: So you’re actually talking about the threshold itself.

Kevin Blumberg: It’s purely a thresholding issue right now as far as I’m concerned.

Scott Leibrand: Okay, thank you. Owen?

Owen DeLong: So I don’t see 13 as being so much a specific use case as being placing the threshold basically at the point where you go from /44 to /40 on the prefix size.

Because with our 25 percent minimum free round up nibble boundary stuff that we put in the policy, the distinction actually occurs at that point. And I think that’s why that was chosen.

If you want to make it ultra easy for people that could qualify for a /44, that’s basically anybody that’s got more than one site, I believe, I don’t know if that’s getting too into the minutiae assignment category where they really should be getting it from their upstream.

As everybody knows, I’m pretty much a PI for everyone in almost every circumstance kind of guy. But if you’ve got – if you are multi homed, you can get anything down to a /48, and I’m not sure we want to move, if you’re not multi homed boundary, for getting PI in v6 much below a /40. I don’t see that as being necessarily beneficial to the community.

Scott Leibrand: Does anyone have suggestions on how this proposal could be improved or any other comments on it? If not, I think we are getting close to closing the mics.

I’m going to ask John if he can do a poll on whether you believe that this is something that the ARIN Advisory Council should continue working on. I’ll turn it over to John.

John Curran: Thank you, Scott. Okay. The AC are great people. We want them working on policy that only you folks think they should be working on.

The way we do that is we ask the question, should the AC continue to work on this? And an answer of yes means they’ll continue to work on it, likely. And an answer of no means they’ll consider stopping work on it.

So we’re going to ask one question. The question is whether or not you believe the AC should continue work on this policy proposal. Okay. Tabulation engine is in place. You remote users, get ready. You type slow. I mean, I’m sorry, we love you, but please get ready.

Okay. On the matter of Draft Policy ARIN 2015-1: Modification to Criteria for IPv6 Initial End User Assignments, should the ARIN Advisory Council continue work on this policy? Raise your hand if yes. Nice and high. Elbows straight, fingers pointing at the ceiling. Don’t throw back your hair, rub your beard, adjust your glasses. Okay, thank you. Waiting for the remote participants to get their job.

On the matter of Draft Policy ARIN 2015-1: Modification to Criteria for IPv6 Initial End User Assignments, all those opposed to the AC continuing work on it, raise your hand now. Nice and high. Keep your hand up, remote participants, do your entry. Okay. I think we’ve got it. Hands down. Thank you Marty.

Martin Hannigan: Recount.

(Laughter.)

John Curran: One vote, a lot of soul. We’re now doing the remote tabulation. And we’ll bring the results up. We’re actually after this not going to go to break. Nice try. We skipped Leslie doing the Internet Number Status Report. So
Leslie will be up immediately once this is done.
Okay. On the matter of 2015-1, number of people in the room, 103; remote, nine; for 112 total. Should the AC continue work? In favor 28; against, one. This will be provided to the AC for their consideration.

Okay. I’m now going to ask Leslie to come on up and give the Internet Number Status Report.

Internet Number Resource Status Report

Leslie Nobile: Hi, everyone. Okay. This will be quick. I’m going to give you an update on the Internet Number Resource Status Report which is basically the joint stats of the five RIRs in a side by side format. We update it four times a year. This was just done as of March 31st, 2015.

So the first slide. This shows the status of the entire /8 range, the 256 /8s in the IPv4 space. We’ll look right in the red there, IANA reserved 0, we all know that. That’s been taken out of the pie actually.

So above that, we have the space that’s not available. There’s 35 /8s that are in use by the technical community, and we have detailed there broken out how they’re in use, what they’re being used for.

When you move left, you’ll see 91 /8s in the Central Registry pool. This is the space that was issued prior to the establishment of the five RIRs. We call it legacy space. And that was sort of the SRI NIC, the DoDNIC, the InterNIC, and even Jon Postel prior to that. So these were issued mostly within the US and Canadian region with the early growth of the Internet.

You’ll see in blue the five RIRs received 130 /8s in total. And then the breakout is in that small pie below there – ARIN has 36; AFRINIC, five; LACNIC, nine; and RIPE NCC, 35. And, oh, the big one, APNIC, 45. I’m sorry, I missed that.
So this shows the available IPv4 /8 equivalents in each of the RIRs right now. You’ll see that AFRINIC in gray has the most amount of IPv4 space remaining, with 2.74 /8s; APNIC, .75; ARIN, .28 – although it’s actually .24 now – LACNIC, .18; and the RIPE NCC, 1.1.

Most of the other RIRs have austerity policies where they have last /8 policies or last /11 policies where they’re reserving space and only issuing a single allocation to each of their members. ARIN does not have that same type of policy. So we’re going right to the end.

This is just – we went back as far as 1999. That is becoming an eye chart. So we’re going to probably have to update this, but it shows the growth trends in IPv4 address space issued to our customers from 1999 through Q1 of 2015.

Most of the space was issued, like the real bumps were in 2007, 8, 9, 10 and 11, And most of it was done in the APNIC region. Since 2011, obviously, with depletion it’s dwindled down quite a bit in all of the five RIRs.

This shows the total amount of space issued to our customers, with RIPE at around 35 /8s; ARIN, 32; LACNIC, a little over 10; AFRINIC, a little over four; and APNIC, almost 45 /8s in total.

This is ASN assignments, and that’s pretty steady in all of the regions. It doesn’t fluctuate a whole lot. RIPE is issuing more ASNs than any of the other RIRs are. It used to be ARIN, but it switched quite a few years back and RIPE is issuing quite a few ASNs. And there’s the totals right there since 1999.

And then we broke it out. Those were total ASNs issued in the previous slides. We broke out the four byte ASNs so you could see what’s going on in this arena.

So, again, RIPE is issuing most of the 4-byte ASNs. The thing about the 4-byte ASNs is all of the RIRs at this point are issuing 4-byte ASNs by default, with the exception of ARIN. We’re not issuing 4-byte ASNs by default.

What we do is we ask on the first response whether an organization is willing to accept a 4-byte ASN, and we explain the situation with 2-byte ASNs running out. And we’re seeing about a third of our customers are taking 4-byte ASNs.

So that’s what we’re issuing at this point. Of all our totals each month that we issue, one third of them are 4-byte ASNs. And we don’t get very many returned. It used to be that when people accepted 4-byte, we were getting a lot of them back, but that doesn’t really happen anymore. So that’s a good thing.

That just shows the totals issued by each of the five RIRs to date.

Moving to IPv6 address space. In the gray, /0 was the total IPv6 address space. A /3 has been carved out for global unicast. IANA runs that global unicast space. There’s 512 /12s in total in that /3. To date, five /12s have been issued, one to each of the RIRs under a global policy which happened in October of 2006.

And there’s a sixth /12 that IANA controls and they use it for miscellaneous bits and pieces. You can see it on their website. I’m not quite sure what they all are. But they’re using some of it.

This shows IPv6 allocations from the RIRs to customers. And, again, you can really see the growth in IPv6 in the RIPE region and in the LACNIC region. That’s where it’s mostly happening at this point that you can see.

And this confirms it. This is the total number of allocations made to each, by each of the RIRs with RIPE having the high of a little over 9,000.

And this is IPv6 assignments from the RIRs to the end users. And again RIPE is issuing most of the IPv6 assignments as well, followed by ARIN. And here are the total number of assignments that each of the five RIRs has made in the past however many years that is, 13 or something. Yeah.

And this is – I showed this slide yesterday in this tutorial just for ARIN, but this is the percentage of members in each of the RIRs who have both IPv4 and IPv6 address space.

And you can see AFRINIC is on the left with a little over 36 percent of their members have received their IPv6 from AFRINIC. APNIC and ARIN are neck and neck there. We both have 47 percent of our ISP members are members who have IPv6 directly from us.

And LACNIC and the RIPE NCC have about 75 percent of their entire membership have received their IPv6 allocations. So that’s a really high number.

This is just a link to the RIR stats. You can find them on our website on the NRO website, on the IANA page. So there’s various places you can access RIR statistics.

And that’s all I’ve got.

John Curran: Any questions for Leslie?

Vint Cerf: Leslie, it’s Vint. I know that we don’t normally track anything about usage other than assignments, I guess, but do we know anything about actual traffic that’s going over v6 that would be made available to us just to – sort of as a side piece of information?

John Curran: I was going to say, we actually don’t get to see a lot of traffic data when people ask me for traffic data on v6.

Vint Cerf: You send them to Geoff.

John Curran: No, for traffic data there’s a company called Google.

(Laughter.)

And I send them to the IPv6 stats page. Also, our friends at the Internet Society are doing an excellent job tracking per ISP deployment rates for network enablement. But we don’t get to see the traffic stats at all.

Vint Cerf: Yes, you do, because you can Google them.

John Curran: That’s right.

(Laughter.)

Lee Howard: Lee Howard. Leslie, you mentioned that we are – that 2-byte ASNs are running out and that’s still our
default allocation. How close are we to running out?

Leslie Nobile: I’m glad you asked that question because I was going to remember to tell you all this. We’re really, really close. We have less than 50 2-byte ASNs in our inventory, maybe less than 30. So we’re very close. And we’re going to have to start doing – issuing 4-bytes by default, I’m assuming, in the near future. I don’t think we have a choice.

Lee Howard: So the headline is ARIN is running out of numbers. Wow.

(Laughter.)

Andrew Dul: Andrew, on your third slide, I think it was, there’s the slide that shows the remaining pools in all the regions. And I’d note in the ARIN region we’re not including the /10 we’ve reserved for transition technologies, but the other regions are including their other pools for that kind of thing. So does that slide perhaps need to be adjusted at some point in the future so we include that data in our pool?

Leslie Nobile: I’m glad you asked that, too, because that’s another thing I forget to say. Actually that slide says available addresses, which means what we’re issuing from what we have in our available pools.

You are correct, that does not include what we have reserved or held aside for policy or put aside in quarantine that has to clear filters, so none of that is included in that slide.

So it’s not really an accurate depiction of the total amount of space that each of the five RIRs has, but, as I said yesterday, you can check the extended FTP stats and you can get a really good picture of the reality.

Andrew Dul: It would seem that ours is slightly more skewed, perhaps, than other regions, is that a correct assessment? Because there’s a /10 that’s not included in ours.

Leslie Nobile: LACNIC, for example, has not issued – they’ve put aside their /11, /12, and /13 that they received from IANA for reserves, and that’s not depicted in that slide either. So it really just depends on the RIR.

Andrew Dul: So we’re all comparing apples, oranges and pineapples here.

Leslie Nobile: Pretty much, yeah.

Mike Joseph: Mike Joseph, Google. You did show available v4, but it’s interesting that you don’t yet track available v6. You track number of allocations and assignments, but not weighted by size. So can you comment on actual depletion of these /12s?

Leslie Nobile: Depletion of the IPv6 pools that we have, is that what you’re saying?

Mike Joseph: Yeah.

Leslie Nobile: I don’t have that. And I think we have an RS coordination group meeting this week, and I think that’s a good thing that we can add, because I think it’s a good slide to have. None of the five RIRs have gone back to IANA for an additional /12. We’ve been working with the original /12 since 2006, I think I said. That’s a long time, so it’s probably a good time to track what we each have left. Thank you.

(Applause.)

John Curran: Thank you, Leslie. We’re ahead of schedule and almost at break. I’m not going to pull Nate up because he’s after the break, giving the Software Development Update. But I also don’t want to let you go early because you don’t need a longer break.

ARIN Employee Gift Policy

John Curran: I’m going to do one more presentation and then let you go. It’s a two slide presentation. So if you could bring it up. ARIN gift policy. Actually, it says Erin. I’ll do it because I’m up here, Erin, so don’t worry about it.

So some of you folks really like your ARIN service, and occasionally send us stuff.

And so I have to actually get up here and tell you we do appreciate it, but…

We actually have a gift policy since 2004. We need to have very high integrity. We cannot accept gifts. If you send gifts, unfortunately we’re going to return them. It’s just the way it is. We had someone recently offer to buy the staff pizza, have a pizza party.

We have people who are very generous and very appreciative. But we actually – just for sake of fairness to all of you, just send us an email. Just say thanks, that’s really good. We know how to recognize employees internally.

But keep your gifts, and we do appreciate the thoughts. And if you have any questions about this policy or if you ever want to recognize an employee, just drop us a note. We’ll recognize them internally and you can keep your gift certificates, pocket change, vacation, gold bullion, all that other stuff. Okay?

Questions? Thank you. Now we’re going to go to break.

Vint Cerf: Wait a minute. There’s a question over there.

Ron da Silva: I have one. Ron da Silva. Does this mean we can’t buy any ARIN staff drinks?

(Laughter.)

John Curran: So the policy – that’s a valid question. So there is a lower threshold. If you’re getting someone a drink or a cup of coffee, we’re not very restrictive on that. Feel free to buy a drink for an ARIN person or buy them a cup of coffee.

It’s not going to affect their decision making, I promise you.

(Laughter.)

It’s the – I do have cases where people hand me honorarium checks for money for speaking, and I’m like, no, it’s my job to come speak about v6 and I don’t need the check with all the zeros on it. We give those back.

It’s just anything over $25 we have no choice but to return. So that’s – if you need the lower threshold, that’s the magic number. Okay?

Thank you very much. I’m now going to send us to break. We’re going to be at break until 3:30. And at that point we’re going to come back and hear Nate talk about the Software Development Update, and then I’ll do the closing announcements.

So everyone free to go, and we’ll see you at 3:30.

(Break.)

John Curran: Welcome back, everyone. It’s Monday. We’re in San Francisco at the ARIN 35 meeting. We have just a few quick things and we’re done. So we made great progress on the policies today. The AC will have lots to do.

I now want to have a Software Development Update with Nate Davis, our Chief Operating Officer. Come on up, Nate.

(Applause.)

Software Development Update

Nate Davis: I thank you very, very much. All right. So I’m going to give a Software Development Update. For background, this has been – I’ve actually been giving this presentation for a number of meetings now.

And the purpose of this is to provide more visibility to some of the activities that are occurring within the engineering department.

Engineering department obviously is a significant cost to the organization and thereby the membership. So as part of being transparent and accountable, this presentation takes place at every meeting.

So I just want to give you some background as I go into this.

All right. So what I’ll be talking about, the projects that have been completed since the last ARIN meeting. Some of the initiatives that we plan to deploy following this meeting.

Some of the influences that we have in our prioritization process. It’s not as clear as one would think, because we have a number of factors that influence how things get done within the ARIN organization. And then, lastly, some of the Board guidance that the Board has provided us regarding project prioritization.

Starting first, one of the things we worked on was the IPv4 pre-approvals via ARIN Online. So we now have the capability to actually handle pre-approvals electronically within ARIN Online, not necessarily doing that as a manual process, say, through STLS as we’ve done previously.

In addition to that, one of the things we’ve completed since the last ARIN meeting in Baltimore is we also completed some changes in emails associated with invoicing and reminders. Let me take a moment to dive into this.

We had some emails going out from, for lack of a better term, email addresses that had the word “revocation” in them or “collections” and so forth. And we’ve changed that.

It wasn’t necessarily sending the right message from the organization, particularly when the invoices were sent out and they weren’t past due.

We got feedback from the community member that that actually should probably change, and they are right.

When we looked at that again, we made those changes on behalf of that recommendation from the community. So that’s been done.

Also on the point of contact validation, the POC validation that was discussed earlier, some of the emails there we’ve improved for clarity as well.

The options for validating your POC email are much clearer in the outbound message that we have going to the recipients, in addition to simplifying some of the processes on how they respond back, whether that information is correct or not correct and how to correct incorrect information.

Lastly, all of those emails now are PGP signed whereas before they were not.

And then, lastly, we’ve improved some membership support in ARIN Online. Specifically, on each of the ORG pages within ARIN Online, we now have a link to what is now the Designated Member Representative information. That will soon be changing to voting contact, and you’ll hear more about that later in the week.

But we’ve improved the information that’s available online to organizations regarding their Designated Member Representative. And if they’re not a member, it directs them to instructions and a form on how to become a member.

So those are the things that we have completed since the last meeting in Baltimore. Now, these are the items that we’re actually planning to complete very soon. I’ll have to be somewhat forthright in that some of these initiatives, the transfer functionality as well as the Whois query responses, the links to those.

And, lastly, the records regarding the /8s, all of that we had hoped to actually deploy before we got to this meeting.
What we found out is the transfer functionality is a little more complicated than we expected. So it took us a little more time to provide effective business rules for engineering to actually complete the transfer functionality.

That’s one piece. We also had a little bit of scope increase, in that the pre-approvals were part of some of the functionality that we implemented. And that was something that we didn’t state we’d be completing within this timeframe when I last spoke to all of you in Baltimore.

So all of that we had pushed and hoped that it would be completed by now. It has not been implemented yet but it will be implemented immediately after this meeting.

Additionally, some of the other things that we plan to do are two factor authentication. Mark Kosters is going to talk about this a little later in the week.

On the two factor authentication, we’ve selected Google as their authenticator as a solution. It supports TOTP tokens, and the solution is also compliant with RFC 6238, if I recall.

SWIP Easy, we’re still looking at that as an on deck project that we’re going to begin very soon. SWIP Easy is actually in that area of being able to manage reassignments, which is – it’s not a handful, so it’s not easy within ARIN Online. It’s a little bit more than that.

But may not be as many as what you would script for and use the RESTful services. So this solution is sort of to address that medium area where there’s still a lot to do but making it easier through our Web interface that we have.

And, lastly, there’s some enhancements that have been requested within the community that have to do with the new ASNs that ARIN issues on a daily basis and make sure that those are included in the daily issued report.

As with the prior slide, and let me go back to that just briefly, you’ll see asterisks are noted on some of these completed projects for which we’ve done previously and are planning to do. And all those are community suggested projects.

Those are coming from you. It’s important that ARIN is responsive to the community for their suggestions on how we can improve our systems to meet your needs.

So what are some of the things that influences what ARIN works on? There’s several of them. We obviously have to meet local and federal legal and regulatory compliance items.

We also get policies ratified from time to time that need engineering support.

Some of the things, as you’ve seen that we’ve talked about today, a lot of those have actually come out of the ARIN Consultation and Suggestion Process. We also have Board of Trustees initiatives that come down, operating plan objectives, so on and so forth. Ad hoc requests from the community and so forth. So we have a lot of factors that go into what influences exactly what we work on.

In addition to this, we have the general Board guidance from the strategic plan, which is really to focus on enhancements to ARIN Online to improve the user interface, but also to continue to support the Policy Development Process, and lastly to focus on those smaller issues that yield the greatest benefit to the broadest community within the context of some of the things that we’re working on.

So what that means is focus on the low hanging fruit that doesn’t cost much that provides the biggest benefit to all the members of the community.

And that’s really what we strive to do. So that’s really my report on the software engineering and some of the things that we’re doing. I’ll take any questions.

John Curran: Microphones are open.

Kevin Blumberg: I might as well kick it off. Kevin Blumberg, The Wire, ARIN AC. The first question is a bug versus a feature.

So we use ASCP for feature requests. But at the same time as a community we sometimes find things that are a little off, I suggested there was a problem with the website a couple months ago. But if I just emailed info@ARIN to say “hey” or use the feedback form to say “hey, there’s a problem,” the community doesn’t get into the loop in that situation.

And in some cases the person who submitted the feedback doesn’t necessarily get into the loop longer term. Should we only be using ACSP to talk about these than types of things, or should they be sort of half and half – you sort of arbitrarily pick?

John Curran: So in general, if you have a bug, I’d like to have you use the feedback form, because we know exactly where you are, whether you’re on the website or ARIN Online. It’s consistent and it’s always in the right place.
We get all the information. And fixing a bug is us catching up with something we already told you we delivered. It actually has a little bit of a priority.

So if you’ve got a bug, we’re going to prioritize that first. We don’t have – there may be a bug that’s not consequential, but most of them we want to fix because even if it’s not something that you care much about, there may be someone else who is going to use it tomorrow, and they expected it to work the way we told them it would.

So that’s not part of the pool of free resources. That’s us catching up with what we already told you we were going to do. That’s why we don’t want that in the ASCP process.

Kevin Blumberg: Right. But there isn’t currently an open bug report list of things that you’re working on as far as bugs are concerned.

John Curran: Right, there’s not one that you see, that’s correct, Kevin.

Kevin Blumberg: So people could be submitting the same feedback for months on the same problem.

John Curran: There’s one that we see.

Nate Davis: Actually that’s helpful, Kevin. If we do receive multiple feedback on the same bug issue, per se, the reason why is sometimes we’ll get the report of a bug. And when we’re having product meetings, once a week we’ll say, well, what’s the volume of this? Are we hearing it from customers? And sometimes we don’t hear it from customers.

If we get it through feedback forms or they continue to submit it, then we have some sense it’s not just affecting one person. That’s useful for us in determining priority for it.

John Curran: In terms of additional prioritization, if you have a bug that’s shutting you down, then my email is jcurran@arin.net, and you should send me a note and say this is why this has to happen now.

We do prioritize bug reports. But obviously if someone’s having something that’s business impacting, then we’ll scramble faster. But that’s something you need to take up with us, because there’s things in the queue that need to be prioritized.

Nate Davis: Center back mic.

Heather Schiller: Heather Schiller, Google Fiber. I just wanted to thank you for making good progress on stuff that was in the ASCP and for the work that you’ve been doing on prioritizing some of the developmental requests that have been asked by the community. Thank you.

Nate Davis: Thank you very much, Heather. So something you’ll hear –

John Curran: I passed out, I’m sorry.

Nate Davis: So something you’ll hear about from both Paul Andersen and the Treasurer’s report and also Mark Kosters, engineering, is we’ve actually had some additional funding to do an engineering search for the next few years, if you will. We actually have a dedicated team to ACSPs that’s going to start on April 17th.

Again, we’ve heard what the community has said. The Board has listened and helped us get additional funding to help knock out some of these ACSPs, and hopefully you’ll continue to see the benefits of that over the next few years.

All right. Thank you.

(Applause.)

Closing Announcements

John Curran: Okay, closing announcements. We’ve had a very productive day and we’re done early. That’s amazing. Those usually don’t happen at the same time.

I’d like to thank our sponsors. Network connectivity provided by Webpass. You don’t have to clap for the network connectivity sponsors. You don’t. We actually can identify you and turn off a MAC address. So let’s try it again.
For our Webpass sponsor. Come on, everyone.

(Applause.)

Yeah, there you go, much better. Okay.

And also thank our webcast by Google. Thank you.

(Applause.)

Okay. Our refreshment break – Fastmetrics, ServerHub, and the IPv4 Market Group.

Social, in just a few hours, we’re going to go to Jillian’s. 7:00 tonight is the social. You have pool games, networking, a full buffet, an open bar and a D.J. You have – bring your badge. We check for the badges to make sure we get the right people in there.

In terms of arrangements, where are the buses, Susan?

John Curran: No buses. You walk. So there’s a little piece of paper there. And if you’ll all find Susan, she’ll tell you how to get there.

Susan Hamlin: Registration desk.

John Curran: Registration desk has many little pieces of paper or type it into your phone and I’m sure it will get you to Jillian’s. Walking distance away.

Okay. Reminders. Tomorrow breakfast at 8:00, meeting starts at 9:00. You can in between your games of pool tonight review the meeting materials so you’re ready for tomorrow.

That’s it. Thank you, everyone. See you at the social tonight or first thing tomorrow.

Network Sponsor

Webcast Sponsor