ARIN XXX Public Policy Meeting Day 2 Draft Transcript- 25 October 2012 [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 and Announcements

John Curran: Good morning, everyone. It’s October 25th, Day two of the ARIN Public Policy Meeting.

I’d like to take an opportunity to thank our sponsor terremark for the network connectivity. Come on everyone, clap for terremark. If you don’t thank them, turn off your interface and see how it goes. They’re very important here.

I’d like to remind everyone that the chair will moderate the discussions of the Draft Policy so all can speak and all can be heard. Clearly state your name and affiliation each time you’re recognized at the microphone.

As requested yesterday, if you have a view on a policy proposal, it would be helpful if you speak whether or not – state whether or not you’re in favor or opposed at the beginning of your remarks.

There are rules and courtesies in the Discussion Guide.

Today’s agenda. We have in the morning the ARIN Consultation and Suggestion Report, and we have the IANA Activities Report. We also have some policy discussions. We have Draft Policy 2012-5: Removal of Renumbering Requirement for Small Multihomers, and Draft Policy 2012-2: IPv6 Subsequent Allocations Utilization Requirement.

We have a couple of topics that we’ll be discussing at lunch, at the AC lunch table topics. So when you go to lunch, you’ll see little cards up there. There will be a table where they’re talking about ARIN Proposition 180, ISP Private Reassignment. We’ll be talking about Proposition 182, Update Residential Definition to Not Exclude Wireless As Residential Service. We’ll have a discussion on the AC effort to improve communications. And we’ll have some tables talking about observations on the transfer policy and the market.

At the head table today we have our chairman, Timothy Denton; Chris Grundemann; Scott Leibrand; we have Bill Woodcock; Owen DeLong; and Vint looks very thin, but he’s down there at the end somewhere.

So I’d like to start this off by having Nate Davis come up and give the ARIN Consultation and Suggestion Process Report.

ARIN Consultation And Suggestion Process (ACSP) Report

Nate Davis: Thanks, John. So I’m going to talk this morning about the ARIN Consultation and Suggestion Process Report. For everybody’s knowledge, just to make sure we’re all together here on what the consultation process is, the consultation process is a way by which the community can provide ARIN input on non-policy-related matters. And sometimes those suggestions are taken and we consult with a community, get some sense of priority and so forth regarding the actual suggestions.

When we have a sense of priority or importance to the community, we’ll try to work those into our project schedules in a manner that’s best for ARIN, best for the Board, best for the community as well.

So this is a short report this morning. We haven’t received too many of recent, so…

All right. So the one that’s open and has been for a while is the DNSSEC enhancements. And specifically there’s been a request to enhance ARIN Online to accept TTLs when editing DS records within the ARIN Online functionality itself and also the ability to submit bulk DS records including TTLs.

There was a further request that when these bulk DS records are submitted, that ARIN take those and parse those and load them into the ARIN database.

So we’re currently underway with a cost estimate on this. But we did want to note that there’s some extensive rework to the database structure as well as to zone generation and also Whois and our RESTful interface changes as well. So there’s a fair amount of work there, but we still don’t have an estimate exactly what that will cost.

So that one’s currently open. There is a consultation on it. We encourage the community to go out and provide their feedback on the importance of this particular consultation.

Now, we had a few that came in just a few days ago and the purpose of me reviewing these is just to give some visibility to the community that likewise, whether the suggestions come in and we provide a consultation or they’re just suggestions, either way you can see those on ARIN’s website and provide your input regardless.

The first one is for changes to documentation requirements for ASN requests. ARIN should accept any valid evidence of the unique routing policy and/or multi-homed connectivity as proof of the need for an autonomous system number per policy. It’s ridiculous for ARIN to insist on copies of signed agreements as the only form of acceptance evidence.

So this is one that we received recently, and any input the community feels they want to provide on that, please go to the ARIN website. Similarly, we received another suggestion, improve the request submission options.

ARIN should not phase out the [email protected] channel for additional communications about the requests, ideally restoring this as a channel for request submission should be restored.

To provide context, ARIN still provides support for hostmaster. However, most of the avenues for requests are actually coming through ARIN Online or through the RESTful services.

Hostmaster is not integrated with ARIN Online. So this request is really to facilitate the email process through ARIN Online and not necessarily completely phase out hostmaster or have some interconnectivity there.

ARIN needs to provide much better tools for consultants who use, to work with their customers on ARIN resource requests. The need for better tools is a direct result of the conversion to ARIN Online.

So once we went to ARIN Online, hostmaster became less of an avenue to manage requests. And so that’s the essence of this suggestion.

Make the company name optional on the billing form. And the billing form for ARIN Online, company name should be an optional field for the person paying the bill. Currently is mandatory and requires three to 150 characters. It’s nonsensical in the case where an individual may be paying an ARIN invoice.

So, anyways, when we recently implemented some of our new payment functionality, this has come up as an issue recently, and we look for any input that the community has regarding this.

And that’s really the last one. Any questions or comments? Center mic, go right ahead.

Dani Roisman: Good morning. Dani Roisman from SoftLayer. There’s a suggestion I just put in yesterday, so it didn’t make it to your slides yet, 2012-20, which was to allow for a way to query children, so SWIP records or child assignments, and to get more than 256 results, which is the current limitation.

Nate Davis: Thank you, and I appreciate you bringing that up. Actually, we saw those come in yesterday afternoon; we just weren’t able to fit them into the slides today.

But I think there’s a couple of them that came in.

Dani Roisman: Ann and I both hit send at the same time. We were poorly coordinated. I apologize about that.

Nate Davis: All right. Well, thank you for bringing that up here. And if the community can, if you want to take a look at those suggestions as well and provide ARIN feedback, that would be great.

John Curran: I guess it’s important for people who think any of these suggestions are useful to comment to that effect online in the suggestion process. I guess it’s not necessary. If you don’t comment, I will guess. But if you comment, I will make educated guesses.

So I’m really interested in things that are suggested that you people want to see, because it helps me for end-year prioritization in a major way. Thank you.

Nate Davis: Aaron Hughes.

Aaron Hughes: Just to clarify, which list would you prefer the plus-ones on?

John Curran: There’s an ARIN Consult List, and you can comment away and say “I need these things for these reasons.”

Aaron Hughes: Let me be more specific. If we have a discussion on arin-tech-discuss and we come to conclude there’s a problem, do we need to copy that to an additional list, or will you pull that from the tech list as –

John Curran: I watch every message to arin-tech. Thank you.

Nate Davis: Any other questions? One sort of last appeal to the community, which is when ARIN posts out a consultation, some of them are of the flavor you’ve seen today. But also we post a consultation, new LRSAs, RSAs, and similar key documents or procedures or processes within ARIN.

We really are looking for feedback from the community. It’s the only avenue we have that – non-policy-related that we can collect significant feedback from the community.

So I encourage everybody to pay at least some close attention once a month or so to ARIN consultations and provide us the feedback in a similar manner as you do on the policy side on PPML. Thank you.

(Applause.)

John Curran: Okay. Next up we have the IANA Activities Report, and this will be given by Leo Vegoda.

IANA Activities Report

Leo Vegoda: Hello everyone. So this year we go to the RIR meetings and ICANN meetings and things like that, and every time we’ve given a report we’ve given a slightly different report.

And this time it’s a different report again. So if you are on the meeting circuit, this isn’t the same as what you heard at the ICANN meeting in Toronto, or the RIPE meeting, or anything else.

Unfortunately, or fortunately, we’ve got a lot to talk about. So we’ve been doing one subject per report. This time we’re focusing it at people who actively use IANA services.

So ccTLDs in this room, RIRs, anyone who requests a port or a PEM or multicast addresses, or one of the 1500 or so other registries that we maintain.

So sometimes we do things and we think we’ve done them right, or we know we’ve done them wrong, but, anyway, people want to make a complaint. And we have a process for that.

The very, very long document behind is the escalation process, the customer service complaint resolution process available on our website, the IANA website, click about procedures, it’s there.

And the blowup is the important stuff. It’s there for when we’ve taken too long, if we’ve implemented the policy incorrectly or if you think that we haven’t applied the appropriate neutrality, if we’ve been biased in some way.

And basically if you send in a complaint to escalation at IANA.org, it gets escalated up a chain from the manager of the particular service to Elise, the vice president of IANA, and onwards and upwards.

And at any time you can break out of that, because you might decide that you don’t like us at all, you don’t want us handling your complaint.

If you go and look at this, which is the same process but flowcharted, this is actually extracted from the proposal we put in for the IANA functions contract. It’s published on the NTIA website, and I think it’s also published on the ICANN website. You can go and grab the whole process, which includes all the processes, or almost all of the processes, that we use.

So you can go and see this. Obviously the description stuff down at the bottom goes on for longer. But in this you can go and see that there’s lots of decision boxes, and each of those decision boxes is I don’t want to follow this escalation process anymore, either because the escalation has resolved the issue or because I just don’t like this process and I want to deal with someone else.

And that someone else is ICANN’s Ombudsman who reports directly to the Board, isn’t a member of staff in the same way that I’m a member of staff or anyone else at ICANN is a member of staff, and they don’t report into our CEO and president. It’s a direct Board appointment. And it’s a requirement of the IANA’s function contract. We have to go and make sure that the process we already have in place is suitable. And if it’s not suitable, we have to find out what it is that we should be changing so that we can make the process right for you.

So we haven’t done that yet. It will be a public comment that we’re going to be launching very soon at the start of November. So that’s not very long away.

You can find the public comment pages on the ICANN website. You have to scroll down below the fold, if you’ve got a laptop-sized screen, and there’s a little thing, public comment, and you’ll be able to see it there.

This is the Ombudsman Web page. The Ombudsman runs – is a new Ombudsman, Chris LaHatte, who you can see a picture of there, nice chap from New Zealand.

And if you ever have any concerns, you don’t actually have to use the customer service complaint resolution process. You can go straight to him, if you want. There is no requirement to go and use the process that’s run within the IANA department. But you can go straight to him, or you can contact us.

Hopefully we don’t ever actually give you a cause to issue a complaint. But we are, all of us, human, even in the IANA department, and so occasionally mistakes do happen. We need to have a process for resolving issues.

So this is the advanced notice. We’re going to be running a public comment on this. If you or someone who uses the IANA services, particularly the RIR stuff in the room, but also people from TLDs and others, you know, go and look out on that.

We definitely want to get this right, because if there’s one thing that’s worse than making a mistake, it’s entrenching it by not resolving it properly.

So that’s it. I’m obviously happy to take questions, if people have questions, but, otherwise, you can just catch me. I’m here all week.

Bill Darte: Good morning. Bill Darte from ARIN AC. Not speaking as an AC member, just point of curiosity. I’m sure you don’t get many complaints. I’m sure your stewardship is wonderful.

But imagining that there were complaints that came from either – or were directed either to the Ombudsman or through your regular process of escalation, what kind of tracking, what kind of documentation or visibility to those kinds of inquiries is maintained or anticipated?

In other words, if somebody wanted to know what kind of complaints were received, is there any visibility into that by others at all?

Leo Vegoda: Good question. The ICANN Ombudsman publishes an annual report and also has a blog where he discusses Ombudsman-related issues. So from the ICANN Ombudsman side, there is all of that transparency.

Within the process that we have right now, we don’t actually publish anything like that. I think the main reason we haven’t been publishing statistics is that fortunately we haven’t really had much in the way of complaints to publish. So it hasn’t been a priority.

But when we run our public comment, I would be very grateful if you would put in that comment saying, hey, you should publish statistics about this and all of that, because it may be – maybe if we get zero complaints a year we should publish a report saying we’ve got zero complaints. That would be a nice thing for us to do.

And hopefully we can get zero complaints now. But I think that’s a great idea. Thank you very much.

(Applause.)

John Curran: Earlier this week we had an election. I’m not talking about the Board and the AC election; I’m talking about the NRO Number Council election.

These people serve on the Number Council, which also serves as the ASO AC.

The Number Council election has been completed, and we have the results in.

The winner of the NRO NC election is Louie Lee.

Louie, are you here?

(Applause.)

John Curran: Thank you, Louie. Very good.

I’d like to continue with this morning’s reports. We’re going to have Cathy Aronson come up and give the IPv6 IETF activities update.

IPv6 IAB/IETF Activities Report

Cathy Aronson: These are little guys from my yard. Aren’t they cute? They’re very wise. The baby was really concerned about me. Anyway, good, I’m glad I can see the screen.

So this is my little disclaimer. Like I just told John, I kind of report on whatever I think is interesting. And if you were there and you think something is more interesting, you can feel free to say that.

So we had a few highlights this time. And I’ll talk about them in more detail in a minute. But the World IPv6 Launch happened in June. And I’ll talk about that.

This, I think, is super cool. The IETF website was attacked right before IETF, and all the attack traffic was IPv6. Whew. Super cool. Don’t want to miss that.

And there’s also a really interesting new working group called IPv4 Sunsetting, and I’ll talk about that some more. It kind of sounds like the beginning of the end, but I’m not really sure it is.

So, anyway, onward. I spent a little time in Seattle on my way to IETF, and reminiscing with some old friends we came upon this, what once was a foil of IPng. And if you get a chance, take a look at it, because, as you’ll see, not a whole lot has changed except that we don’t have CATNIP or SIPP or TUBA anymore. But it’s kind of entertaining, and we were laughing quite a lot about it. So I felt I should stick it in here.

Anyway, I think the slides will be online. It’s probably hard to read. I don’t know. But, anyway, it’s pretty cool.

John Curran: This slide shows that the protocol we chose, SIPP, S-I-P-P, under “transition” says “no.”

Okay. Just checking.

Cathy Aronson: Please realize that is really the top of the overhead projector. So this was actually a plastic foil, like a transparency, that’s how old it is. But, anyway, I thought it was super cool.

So the 6man group met, and there’s a whole bunch of documents, if you’re following 6man, or maybe you should follow 6man. Some of them were a little bit controversial, like embedding IPv4 addresses and IPv6 multicast. And I believe that’s where this quote came from: I’m all for documenting bad ideas that are indeed bad ideas. So apparently he was fond of that draft.

Let’s see. What else. There’s a lot of pathology still with like if you don’t get a router announcement and you just keep trying and trying and trying, and so there’s a lot of work being done there, because I guess they didn’t expect that maybe you’d be IPv6 enabled but there wouldn’t be anything else, IPv6, on your LAN, so you’d just keep trying over and over again.

So those would be of interest if you want to follow that. I had originally a huge typo on this screen. But if you guys were here yesterday, there was a really good talk about software-defined networks and trying to figure out what they are.

And the big take-away from the Technical Plenary was the transmogrifier gun. I think they’re basically trying to figure out – there was a really good Technical Plenary, and I think there’s video of it about the vision for the changes in the network. Pretty cool.

Let’s see. Oh. This was actually not IPv6 related, but yet it is. For those of you who haven’t ever heard Van Jacobson give a talk or explain something, you should really watch the video of this if they have it online.

There’s a problem – a really recurring problem in the Internet right now with Bufferbloat. I don’t know if anybody here has followed that. But there’s a lot of pathologies in the network with the huge buffer sizes and then how TCP behaves.

And Van Jacobson and his wife Kathy Nichols have done a bunch of work called CoDel, congestion delay. And they look at the amount of time that a packet spends in a queue as opposed to measuring delay. They have this – what do they call it? – sojourn time. And they’ve come up with a solution for Bufferbloat. And it’s a really interesting presentation. And he describes the network as a fountain instead of a highway, a congested highway. And it’s really interesting work.

And there’s links to the ACM paper in there, and it’s totally worth checking it out. I’m so glad that I didn’t have anything that competed with it and I ended up in that room, because it was a wonderful presentation. And he went way over time, which was great.

And there are a couple of other competing proposals. But I always think that Van is right. I think the other ones will lose. He is Van, you know. It’s like Vint. If Vint says it, you believe it.

IPv6 Launch happened. Instead of World IPv6 Day, where people turned it on for the day, the theory in June this last year was for it to be turned on and left on.

So 2,000 websites went to IPv6. And a lot of them are still running IPv6. And I have some data from some of the folks that presented. There was a panel one of the days at lunch.

Since I had nothing to do, I went to that, too. So these are the stats for Comcast, and I know there are people here from Comcast. So if you want to add anything.

So YouTube, Netflix, iTunes was most of the traffic. They were comparing the experience between the v4 experience and the v6 experience. And they have v6 on 50 percent of their network, which is super cool.

Some little take-aways from Google. They deployed IPv6 SMTP support. They have IPv6, has gone up 150 percent over the last year. So if you had like one percent, then 150 percent more than that – anyway, I don’t know.

So one of the problems that they’re seeing is that people who want to turn off v6 start filtering quad-A records, and that’s causing some problems.

Time Warner presented. I think it’s here somewhere. It takes a lot for a big ISP to get to 1 percent traffic. And that was one of the requirements for World IPv6 Launch Day. So a lot of Internet service providers couldn’t really qualify, but they still tried.

And then there’s some stats about Akamai. Let’s see. So the IRTF met. So there’s a subset of the IETF, the Internet Research Task Force, which talks about more exciting things like Vint’s Interplanetary Internet, which has been a favorite of mine, but it’s actually become less interesting title, Delay-Tolerant Network Research Group. I like Interplanetary Internet much better.

The interesting thing about the uprisings in other parts of the world is that in Egypt there are 51 autonomous systems, and in Libya there are three. So it was a lot easier to control the Internet in Libya than it was in Egypt, which is pretty – I thought that to be really interesting. That talk was kind of cool.

So I guess the thing is try to have more diversity, but in some of those countries there’s really only a couple, maybe one teleco and it’s run by the government. So it’s a little bit more difficult.

So let’s see. So in v6 operations, the take-away from v6 operations, it’s kind of neat, they’re starting to put together a bunch of different documents that actually explain how you do stuff.

So there’s a number of them. Like if you have an enterprise, how do you deploy v6, and if you – how do you design your network.

So it would be really, really cool if we got input from the operator community on those documents. And there are some operators that participate because it’s an operations group. But still there’s not a ton of NANOGers or ARIN attendees that go to IETF, but they’re interesting documents. And they’re pretty far along.

Let’s see. So the semantic IPv6 prefix, there’s a group of folks trying to put a whole bunch of little bits of information into the v6 prefix. So instead of just selling dead beef, you can put other things in your address like where it is and they’re really big. So you can use different parts of it to say where it is.

There was a really interesting presentation about NAT64 from T-Mobile and their experiences, and there’s a couple of quotes from that day. So going to lose a lot of information.

So let’s see. So there’s some work being done in IPv4 connectivity over a v6-only network, which is pretty problematic. But they’re still trying to figure it out.

Let’s see. And in the Internet area, these are some of the things that were going on. I found the second bullet really interesting. So there was a group there from IEEE, and they had this really interesting problem they were trying to solve.

So you know those MAC addresses you have that you use when you connect your computer to the Internet? Well, apparently they’re a finite resource, and they hand them out in two different size blocks: one’s really small and one’s really big. And they’re just trying to deal with that. So they’re coming up with several different what we should call block sizes that maybe they could start handing out instead of a really big one and a really small one.

And there were a number of us in the room that were saying, well, gee, guys, maybe you should talk to the numbering community, because we kind of dealt with this a while ago.

Anyway, that was a little scary. And really funny. And they kept saying no, no, it’s a really completely different problem.

So, anyway, if you’re involved with the IEEE at all, somebody might want to kind of shake them a little, because they’re really trying to solve the ABC CIDR thing all over again. Can you believe it? I was totally shocked. So that was pretty entertaining.

And then the other thing that they’re dealing with in that group is there’s a lot of things that get MAC addresses dynamically and how do you grab them back and reassign them, because it is a finite resource.

So there’s lots of work being done in this area, the DHC area as well. And these are a number of the drafts that were presented. And it would take all day to go into all of them.

But I just wanted to kind of give an overview of what’s going on in that area. And there’s a number of – anyway, so there’s a number of drafts there. A lot of them, actually.

DNSOP, this is a really interesting thing they’re working on in DNS. There’s a lot of queries that never get answered and they just keep asking and asking and asking. So there’s this project underway to set up these AS112 servers that respond authoritatively for things so that everyone will shut up.

And they’re talking about what part of the tree the DNS hierarchy should they respond to. And there’s some folks that think it should be for just .ARPA, some for just dot. So there’s some work being done in that area to try to figure out will it cause more problems than not. But it would be really nice if we could make it so that the things that are querying for things that are never going to answer get an answer so they shut up. So that’s pretty interesting.

So the V6 RENUM group. There’s some drafts in that group for renumbering your v6 group. It would be super awesome if people like you guys started following that list and giving some input about what would be useful for renumbering, because the people working on it aren’t necessarily – I mean, they’re breaking up the problem into little bits. So I think there’s an enterprise draft and there’s maybe another draft.

But it’s a hard problem to solve, and renumbering has always been a pain. It would be neat if there was some good documentation out there, because even though v6 is huge, you’ll still have to readdress.

Anyway, let’s see. So on to my favorite working group, Homenet. So I went to the home networking group, and this was the diagram picture of the Homenet of the person who was presenting the draft. And I explained to him that if this was his mother’s network, then that was entirely his fault and that maybe people working on Homenet should actually have a Homenet that somebody would normally have, like the people in the NANOG room aren’t necessarily the people who have a network that your mother would have or your neighbor would have.

So, anyway, the group went on, and I call it the “Arbitrarily Complex Home Networks Because We’re Geeks” Working Group.

(Applause.)

Cathy Aronson: Thank you. I have to put that into an appropriate acronym, but I was just – it’s just what came off the top of my head. And my favorite quote from the working group was: Well, if I take my router to my neighbor’s house because there’s a party and they need a router, what prefix will the router get?

And does that really ever happen in real life? I’m not entirely sure. It happens at Owen’s house. Okay.

(Laughter.)

John Curran: I’m told the protocol is to bring a bottle of wine, not a router.

(Laughter.)

Cathy Aronson: I know. But apparently at the IETF one would go to their neighbor’s house with a router. And apparently it’s probably this guy. Except that I don’t know if he could actually physically carry his stuff to his neighbor’s house.

Bill Woodcock: I believe the phrase is arbitrarily complex house.

Cathy Aronson: One of the cool things they’re looking at is maybe using OSPF and some dynamic protocols in the home. But, again, I can’t even imagine that they’re really going to solve the problem. Because they’re dealing with this. And I go because I find it entertaining and they talk about IPv6. But I don’t know. I got no answers on that one.

And I think there was a presentation at NANOG about this, too. Chris presented the same kind of thing, only a lot more polite. So I stood up and said “arbitrarily complex because we’re geeks.”

So the IPv4 sunsetting working group, which I think is a really big step for the IETF to say, okay, v4’s at the end-of-life and we’re going to take this stand that there’s this working group and it only really deals with things that we need to make interoperability happen or things that we need to keep IPv4 and IPv6 working, but not necessarily enhancements to IPv4. And any new protocol has to have both v4 and v6.

I like Lee Howard’s comment: “I like sunsets. Sunsets are pretty. Sometimes I like sunsets to last longer.” Anyway, that’s pretty good.

So, anyway, that’s what the working group is starting to do. It’s a central place to discuss that sort of work instead of having it in a whole bunch of different working groups.

But it’s really the minimum that the IETF would need to keep IPv4 done and they consider IPv4 to be done.

Let’s see. And this is what I said about IPv6 support within the IETF. So all future IPv4 work is limited to solving operational problems and not enhancements or features and that sort of thing.

And then there’s also work being done on a gap analysis of what’s missing in that, what’s missing for turning off v4, which it’s a big step for the IETF.

“If you don’t have v4, you don’t have a v4 problem.” Somebody said that.

The operations and maintenance area is a big working group of just high-level things that don’t fit into individual little working groups.

I like Kireeti’s comment about virtual MIB. If you think about, it’s kind of funny. They’re talking about flow operations and maintenance and various MIBs and some things in there.

So these are where you can get the updated drafts and agendas and who is doing what. Sign up for mailing lists.

And then I have this, and if anybody has questions, you can read the comment, because it’s pretty funny.

Anyone have any questions or comments or things to add if you were there?

Aaron Hughes: Aaron Hughes. Just out of curiosity on the list of things to remove the dependency on v4, what is the discussion like around replacing the 32-bit dependencies on various RFCs? Is the intent to use v4 addresses or some other kind of 32-bit identifier or get rid of them and replace them with a v6 ID?

Cathy Aronson: I’m not entirely sure what you –

Aaron Hughes: Like OSPF and BGP requiring a 32-bit unique identifier.

Cathy Aronson: Oh. I don’t know. We should bring that up in sunsetting.

Ruediger Volk is coming up to the microphone.

Ruediger Volk: The particular example of route ID in BGP is, well, okay, we just say it’s a 32-bit entity and it has to be unique within your AS, which removes the uniqueness by using global IP addresses.

I’m not sure – I’m not sure what all the other 32-bit entities are about. But that’s one particular thing that might be interesting in this community. Well, okay, more than enough.

Cathy Aronson: But doesn’t ISIS still use CLMP addresses for their –

Ruediger Volk: Yes, but those are definitely not fixed-length 32-bit entities.

Cathy Aronson: I know. It’s just that they didn’t get rid of that, and – Owen, did you have a –

Owen DeLong: I was actually going to say what Ruediger said.

Cathy Aronson: Oh, okay. All right. I guess that’s it on that. Thanks.

John Curran: Thank you very much, Cathy.

(Applause.)

John Curran: Okay. It is now after 9:45. Wonderful. We’re in our Draft Policy block. We’re going to consider two policies this morning. The first one up is ARIN 2012-5, Removal of Renumbering Requirement for Small Multihomers. I’ll give the review of the proposal, and then we’ll bring up the AC for their remarks.

ARIN-2012-5: Removal Of Renumbering Requirement For Small Multi-homers

John Curran: So history of the proposal. Originated as ARIN Proposition 167 in April 2012. The shepherds, Cathy Aronson and Bill Darte. The current version is the text from 25 July 2012. The text and assessment are online and in the Discussion Guide.

This proposal removes NRPM Policy Section 4.3.6.3, Additional Assignments For Multihomers. Eliminating this section removes the requirement for small multihomers to renumber when they come back to ARIN for additional IPv4 address space.

Status at RIRs. No similar proposals or discussions.

Staff issues and concerns. The original intent was to conserve routing table slots. However, statistics have shown that NRPM 4.3.6.3 has rarely been used and that for most small multihomers have not come back to ARIN for additional space.

To implement this is minimal. We update the guidelines and staff training.

Legal assessment. No significant legal issue posed by this proposal.

PPML discussion. 26 posts by 12 people; five in favor and two against.

Some representative comments: “I would argue that since this policy as-is is not providing any benefit and changing policy would do no harm and provide benefit, changing policy makes sense.”

“I would argue there’s no reason to charge policy for a few ORGs when the majority aren’t even affected by the policy in a negative way. There will always be at least one.”

“I support this proposal because this existing requirement treads dangerously close to the dubious grounds of ARIN taking a position on the routing utility of the assignment at hand.”

That concludes the staff introduction of Draft Policy 2012-5. I will now ask – I’ll ask Cathy to come on back up to do the AC presentation.

Cathy Aronson: Yay, it’s me again, huh?

Okay. So I wanted to put the rationale up here for you guys. I guess John probably just did.

But when we initially came up with this proposal, I mean with this policy, the original policy, we were really concerned that there would be a land rush on small multihomers and the routing table would explode, and we all agreed to revisit it at a later date, so we’re kind of here.

But it does single out a part, as it says, a part of our community for work that other people don’t have to do.

So here’s the policy text. We can come back to that at the end.

So the pros for this policy to be passed are that it removes this unfair requirement that the small multihomers have to renumber every time they come back. Like I said, the original intent was to preserve routing table slots and hasn’t been used that much, so we’re not really exploding the routing table.

The other thing that I didn’t put on this slide, but in a post runout, when we run out of address space, so with these multihomers, so do they say they have a /24 and they need a /23 but the only way they can get it is on the transfer market, do they have to like really readdress out of the /24 and buy a /23 when all they really need is another /24?

So it really does, as we get closer to being out of address space, add another burden on them where they might have to buy a bigger block and renumber out of the one that they’re in.

And I don’t think that that seems fair either. And that’s one of the reasons why Kevin wrote this proposal. The cons to this of potentially adds routing table slots, if it’s hardly ever used, then maybe that’s because we got the desired effect. Maybe if we had this policy, if we take this away, there will be a land grab and lots of small multihomers and multiple routing table slots and they knew what they got into when they got their address block.

So that’s – I’m going to put the text back up here, but – I guess if we have discussion about that.

John Curran: We’ll now have the chair come up to moderate the discussion of this policy proposal. Microphones are open. Please remember the courtesies.

John Springer: John Springer, Inland Telephone. I support the policy, but I would like to point out that you’ve got some typos. In the printed guide you reference on several occasions 4.3.6.3 instead of 4.3.6.2.

Cathy Aronson: I think this is correct, though, in the – I got it from the NRPM online.

John Curran: I’m checking now. Hold on, please.

Tim Denton: Mr. Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the policy as written. I just want to note for the community as of on the Web page currently there are 745 /23s and 1682 /24s. These are itty-bitty fragments in ARIN’s inventory. This is a really good thing to do with them, this policy. Otherwise, what are we going to do with them? I would rather see a whole bunch of little people get these rather than giving them out to a bunch of bigger people and have them advertise the /24s as a whole bunch of /24s.

So we’ve got inventory here. I want to thank ARIN for putting the block size inventory up on the Web page. That’s very helpful. Thank you.

John Curran: I just want to point out, yes, you’re correct, on the slide it is correct. It’s 4.3.6.2, and in the staff slide it says 4.3.6.3, which is incorrect.

Jason Schiller: Jason Schiller, Google and the NRO NC. Just to follow up on the point that David made, question for ARIN staff: If an organization comes in and asks for, I don’t know, say a /16 and one is not available, ARIN will not give out a bunch of /24s because they happen to be in inventory; is that correct?

John Curran: I believe so. Leslie, do you want to comment? That’s correct, yes.

Tim Denton: Bill Darte, are you just standing there looking masculine, or do you want to come to the microphone?

(Laughter.)

Bill Darte: Just masculinity.

Tim Denton: Someone? Owen.

Owen DeLong: I support this policy.

Owen DeLong, Hurricane Electric, ARIN AC. I support this policy.

Tim Denton: Thank you.

Do we have any remote participants? Wow. Okay. So it’s time now to take the vote. All those in favor of the proposition as written and displayed on the screen, would they please raise their hands.

We have been signaled that the ayes have been counted.

Those who do not favor the adoption of the policy as written. That’s an easy count. Any remote participants?

I was admonished yesterday that we always have to do the formal count even if it’s obvious what the vote is.

Bill Darte: Bill Darte on the ARIN AC, and the count is very useful to the AC and we thank you for it.

Tim Denton: Room count is 128. 2012-5: Removal of Renumbering Requirements for Small Multihomers, in favor, 48; against, zero.

Proposition is moved to the Advisory Council for their recommendation.

(Applause.)

Very good. Moving right along. The second item we have to be considered this morning in the Draft Policy Block is ARIN 2012-2: IPv6 Subsequent Allocations Utilization Requirement.

ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement

John Curran: This policy proposal was submitted in November 2011 as ARIN Proposal 159. The AC shepherds are Heather Schiller and Cathy Aronson. It was presented at ARIN XXIX and deemed needed more work. It was revised. The current version is the 26 September 2012 version. And it is available online and in your Discussion Guide.

The intent of this proposal is to allow an additional way for ISPs that have already begun using their IPv6 space but who may not have sufficiently planned for longer-term growth to receive an additional allocation.

Status at other RIRs. No similar proposals or discussions.

Staff assessment. The challenge is that this is set up to allow ISPs who have allocated at least 90 percent of their space to serving sites to qualify for an additional allocation as long as the block size for each serving site is justified.

However, the policy text has allocated more than 90 percent of their serving site blocks to serving sites and has sufficient actual utilization at their serving sites to continue to justify the blocks as specified in Section 6.5.2 to be a little unclear and confusing. The staff would like tighter or more simple text here.

Staff suggests that the text be modified to: Has not allocated more than 90 percent of their total address space to serving sites with the block size allocated to each serving site being justified based on the criteria specified in Section 6.5.2. This would allow the block size to be based on the same criteria used to determine the block size for initial allocation.

Resource impact. Minimal. Simply updating the staff guidelines and training.

This policy does not create any significant legal issues.

PPML discussion. 12 posts by seven people; one in favor and zero against.

“ARIN 2012-2 does a good job aligning subsequent IPv6 allocations with new more liberal allocation policy.”

“I am unclear what ‘sufficient actual utilization’ means in this context.”

That concludes the staff introduction. I’ll now have Heather Schiller come up and present the review of the AC policy.

Heather Schiller: The policy that nobody knows they need yet. So it kind of ends up coming down to this sort of wordsmithing action.

The stuff highlighted in red is the parts that are new. Taking away the requirement that aggregation be actually implemented as long as you have a hierarchical addressing plan, and then adding the option for getting additional v6 space later on in your addressing plan possibly after you’ve already kind of corrected for moving from a /35 to a /32 or a /32 to a – where is Owen? – a /24 under some of the other existing policies, and so coming back in after your subnetting plan is already being pushed out and realizing you don’t have enough subnets to finish your deployment.

So have at it. Questions? Comments?

John Curran: Microphones are open for discussion of this policy. The chair will moderate the discussion. I recommend everyone speak their views.

Tim Denton: A thundering herd approaches the microphones.

John Curran: I will note that if you’re in favor or opposed to this proposal, please come up to the microphones and speak.

Tim Denton: Sir, you’re recognized.

Dani Roisman: Dani Roisman with SoftLayer. Generally I like where the proposal is going. I’m concerned about the unclear definition in the very last bullet that’s suggested where it says “sufficient actual utilization at their serving sites.” What is the gauge of sufficient actual utilization?

Heather Schiller: To continue to justify the block being used as specified in 6.5.2. So 6.5.2 defines the utilization criteria, and then so it’s basically as long as you’re complying with 6.5.2 in your assignment plan and in your utilization and you – and basically – and you have more subnets than you did when you originally justified. Does that make sense?

So as long as you’re sort of continuing down that path but you’re still using the 6.5.2 initialization criteria.

Dani Roisman: Do you have to meet the criteria of 6.5.2 in every serving site?

Owen DeLong: Heather?

Heather Schiller: No. It’s not in each serving site. It’s in the number of – sorry. It’s in the number of subnets and customers you deploy, I think. So it’s sort of overall. So the idea is that you’re adding – so when you originally applied, you said I had 200 sites that I was serving and –

Tim Denton: I think Owen is trying to contribute here.

Owen DeLong: 6.5.2 is pretty clear. It’s based on your largest serving site. So basically to fall out of compliance with 6.5.2 you would have to be able to shrink your largest serving site by a full nibble and still have a 25 percent min free in the serving site.

If you can’t meet that criteria, then your largest serving site still qualifies under 6.5.2 and the question falls under this proposal as to whether you’re out of blocks for additional serving sites, basically. If you’re out of block for additional serving sites and you have additional serving sites, then you would qualify under this policy for additional address space.

Dani Roisman: That makes sense. Thank you.

Owen DeLong: And I do have a separate comment.

Tim Denton: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I support the policy as written. It corrects an oversight when I wrote the original policy that is currently in effect, and I applaud the authors for doing a really good job of finding a way to navigate what turned out to be a very complex problem to solve in addressing this issue.

Tim Denton: Mike.

Mike Joseph: Mike Joseph, Google. I have a question. The language added to Section 2.1.4, specifically the one highlighted in red on the slide up there, seems to be in direct conflict to 6.5.2.1(f). Is that intentional?

The language in 2.1.4, although it doesn’t require aggregation, does require topological address assignment, whereas 6.5.2.1(f) specifically notes that no constraints are placed on address assignment.

John Curran: So it is clear that 6.5.2.1(f), which reads “An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP block which the LIR is entitled,” will be overtaken by this policy proposal, because, to some extent, while not specifying your network architecture, we are talking about serving sites and the structure of each.

So I think 6.5.2.1 where it says you’re not required to design or deploy your network according to this structure, it’s still accurate. You’re not required to. But the structure of your serving sites will decide the size of the block you get.

And it might be that they could be read in conflict. I don’t think you need to change 6.5.2.1(f), but as we get more complicated v6 policy, if your network doesn’t meet it, you won’t get additional space.

Tim Denton: Mr. Leibrand has a point of information.

Scott Leibrand: I believe my understanding is that because of the way the new policy is structured, where this is a list of bullet points where it’s basically any of these type of things, that the definition of “serving site” here only applies if you are choosing to take advantage of this particular way of aggregating and using the aggregation to justify more sites. There are other ways of justifying your usage, which I think 6.5.2.1(f) still would apply to as written.

Mike Joseph: Except that this is Section 2, which is definitions, so it would apply to both initial and subsequent allocations.

Scott Leibrand: Right. But it’s definition of serving site, and serving site is only referenced, to my knowledge, in the red text here.

Mike Joseph: No, serving site is referenced all over initial allocation. So it substantially changes both subsequent and initial allocation criteria, is my point.

John Curran: Serving site is presently in 6.5.2, the initial allocation to LIRs. This changed to serving site, which is 2.1.4. I will need a moment, but it may change the impact of initial site.

Tim Denton: Jason Schiller.

Jason Schiller: Jason Schiller, Google, NRO NC. So I think some of the lack of clarity here comes from an interpretation of what is meant by the phrase “serving site.”

And if we look back at the originating text for this and some of the previous discussions that we had, granted, it was much more complicated and never passed muster in this community, and I’m not suggesting we go back to it, but if we try to distill from that the original intent, basically the concern was that you might have a hierarchy of serving sites and you might be – might have an inability to draw down resources to fill a lower-level serving site or a customer endpoint.

And that was what was kind of the idea of this must have a subnetting plan, must have at least one customer in each subnet, blah, blah, blah, language, which is completely gone.

But the point I’m trying to make here was there was a concern that if hierarchical serving sites are supported under this policy, then somebody could build an arbitrarily complex hierarchy of serving sites and try to justify a lot of space. And I believe the way that people were trying to counteract that was to say you have to give out your addresses to support this hierarchy that you’re claiming is in use.

And I’m not sure that that was the original intention of the initial allocation, whether hierarchy was intended to be supported or not.

When we discussed it initially, there was some discussion that hierarchy was supported with the original phrasing of shall include but not limited to points of presence, data centers, central or local switching office or regional or local combinations thereof.

So I think that’s probably where this confusion is coming from.

John Curran: In looking at the change to serving site definition in the policy text, while we do – while it does add the sentence that says it is not required to be implemented of such aggregation and routing, the actual change to serving site is only stating that it’s not required to be implemented in routing; it’s not a material change to the definition.

So even though serving site is used throughout the text, I don’t think it changes the impact of initial allocations.

Tim Denton: Louie Lee, and then, Mike, when you’re ready.

Louie Lee: Louie Lee, Equinix and also the chair of the ASO AC. I want to mention that for the community to consider the staff comments heavily, because if you want this proposal and it matches up with the staff comments of intent, then they need a clear way to apply the intent of this.

So if this is too complex or worded in a way that they can’t implement, then might not be of much use.

Tim Denton: Louie, for the sake of clarity, for or against it as drafted now?

Louie Lee: I’m still formulating that. Thanks.

Tim Denton: Mike Joseph.

Mike Joseph: Thanks, John, for the clarification, but the issue is a little bit – it says it does not require the implementation of such aggregation in routing. It further says only the implementation of an addressing plan that is subnetted along these topological boundaries.

But nothing currently in any part of the IPv6 policies require any particular subnetting plan to be adopted by the ISP, only that a particular formula is specified by which the ISP can determine the amount of space to which they are entitled.

Therefore, this represents a change to both initial and subsequent –

John Curran: I see. So your point is that this states that you will implement those subnets as stated, and because this is a definition in the initial allocation, once you’ve qualified for your initial allocation block size, it would imply that this serving site definition means you must implement along those subnet boundaries.

Mike Joseph: That’s correct. That’s a concern I have.

Heather Schiller: So the idea was that if you were trying to use additional subnets as justification for getting more space, that you actually have deployed this subnetting plan that you justified under and like shown sufficient utilization of the subnets. And the way to do that was to constrain it back to the initial allocation criteria, because otherwise you would have a situation where someone could create arbitrary subnets and say they were done.

John Curran: From a practical matter, a party that goes and gets an additional allocation, even though this isn’t in the subsequent allocation policy, they would need to have implemented subnets along the topological boundaries.

Mike Joseph: Despite the language in 6.5.2.1(f)?

John Curran: Well, because the proposal text says –

Mike Joseph: You’re talking about if this proposal is adopted.

John Curran: If this proposal is adopted, then they would need to have an implementation of addressing plans subnetted along the topological boundaries.

A party in theory that received an initial allocation would also need to have that, but I’m not sure how we’d ever know if they did not come back for subsequent.

So you’re correct, this does create an implied constraint on someone receiving an initial allocation that they use it. It says they will use it because that’s now in the definition. I’m not sure that text is ideal under serving site as opposed to actually in the subsequent allocations.

But in actual implementation, it won’t make a difference. If a party doesn’t come back, we will never know their subnet structure. Understood?

Mike Joseph: I think so. Though it sounds like what you’re suggesting is that someone applying for initial allocation may be making implied representations to ARIN that would simply never be validated.

John Curran: This now says that your serving sites are to be – it says that your serving site definition now says must be implemented in addressing plan that is subnetted along the topological boundaries.

So it’s an assumption that when someone is going to do their request initially, because this is in the serving site definition, they’re telling ARIN, yes, if I come back to you, I will definitely have this.

I don’t know what it means if they don’t ever come back to us, I really don’t.

Tim Denton: I saw Owen DeLong and then Jason.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC.

I think that this really – we’re nitpicking a piece of this that doesn’t actually affect policy. What your subnetting plan will be or is or isn’t really doesn’t apply if you haven’t got space yet.

So in an initial allocation we’re looking at what your plan is in terms of the number of serving sites you can justify. And we don’t really have any way to see or know how you’re going to divide those up after you get the space. And so although the language is there, it isn’t really applicable in any meaningful way to an initial allocation.

Certainly I think that it would be better if we moved that portion of the language down into something that is specific to this policy rather than leaving it in 2.1.4, though it’s going to take some additional wordsmithing to make it make sense outside of that context.

That’s something that the AC can probably do on the way to last call if the community feels strongly that it’s necessary.

Personally, I think as is it’s significantly better than what we have today and that it doesn’t pose any unnecessary constraints on initial allocations.

Tim Denton: Jason.

Jason Schiller: Jason Schiller, Google. So I’m very confused now. If I pick some sort of a unit for serving sites, say, oh, I don’t know, a metro, and I find my biggest one and I count up the number of customers in that metro and I come to some number, say 200, and I round that up and I say, oh, I’ve got eight bits per metro, I’ve got N number of metros, please give me a / whatever.

Owen DeLong: 200 gets you 12 bits.

Jason Schiller: Okay. Round it up to the nearest nibble, 12 bits, because I’m over 75 percent. Sure. So I get a / whatever. I then don’t actually deploy a numbering plan that is aware of metros. I simply give out /48s to each customer in serial as they come up. And then I’m about to run out of /48s. I’ve got one left. I go back to ARIN and I say, Hi, I’d like more space.

Under this policy that currently exists, I believe I can get it. Under the new text, it doesn’t look like I can get it because I’m not following the topology of the network. Is that true?

Tim Denton: Owen DeLong.

Owen DeLong: No, it’s not true, because you would be able to submit a different topology for your justification for the new space that would match what you’ve done, which is essentially I have one serving site, I’ve used 65,535 out of the 65,536 /48s. I’m therefore over 90 percent and I qualify for more space. Done.

Jason Schiller: But I could not submit a justification that says in a metro region I’ve got 800 customers and I’ve got N number of metro regions, and therefore I need a larger allocation than under the one you just described with the single server site.

Owen DeLong: If you haven’t built out your metro regions as a hierarchy and you’re routing them as a flat routable address space, no, because the hierarchy is designed to support your routing needs.

If you’re able to treat your entire network as a flat address space, you don’t have hierarchical routing needs, and therefore you’re operating essentially as a single serving site because you have one point of aggregation at your border.

John Curran: It’s any of the criteria. So you can say I’m one serving site or you can show 75 percent of your total address space overall.

Jason: Okay. Thank you.

Tim Denton: All right, then.

John Curran: Any more questions?

Tim Denton: I’m waiting. Mike Joseph.

Mike Joseph: Mike Joseph, Google. I support this policy in general. I would request that the language in 2.1.4 be removed prior to moving to last call. It obviously doesn’t belong in 2.1.4, and I’m not sure that it’s even necessary in 6.5.3.

Tim Denton: So then we should adjust the vote, I think, to be a couple of votes. First is to as written, and then your proposal is that – say it again, Mike.

Mike Joseph: Strike the first change from 2.1.4.

John Curran: Strike the change in 2.1.4.

Tim Denton: And we’ll have a vote, and the vote will be to approve it as written. Yes. And then, if that fails, to give it to the AC for further work.

What you’re going to be asked to vote upon for the first vote would be to approve it as written. The second vote will be to refer it to the AC for further work.

John Curran: We’re going to have a vote. Remote participants get ready. We’re going to try to slow down the pace of the vote to make sure that the remote participants have the time to cast their support.

Tim Denton: Mr. Schiller.

Jason Schiller: Jason Schiller, Google. I’m confused what the vote is on. Will it be a cleanup of the text in last call, or this is to go back for discussion?

John Curran: I believe the vote, the first vote, is going to simply be in favor of advancing this policy proposal as written. And that would be a yea/nay vote. And potentially, if that doesn’t show support, then there might be another vote.

Tim Denton: So the first vote is to approve it as written. Second vote will be in consequence if that does not pass, then back to the AC for further work.

Please raise your hands, those who are in favor of this policy proposal as written.

John Curran: Nice and high. There’s a break coming up soon, so you’ll get to relax.

Tim Denton: Done. Those who are not in favor of the proposal as written, please now raise your hands.

You can lower your hands now.

Tim Denton: The Proposal 2012-2: IPv6 Subsequent Allocations Utilization Requirement. Number of people in the room, 128. Approval as written, in favor, 22; against, 15.

John Curran: So, in light of that, we’re going to ask a simple question, another poll, on whether or not people are in favor that the AC continue to work on the policy proposal, yea or nay. Okay?

Tim Denton: Those in favor of the AC continuing to work on this policy proposal, would you please raise your hands.

Heather Schiller: I take it that you’re all volunteering to help me with the wording, right? I see a lot of volunteers.

(Laughter.)

Tim Denton: Those who do not favor referring it to the AC for further work, for whatever reason, would you please raise your hands.

Discussion Topic Draft Policy 2012-2. 128 people in the room. Those in favor of referring it to the AC for further work, 45; those against that idea, zero.

John Curran: Thank you, everyone.

(Applause.)

John Curran: People have to realize that these are indications to the AC. The AC is an elected body that advises the Board on policy. They look at the discussion and they look at the support for various directions and they do the right thing. And that’s up to them. Okay? And they may change the policy proposal after this and send it to last call. So there’s an option to edit it if they want to.

If they make significant edits, then they probably shouldn’t. They’ll come back to another meeting. And that’s also their judgment. Okay. So this is indications to the AC, the elected body, on how to do their job on this policy proposal.

I need to be very clear here: At the end of the day, folks, the best way to make sure they do the right thing is to find the AC members and tell them what to do.

You can see them. They all have badges that don’t look like this. They say “AC” at the bottom.

Now we’re going into a break. Amazingly, they’ll be out there at the same time you’ll be out there. So that’s not a coincidence. That’s planned.

We’re going into a break. When we come back, it will be 11:00, and we have a number of presentations coming up. Thank you very much.

John Curran: We’re running a little ahead of schedule. Luckily we have a presentation of some interest, I think. The esteemed Geoff Huston will come up and give a presentation on, let me guess, DNS over IPv6.

DNS Over IPv6

Geoff Huston: Good morning, everyone. Geoff Huston from APNIC. My boss, Paul Wilson, may or may not be listening to this. It’s 3:00 in the morning, so let’s hope he’s not.

And, evidently, he says folk often ask him: What does Geoff do?

(Laughter.)

Geoff Huston: And I’ve heard the answer is: I have no idea; you should ask him.

This is a little bit of what I do. And it ties in actually to the discussion you had in the first part of ARIN policy about IPv4 reservations for critical infrastructure.

Because there was this implicit assumption in that discussion that these new DNS gTLDs absolutely desperately needed IPv4 for the Internet to see them.

That’s an assumption. It’s not a fact. It’s an assumption.

So in my mind was this question: Is that true? And the corollary question is if I put up a domain name, a zone, entirely on v6, how much of the Internet could see it?

Interesting question. So I’d like to talk about that. And I’d like to talk about how you measure that. So there are three kind of questions flying around here that I’d sort of like to take a shot at answering.

The first thing is I don’t actually need to know about you. If you’re, say, in the Sheraton Hotel and you look at your DNS resolvers, you’re actually not doing the resolution, you’re passing it off to Google’s public DNS servers because the first one on the list that I got on my MAC last night was 8.8.8.8. So I don’t really care about your v6 stuff; I care about whether 8.8.8.8 can do it.

In other words, I’m looking at the resolvers, not the clients. So that first question is: What proportion of these resolvers are actually capable of doing the DNS query over v6 transport?

But ultimately it is about you and me. It is about the user. So when I put up allthingswonderful.net in v6 only, how many of you folk could resolve that name and go and visit the site even in v4?

So the next question: What proportion of users are using this?

And the next one gets back to one of these stuff-ups in v6. We really, really did get fragmentation different in 6, and the semantics are bizarrely weird. Instead of fragmenting and moving the packet forward, a packet that’s too big stops in its tracks and a message gets sent back.

Now, that assumes that an interior router can actually send a message back to the source, which is not always the case, but it also assumes that the sender gives us stuff.

In TCP, the sender cares. Because it’s TCP and that’s your job. UDP is an “I don’t give a stuff” protocol. So when you get back a message to say, you know, that UDP packet you sent was too big, the server kind of goes: Tell it to someone who cares; I don’t.

Now, normally that’s okay, except in the DNS. Because what happens next? Long timeout inefficiency.

So I’m really interested in that third question: If you go v6 in DNS, are you going to tickle some UDP bugs that ultimately completely break you? Interesting question.

So how do we do this? The ad network is brilliant. Everyone watches YouTube. Everybody on the planet watches YouTube, evidently.

So all I need to do is create an online ad that simply has two fetches. Why two? Because I wanted to try and sort of exacerbate things by putting the packets a little bit small and just a little bit big over that 1500-octet point. Both of these domains, t7.dotnxdomain.net, only resolve in v6.

So you can go there now if you want, and if your DNS resolver will handle v6, you’ll get an answer. If it doesn’t, you won’t. It’s simply filed because there’s no v4 NSs in there.

The other part of this is when you’re doing these kind of experiments, caches are your enemy. Any form of proxy caching is terrible.

What we do now is use wildcards through the kazoo. With a little work in flash, with a little bit of mucking around, you can get the user to generate their unique domain name, which is totally unique. So those UNS strings are basically a combination of the time, 134, blah, blah, blah, and a really unique number, that U number. So nobody’s caching this domain name. Every time you ran or saw the ad, it was a new number. It was completely unique.

So there we were. We set up those domains with NS records only. We put it in the ad and allowed folk ten seconds to do the resolution and then generated a resolve.

And we called on Google to do this. Google’s got one of the better ad networks. And it’s cheap, really cheap. You only pay for clicks, and as long as nobody clicks, you can get quite a lot of impressions very cheaply.

So we ran this for six days, just six days. That particular part of the experiment cost us a thousand dollars, because only about 30 people clicked, thank God.

(Laughter.)

But those six days we actually managed to get the experiment executed – in other words, loaded up – 2,299,000 times, which is amazing.

The problem is, though, these days on the net, your attention span is not ten seconds. It’s not four seconds. Your attention span is about three seconds.

So a huge number of times, 2.2 million, you go before I even get to execute something. You’re just on another page. You just go again. That’s the attention span of today’s modern society, about three seconds.

Of those 2.299 million attempts, only 432,000 ever actually got to doing the DNS query.

So we’re kind of getting to some numbers now.

So the first question is really a question about resolvers, how many DNS resolvers did we see that queried that actually managed to do that query in any part of the experiment, and what’s the subset that managed to do the query over 6 for the t7 subdomain.

So of those 432,000 that then had to execute some flash code and actually had this working for a few seconds, again, the number of unique resolvers here is lower than you might think. 111,000 unique DNS resolvers, which 5,000 can do it in v6. Not bad.

So that’s 4.6 of all resolvers out there can perform their DNS queries using v6. Not a bad number. Certainly more than the number of clients who can run v6 by orders of magnitude.

This is cool because only 1.6 percent of the resolvers can even do DNSSEC. So, you know, there’s some good news out there one way or another. It’s not that bad a result. Where are they? These ads are everywhere. And actually track individuals. Philip Smith of APNIC spent an awful lot of time in Bhutan. And guess what? There were more v6 sort of resolving clients in Bhutan than there are in v4, effectually because they use v4 resolvers in other countries.

But those first set of ten countries are actually completely unexpected. Unexpected that I even managed to get folk there running this particular test.

I call your attention to the Faroe Islands, which I never expected to see in a lost of top ten countries, nor did the folk in the Faroe Islands, I’m sure.

But maybe I’m just trying a bit hard. If I actually pull this down a little bit and look at the origin AS of these rather than the country code, you start to see where these resolvers are that actually are doing v6 resolution.

Google, of course, the public DNS runs, v6 resolution these days. Then that’s enormous. It has an amazing impact.

Then you get some strange ones like Thailand. Comcast is doing it from the U.S. but you look at the other sets of countries – Romania, Indonesia, Portugal, and Croatia and Malaysia – it’s not all concentrated in the large resolvers in the developed parts of the world. It is actually all over the place.

So the message about v6 in the infrastructure is actually pretty well understood. So now let’s talk about you and I and the resolvers we use.

So how many folk did the experiment? Well, we said 2.3 million. And of those how many were actually able to do this in 6? Wow, one in five.

If you kept on improving this, within three years, even within two years, you could put up a DNS server in v6 only and it would work. Almost irrespective of the number of folk who can actually at the client level do v6, the resolvers will actually resolve a domain using v6-only transport.

That’s an amazingly big number. You know, 19 percent is brilliant.

So let’s look again, not at the number of experiments, but let’s actually look at the number of unique IP addresses, the number of folk who I would class as clients. Some folk actually pulled down this ad a few times. It’s still 890,000. I’ve got 161 hits in 6. I’m still at 18 percent.

So, in other words, most of you can’t, but one-fifth of you can. Isn’t that fascinating? I think that’s really encouraging, actually. So where are these clients? Again, where did the ad go? Let’s color the map.

Bright yellow says heaps. Dark red says not heaps. Algeria. The Baltic States. In fact, here’s the list. And this is probably the first and only time in the history of civilization that Nauru is at the top of a country list. Because I saw one user, and they were able to resolve that domain in 6. Go Nauru. And I think Burundi would also be similarly celebrated. It’s the only time it’s been two.

So, yes, oddly enough, the small numbers bias it, and, oddly enough, those small numbers, maybe they’re using public DNS, but the small numbers are quite high. Let’s get rid of the small numbers and see who is left.

These are the countries where I saw at least 500 countries or 500 endpoints performing the experiment: The occupied Palestinian territory, Algeria, Latvia, Belarus, Slovenia. I’m looking out to the United States, and it’s down there, way down there, oh, around 30 percent.

So, oddly enough, clients in some countries like the occupied Palestinian territories, 52 percent of them can resolve in v6. Wow. Some folk have really got the message and are doing it brilliantly.

Even France, 25 percent. So this is actually amazingly good. And these are the folk who can’t. The Republic of Korea stunned the world ten years ago by being top-of-the-world broadband penetration deployment index. It was 78 percent of their populous were able to access the Internet at megabit speeds. But not using v6. Because they’re down at the bottom.

So, yes, it’s a very, very varied list there of who can and who can’t. And, yes, that is the United Kingdom all the way down there at 4.5 percent. Get your act together.

What about ASs, the top ASs? Again, Nicaragua. Quite surprising. Google with its public DNS, of course, but that actually isn’t the public DS. These are insights sitting behind Google’s AS. You can see the rest of the list if you look at it online. But, again, that’s a quite surprising diversity of folk who are actually using services that resolve in v6.

So the next question: Is it wise? Are you going to break stuff if put your name servers in v6? And the real question is: How does it handle UDP Path MTU discovery? Will it stuff things up?

Well, there’s an Australian by the name of Mark Andrews who actually does most of Bind software, as far as I can tell, whose idea of documentation is read the code.

So helpful. But his sticky fingers are all over Bind, and he got there before us. Because if you’re running Bind as your authoritative name server, it doesn’t push packets out any larger than 1280. It sits at the minimum.

So try as I might, because I was running Bind, I can’t break things. But you can, and you do. Occasionally you say, I can’t handle frags; give it to me in TCP. I say fine. Here’s TCP and I’m sending out 15 octet MTU packets. They’re big.

And if I encounter a router that doesn’t like it, it’s meant to do the right thing. What’s the right thing? It sends me back a message saying that packet was too big. Here’s what you should try.

So I’ve got four messages saying you should try 1280. Fair enough. 19 messages saying you should try 1476, which is 24 bytes of uptick, which seems to be some kind of IP packet header. 265 says you should try 1480, which looks like a protocol 41 GRE tunnel. And 4,382 messages said you just sent me a 1500 octet packet. That was way too big. You should try 1500 octets. So helpful. But I recorded them.

So if you’re in the Swiss Educational Research Network, you have 2001:620:610:20::20. Go and fix it. It’s insane.

And here are all the others from there, including our dear friends at JANET, the French Research Network, BELNET, and so on. If you see yourself there, go and find your router and fix it, because you’ve just stuffed things up. Because if you can’t accept 1500 octet IPv6 messages, nothing’s going through.

So the good. 18 percent of folk will actually see you if you put your name servers behind v6. That’s brilliant. Hopefully within a couple of years we won’t have to worry about preserving some v4 for critical infrastructure in the DNS, because hopefully within a few years we can get that 18 percent up to 98.

That’s actually really, really good news. But we also have been using for a couple of years exactly the same ad using v6 infrastructure at the endpoint to see how many clients will actually drag down an object end-to-end in v6. And it’s still not anywhere near that.

.18 percent will actually use v6 to actually fetch the object in the end. It’s kind of good news and not so good news at the same time.

Thank you. Any questions?

John Curran: Interesting presentation. There must be questions. Remember to identify yourself.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Any clue what insanity those routers are smoking or whatever?

Geoff Huston: I really thought at one point that it was inside one country, it was a particular vendor and they just got the standard wrong and it was just a bad implementation of v6 where they put the MTU of what it received, not what it would do. And it could still be that. But that’s a really diverse collection. And the numbers aren’t sort of overwhelmingly big, although there are a lot in China. So I still suspect it’s a vendor. But I suspect it’s a configuration thing where somehow they’ve got the way they configured it just wrong and they’re sending back what they heard, not what they can cope with.

David Farmer: Looking at the list, I see a lot of R&E stuff, and we in our community have been doing v6 for a long time. So we could have some routers with some really old v6 code on it. I know I do.

Geoff Huston: But the assumption is that if they send me this packet, they’re not delivering. So every single 1500-octet packet doesn’t make it through, which means behind those routers, which they thought they had v6 on –

David Farmer: There’s a lot of people who think they have v6 on and don’t.

Geoff Huston: That lot there, including the University of Macau. You can go through this. They are quite an astonishing, eclectic set of networks.

David Farmer: So you haven’t been able to figure out, oh, it’s vendor X with code blah.

Geoff Huston: It would be impolite of me to go and hammer these particular IP addresses. But if others wish to have a look, feel free. That’s the list.

(Laughter.)

Louie Lee: Louie, ASO AC, Equinix chair. Did you see anywhere on those country lists Australia? I didn’t notice where it was on the list.

(Laughter.)

Geoff Huston: It wasn’t in the top. But it wasn’t at the bottom either.

That top list, if I can find it again, that top list, particularly that first list, this ad network is truly astonishing. You know, if you run this ad for just seven days, you actually cover 211 countries almost immediately for remarkably small amount of money. So this sits inside the research budget easily.

But, yes, Australia wasn’t good, wasn’t bad. It was just in the middlish somewhere. As you probably heard elsewhere, we have large telecos that dominate much of the market who specialize in trailing-edge technologies and swinging their dinosaur towel. What can I say?

(Laughter.)

Scott Leibrand: This is kind of the other side of the PMTU thing, but you might be interested to know that we recently ran into a bug in the previous de-implementation of Path MTU Discovery such that when we received a PMTU packet-too-big packet back, it was not actually updating the TCP session involved and was resulting in a lot of retransmissions back and forth to certain v6 clients.

So that may be an interesting way of – I mean this path MTU thing, this is probably not an ARIN topic, but it is interesting. There is more brokenness here than we may have realized.

Geoff Huston: I actually don’t see this as being an evidence of much brokenness. Don’t forget I ran this across 2.3 million folk, and the number of resolutions were high. And that’s the only evidence of brokenness I found.

That one page of routers out of the entire IPv6 Internet structure, I now have a list that you can go and fix these and I would find no errors. I think that’s really good. I think if you got broken down to that level rather than mindboggling huge lists that’s, fixable.

So if any of these are your routers, anybody, who’s even out there on the Web, go fix, and it will work.

Heather Schiller: Heather Schiller, Verizon. Like you said, a report. Do you publish it anywhere so people can like beat each other up over this stuff?

Geoff Huston: I will be publishing a report on labs.apnic.net just as soon as I get time in between the more fascinating parts of this meeting. It should be up by the end of the week. Thank you.

(Applause.)

John Curran: Next up we have an ICANN/GNSO/ISP constituency report.

Izumi, are you here?

ICANN/GNSO/ISPCP Report

Izumi Okutani: Hello everyone. My name is Izumi Okutani, and I’ll be speaking on behalf of my colleague about ISPCP, which is one of the constituencies in ICANN within the GNSO.

And you might think: Why is she talking about domain names in the ARIN meeting? The whole idea is that the people in ISPCP feel that they would like more people to be aware that you can actually be involved in discussions of gTLD policies, and the people who attend RIR meetings like you are exactly the kind of people that they would like to have more input and participation because you have more like knowledge and insight from Internet service – insight from the operations of the Internet and the Internet services.

So the same presentation was made at APNIC, RIPE, and then I’m presenting here in ARIN on behalf of my colleague.

So for the next few slides, I think most – most of what I’m going to speak about is something that you already know. So please listen. It’s a brief summary of what you already know, and I’m just sharing this information just to give you an idea of ISPCP’s involvement with the ICANN structure.

As most of you know, the role of ICANN is to coordinate on global Internet’s unique identifiers such as domain names, IP addresses, and protocol numbers.

And I think the key feature of ICANN is that they take the multistakeholder approach, not just simply by saying that the participation is open to everybody, but if you look at the structure of their board, they ensure that stakeholders from various areas are represented within their board. They have two people each from each of the three ASO’s supporting – each of the supporting organizations. One of them of course is the ASO that represents the addressing community, and two remaining ASOs in their domain name area, which are GNSO and ccNSO.

And I would like to speak a little bit more about GNSO, because this is their supporting organization that ISPCP is involved. As you can tell from the name, it’s the supporting organization that discusses about the policies for generic domain names, such as .com, .net, .info, and responsible for developing substantial policies on gTLDs, and they make recommendations to the ICANN Board.

So I think you still have fresh memories about the new gTLD program that’s been implemented. So a lot of this has been discussed in the GNSO. And I think the key feature of GNSO compared to ccNSO is that they take the multistakeholder approach.

So while ccNSO is pretty much based on each country code’s registry policy, there’s not a lot that’s – like any people outside the registries get to have a say on the ccTLD policies, but for the gTLDs. It’s not just the registries or registrars who get to have a say, but within this supporting organization they have what’s called contracted parties that constitutes from registers and registrars, but they also have noncontracted parties. So it’s like those of you who are here, too, get to have a say on the gTLD policies.

So if you look at its structure, the council itself constitutes of 22 members, and roughly half of them are contracted parties which are registries and registrar. The remaining half is noncontracted parties. So this is the parties that where you get to have a say even if you’re not directly involved or have contract with ICANN.

And ISPCP is one of the constituencies that belongs to noncontracted party house and they belong to commercial stakeholder groups.

And I think all of you know that anybody can participate in the meeting of GNSO, but to be able to have your opinions reflected in the GNSO, just simply popping up to the GNSO meeting, does not like – well, I wouldn’t say help much, but then the idea is that you participate in one of the discussions of the constituencies that you belong to, and we believe that ISPCP could be one of the constituencies that you can participate.

So as you can tell from its name, it’s short for Internet Service Providers and Connectivity Providers Constituency, a little bit long and tongue twisting, but the membership criteria is that if you are an ISP or carriers or any of the associations of those, then you can become a member.

So you have to apply to become a member to be able to join the discussions, but it’s very simple. As long as you submit the application, then there are no further criteria.

And what I hear is that I think the total number is roughly about 40 or something in total. And they have about 10 active members who actually really give active inputs. And mostly currently constitutes major telecos like British Telecom, Deutsche Telekom, Aetna, et cetera, et cetera.

So they’re really looking for like contribution from new faces who can give like inputs from a different perspective.

And the kind of topics that are being discussed is of course still the new gTLD continues to be a hot topic for discussions. And there are also others such as discussing about Whois policies to have a consistent Whois output throughout different registries including domain name and IP address registry, kind of related to what’s being discussed in weirds in the IETF. Another topic is SSR. I think it’s short for security, stability, and resiliency for the Internet.

So I think there are rooms for you to give inputs in these areas. And I don’t know in the case of the US, but then at least in case of Japan, I hear ISPs talking between each other about the new gTLDs, but you can actually – not just talking to each other, you can actually participate and get involved by becoming a member of ISPCP.

So I think they recently had a meeting in Toronto last week, and the next one will be in Beijing.

And if you don’t feel comfortable to immediately become a member of ISPCP, they have the public Mailing List archive so you can see what’s being discussed without being a member. And you can also participate – just join the meeting without becoming a member, too.

So if you have any further questions, please contact the email that’s listed here, or I’ll also be here for the whole day today so you can talk to me, and I’d be happy to direct your questions or comments to my colleague who is actually involved in this activity.

Thank you for your time.

(Applause.)

John Curran: Any questions for Izumi?

Next up we have some of our afternoon reports. And we’re going to move ahead into the report for AFRINIC.

And, Ernest, are you here? Ernest Byaruhanga. Thank you.

RIR Update - AFRINIC

Ernest Byaruhanga: Good morning. My name is Ernest. I’m from AFRINIC. I’ll use the next few minutes to update you a little about what’s happening in our region and what we’ve been doing and any activities that are coming.

We’ve been mainly involved in the structuring, organizational structure, to improve organization efficiency. And most of the operational functions of the registry are now under a COO who was hired some time back. She was actually hired from ICANN. Some of you could know her. Some of you know, Anne-Rachel. She’s our new COO. And most of the functions of the registry actually fall right under her. That’s how the structure looks like.

Activities at a glance. We now have 33 full-time members, and most of those, actually about 30 percent, about a third of the staff, were hired in 2012.

So we have many new faces at AFRINIC. Some of these are still trying to adapt to the staff we found, and the way around, but all this is for the good of the organization.

You have actually 30 percent new people joining in one year. It’s not easy. But we’re all adapting and trying to move along.

Just in 2012 we have issued about 3 million IPv4 addresses. This might not look like a big number from this part of the region, but on our side actually this is quite huge. We’ve seen quite a lot of demand in IPv4 addresses, and we think that the depletion might happen sooner than we have anticipated with the demand and the consumption.

So our free pool inventory. We have about 67.4 million IPv4 addresses left in our inventory. That is as of yesterday. That’s about four /8s available.

On the membership side, you see we have about 107 new members, and our total membership is about 866. That excludes legacy members. That excludes organizations that are holding legacy resources. If you were to put those into consideration, we have about 1,300 members in total.

So the legacy number is actually quite a huge chunk of our membership. We have not gone the way of the legacy RSA in the ARIN region. Maybe it’s perhaps something that the Board would be looking at in the future.

We’ve been busy with IPv6 training. We conduct v6 training on a monthly basis all over our service region. These are actually technical workshops that target engineers, people that are relatively confident with deploying IPv4 networks. Technologies are growing, and we try to impart our v6 knowledge to them so they can go on and duplicate the same knowledge in their networks.

And usually every network, every training that we do, we try to make sure that when we leave, there’s a list of functional IPv6 networks in that country.

So we’ve done 66 – sorry, we’ve done 15 this year. And we are planning perhaps the same number next year. That’s quite a busy time for our trainers.

IPv6. We’ve issued so far 66 new prefixes in 2012. Again, this, of course, might look like a small number. But in our region, this is actually quite big, given that we have 54 countries and the uptick is not as big and as fast as the other regions.

But this is very good growth for us. And we hope to see more numbers in here, because the community is well aware right now that v4 is running out. We’re doing enough evangelization, and we hope to see these numbers increasing as v4 depletes.

There are currently five active policy proposals in our region. The Mailing List is not that busy, but, yes, they get busy once in a while. These are the proposals we’ll be talking about at our next meeting.

Just to quickly go through them, one of the proposals tries to include ccTLDs as part of critical infrastructure. This was quite well received on our Mailing Lists. There was support for it, and we hope at our next meeting the community will have consensus on that.

There’s a proposal for a type of privacy for Regional Internet Registry data. This talks about what sort of data is considered private and what’s not considered private, what data can be given out by the registry, et cetera.

Then anycast assignments. This is a proposal to be able to issue v4 blocks on v6 blocks for anycast purposes. We didn’t have such a policy in our region, and there has been a need for it, and the community seems to be okay with that.

The other one, no reverse DNS unless the prefix is assigned in the host database. Here the author is looking at the ability to not provide robust DNS for customers of an ISP unless their IP addresses have been registered in the Whois database as assigned, or reassigned as you call it on the ARIN side of the street.

And the last one, periodical cleanup of AFRINIC Whois data, this is data that is considered out of date or not referenced in other objects.

So these are the policies under discussion at the moment. We do not have a transfer policy yet. Some people in the region have been talking about it. Although, the times that it’s been mentioned, the community does not seem to welcome it yet. There’s always some opposition to transfer policy every time it’s mentioned. So we don’t see that coming up yet in our region. Perhaps when we hit the final /8, it might pique some interest, but not so far.

These are the IPv4 stats so far. Total IPv4 addresses issued in the African so far region, including the addresses that are issued in the region by the other registries, about 50 million IPv4 addresses. What’s interesting is of those 50 million issued since 1984 in the region, actually more than half of those were issued in the last four years.

So we’re seeing tremendous consumption of v4 addresses, and, again, this goes to highlight that exhaustion in our region might happen sooner actually than we anticipated.

That’s the v6. That’s the trend of v6 growth in our region so far. Also we’ve seen quite a lot of v6 demand in the last three years, perhaps because of the training and evangelization we’re doing with v6.

That’s the distribution. South Africa, of course, being the largest economy, takes about 30 percent of the v6 in the region.

We’ve been working on what is called Extended Stats Project. We tried to do quite a lot of in-house cleanup some time back to try to automate management of our resource inventory, and this also happened at the same time when the RIRs were doing what is called the extended stats.

Extended stats – all RIRs publish their resource data online, on FTP. This data usually involved resources that have been issued or that have been assigned or allocated. It did not include information about resources that are available or resources that have resolved.

This is a project that we have been doing, as well as the other registries, actually, have been involved in doing the extended stats. We finished this project some time back, and our extended stats are now available online. So if you want to run your scripts to look how much space is available at AFRINIC, how much of that has been resolved, then you’re free to browse the area in red to look up the statistics.

Again, thanks to Geoff Huston who actually – he went back to look at some of the inconsistencies. Thanks, Geoff.

Communication and outreach. We’ve been rebranding. For some of you that have visited our website and our meetings in the past, notice that our logo has changed from the one over there with a butterfly thing to the one on the right. So we’ve been involved a lot in branding and having a presence in social media.

We also have a flashy new website, which we’re still trying to put more content in. The migration has not been easy. We put up a dedicated training portal where all our training content is, and it’s where we manage all our training events from registration to feedback and all that.

There’s the FIRE initiative, which basically gives out monies to persons or entities that can generate content in the region. And that’s only open to people in the community.

And then we have the African Internet Summit, which will be coming next year. The African Internet Summit basically is a rebranding of AFRINIC and AfNOG meeting, as well as the other players that are involved in activities to do with Internet technical coordination and governance, like AFTLD and all the others. We decided to rebrand this to the African Internet Summit. So once a year, and the next one will be next June.

And of course our next meeting in Khartoum in Sudan will be in a month’s time. You are all welcome to the meeting. I know that some people are a bit worried of traveling to Sudan, but I can assure you that it’s safe. You’re all welcome. And thank you.

Vint Cerf: Vint Cerf. I’m an ARIN Board. First of all, this is such an exciting report. I can’t tell you how satisfying it is to see how much progress you’ve made. And I know Anne-Rachel must be a breath of fresh air to help organize things even better for you.

I had – one question I wanted to get at has to do with connectivity in the region. We know there’s been an increasing amount of fiber terminating around the edges of the continent, and so increasing amounts of capacity are becoming available. Penetrating into the interior is a big challenge, and interconnecting the various networks in Africa is also a challenge.

Can you say a little bit about Internet exchange points and whether or not you’re seeing a significant growth of connectivity by implementing IXPs?

Ernest Byaruhanga: Okay. First of all, the cables are landing on the shores, but many countries actually have gone the extra mile to extend the fiber inland.

And I can say that the eastern part of Africa, the cables so far run all the way up to Kigali in the eastern part of Africa, at least that’s most of the industry that I’m aware of, IXPs are there. They’re operating quite well. We have seen that the statistics on the IXP, on the IXP websites, the stats seem to be increasing.

I would imagine that – I’m not quite sure if that’s directly related to the cable landing, you know, the cable’s landing in and going inland, because traffic on the IXP is really local traffic. So it was more or less meant to be there with respect to whether the cables are coming in or not.

But, yes, we are seeing that IXPs are becoming more and more on the continent. AFRINIC in particular will send in so many requests for specs for IXPs under the critical infrastructure policy.

So I’m not quite sure if that answers your question. But we think a lot of IXPs at least around the continent are coming up.

John Curran: Any other questions?

Bill Woodcock: On the exchange points in Africa, there was a little bit of a lull in exchange points in Africa between about 2004 and 2010. So there have been quite a few new exchange points in the last couple of years largely due to AFRINIC’s increased outreach on that issue and a lot of other international organizations that have been paying more attention to that. There are these sort of tied bottlenecks between the international connectivity and the domestic production. So you can’t base an Internet economic ecosystem entirely on one or the other. So if you resolve one, then it provides room for growth in the other, in both directions.

But the next step, the next bottleneck, I think, in Africa is intraregional connectivity. So it’s easy for you to buy transit from Europe in Africa, and it’s easy now to peer locally, but peering regionally across borders between countries in Africa is still a bit of a challenge due to mostly regulatory issues and some just physical infrastructure build issues. So Tanzania, Uganda, Kenya, and Rwanda are kind of leading in that by having a free-trade zone that does allow ISPs to peer across borders and so forth. But much of the rest of that hasn’t got quite there.

Vint Cerf: I don’t mean to prolong this, but it occurs to me, with regard to what Bill just said, providing regional connectivity is a challenge for a lot of different reasons.

I hope that when the O3B satellite system becomes available in mid-year 2013, that that provides yet another opportunity for local connectivity to be arranged across the region. Because of the relatively low altitude – it’s an 8,000-kilometer system – the round-trip time delays are only 50 milliseconds and the data rates are in the order of gigabit per second. So that can give some regional connectivity that might otherwise be difficult to physically build.

Ernest Byaruhanga: I guess it would depend on the cost. I know that many countries, they’re having initiatives to move fiber inland and interconnect. So the end of the day that would be cheaper than the fiber, then I don’t see why you won’t have regional interconnectivity happen.

And another – also the Africa Union through NEPAD, I think, an umbrella called NEPAD, has also been having initiatives to get regions to interconnect.

So, yes, the government will actually think about that and take it quite seriously.

John Curran: Thank you very much.

Okay. We have one last speaker before our lunch break, and it’s the APNIC update. And I’ll tap Geoff Huston once again to – no. Very good. Come on up, German. I’ll tap German to come up and give that.

RIR Update - APNIC

German Valdez: My name is German Valdez. I’m the external relations program director in APNIC.

This is the list of topics I have for my presentation. No worries. It’s a little long, but I think I can fit it in the following ten minutes or so, speaking slowly.

I will start with a couple of graphics. This graphic shows the delegation rates, one, we started implementation of the final /8 policy. As you can see, we started with a high rate of delegations in the first month of implementations. We have a decrease. But we’re back to steady growth of delegation rates. This data includes the last quarter.

The delegation rates is related to this graphic, which is the annual membership growth. There is a few factors that are contributing to the increasing growth of membership. In fact, we have been setting records of new members are joining APNIC in the last month.

This is good for APNIC in terms of the sustainability of the organizations. On the other hand, we also realize that the ongoing incoming fee from these new members will be reduced in the coming years. So we have this in consideration for the future projections.

IPv4 transfer is a topic that is a passion in the RIR community. We are very well known that we have a transfer policy between ARIN and APNIC. The policy is very clear. The recipient must be able to demonstrate a need for these transfers. In the case of APNIC, we have a transfer fee that applies to this service.

We also have a listing service where we have a list of preapproved recipients. So the sources can contact them before any action is done. This is opt-in anonymous listing. And also while the benefits of the NRO coordination, there is some inter-RIR traffic criteria that was developed by the resource services managers.

We developed a special section in the website, www.apnic.net/transfer, where more details and information can be found.

Training. As you know, in APNIC we have a big team dedicated to deliver training across the region. Most of the content in the APNIC training is related or has something related to IPv6. We’re focusing strongly on IPv6 deployment.

In regards to the eLearning program we developed a new schedule in 2012, which allows more content to be delivered in more sessions. These sessions are delivered through one-hour modules that are broadcasted, fortnightly in three different time zones, which are for the Pacific Islands, the Southeast, and South Asia.

And for the face-to-face trainings, we incorporated more hands-on exercises. Half of the training is presentation. Half is hands-on which we allow it through the incorporation of a training lab. The training lab resembles a topology of an ISP with multiple operation regions.

Well, you know the work that Geoff and George Michaelson is doing through APNIC Labs. They have a real global impact. It’s difficult to summarize all the work, but I try to highlight a few aspects here, like the IPv6 Capability Tracker, which is a Google analytic tool to enable website operators to measure client IPv6 capabilities. There are other activities related to measuring IPv6, like they want to measure end-to-end capability of IPv6 clients per economy and also the IPv6 client capability per autonomous system. There are reports measuring IPv4 free pool address exhaustion.

There’s more information in labs.apnic.net. But also I’d like to invite you to visit the blog, that’s where you can find more insight on what is happening in the mind of George and Geoff, at blabs.apnic.net.

Policy. Well, we have implemented one policy this year as a consequence of the consensus reached in our daily meeting. This is the sparse allocation guidelines for IPv6 resource allocations. It was implemented last August.

And also we reached consensus in two policies discussed in the last meeting in Cambodia, one is about removing the multi-homing requirement for IPv6 portable assignments. And the other was related for the transfer policy in order to bring some consistency with the ARIN criteria, so we extended it 24 months in order to demonstrate the requirements needs for transfer policy.

Also, we’re doing some extra work in editing the policy documentation now, making it more accessible and better structured.

ISIF, which is our Information Society Innovation Fund, is quite similar to what AFRINIC is doing with FIRE. This is work we’ve been doing the last almost five years. This year there is an expansion of this program. IDRC, which is a Canadian research incorporation agency, has increased contributions to this program. And also we have a new member, which is the Swedish Internet agency, has injected or contributed 1.5 million to this program, which allows us to extend as well the awards of the projects that we select up to $30,000 Australian dollars, which is similar value – that’s similar price as the US dollars.

Also we’re continuing with the ISIF awards, which is given to established initiative of $3,000 Australian dollars and travel support to go to the IGF, global IGF in Baku.

APNIC is not exception in the efforts that the RIRs put in on having a better relationship with the public sector. And a specific example is the ITU. Well, APNIC is one of the first Internet organizations to join ITU as a sector member, and that’s back in 2003. The topics where we engaged with the ITU are related to IP address and Internet governance aspects. An example of this is an active contribution through the NRO to the ITU IPv6 Group, which was recently closed as no current concerns identified with existing allocation model.

Also we have a collaboration program with the regional office of the ITU. This is about organizing IPv6 workshops and migration strategies across the region basically in developing countries. We provide the content and the speakers, and the ITU helps us to organize these events with government officers.

We had a very interesting session yesterday about the impact in WCIT and the future of the Internet.

We are doing our task on sharing information and educating the governments in our region, mostly through APT with the Asia-Pacific Telecommunity.

Basically a point of discussion, the first one is the interconnection models supported by the ITRs, and the number misuse in the ITRs. We have produced a set of articles and materials written by Paul Wilson and Geoff Huston where basically we have a single point, and this discussion is that the ITRs have worked well for telephony, but very difficult to translate it into the Internet.

Also we have developed a special section in our website where we are publishing all the content related to this activity, which is apnic.net/wcit.

We recently concluded our member survey. We run this survey every two years. This time we do it a little earlier in order to align these better to our planning process and budget operation.

This is conducted by independent body, which was the Internet Research Centre based in Singapore.

We have very good numbers in terms of the response, almost 70 percent higher than the last survey, from 67 different economies. And the good news; that around 70 percent of the respondents were highly satisfied by APNIC services. We compared that 64 the last survey.

From that survey we have a set of important inputs for the secretariat. This is a list of the top ten priorities where the secretariat should put future planning.

As you can see, resource registration, which includes APNIC Whois database, is at the top of the list, root server deployment in the region, reserve DNS, Internet community, training; they were highly appreciated services that we provide to the community.

We have a section as well in the website where you can review more detailed information, which is apnic.net/survey.

And finally I’d like to extend a warm invitation to join the conference next year. The first one would be in conjunction with APRICOT in Singapore from the 20th of February to the 1st March.

And second standalone meeting will be in Xi’an, China. And this is – perhaps you are not familiar with this city. Perhaps the home of the Terracotta Army will give you a hint. This will be from the 20th to the 30th of August in 2013. That’s all for me.

John Curran: Thank you.

(Applause.)

Any questions for German? No. Okay. We are going to go into our lunch break. You have one hour. Be back here promptly at 1:00. Lunch is outside and up as always. We will see everyone at 1:00. It’s a one-hour lunch.

John Curran: Okay. Very good. At this time we’re going to resume, and we’re going to have a guest speaker from the CRTC, and then after that we’re going to go into our policy block, including consideration of reassignments for third-party Internet access and the ISP private reassignment policy.

So a reminder. When we’re in the policy block, the chair – in this case the vice chair will moderate discussions of the Draft Policies so all can speak and all can be heard.

Please clearly state your name and affiliation each time you’re recognized at the microphone. Comply with the rules and courtesies in the Discussion Guide.

Up first on the agenda is going to be our guest speaker from the Canadian Radio-television Telecommunications Commission.

At the head table I have Scott Bradner, our vice chair, Paul Andersen, Stacy Hughes, Bill Darte, Owen DeLong, and Scott. Dan? Close enough. Sorry. I can never get the head table. I could be looking at pictures and names and I’d get it wrong.

Okay. And so at this time let me invite up Stephen Meyer. Come on up, Stephen. And he’ll give a presentation about IPv4 allocation implications.

Canadian Radio-Television Telecommunications Commission (CRTC) Guest Speaker

Stephen Meyer: Good afternoon, everyone, and thanks for coming after that delicious lunch. I had two slices of pecan pie. So first off I’d like to actually thank ARIN for inviting me down to speak, and in particular to this conference. It’s very interesting coming from the regulatory world where policy is created in a much different way than what we’ve seen here.

So, transcription, my apologies.

And I’d also like to say there are two things that are worth noting right now, so first off is that I feel like I’ve been looking directly into the tubes of the Internet and learning how it all works. So it’s been very instructive. I’ve also never thought in my life I would see live armadillo racing. And I’d like to congratulate the fellow Canadian who came in first on the first round last night, so well done.

For your own information I do have an engineering background, so I take with a grain of salt yesterday I heard some comments around the fact that there’s great concerns when governments want to get involved in policymaking and there’s some cluelessness and whatnot.

I’m not completely clueless. I know enough to know when we want to be involved and when we don’t want to be involved. I’ll let you know that.

I did – in a previous life I was involved in things such as any numbering, network designs, sync clock design, all that sort of thing, so I do speak some of the language here.

So without further ado, let me just talk at the beginning about who are we as in the CRTC, the Canadian Radio-television and Telecommunications Commission. We are in fact pretty much the Canadian equivalent of the FCC in Canada. We regulate the telecommunications and broadcasting sectors, and we use that through a combination of acts that come to us through Parliament.

What I would like to say is that we regulate players and the markets. We do not regulate technologies. It’s a pretty important point, and I’ll come back to that a little bit later as well.

There are a couple of major differences between us and the FCC. Not overly important for this discussion, but, for example, we don’t actually have control over the spectrum. That resides with Industry Canada.

So the mission I put at the bottom there is we seek to ensure that Canadians have access to a world-class telecommunications system.

And why am I here? First and foremost, it’s to learn and interact. I’ve had some great interactions here throughout the last couple of days meeting a lot of you fellow ARIN members. And it’s been very good. We do not have any direct involvement, the CRTC, in IP numbering as we do in telephone numbering. Who knows what the future will hold as enum becomes more important and those sort of issues come to the fore. But at the moment this is definitely not in our realm of expertise or interest in regulating, as it were.

Nonetheless, we do have stakeholders that come to us and do raise issues related to IP numbering, which I guess is why I’m here today.

Also give you a quick brushstroke about the Canadian access market itself. So much like the US, we are characterized by two separate wireline networks. You have the cable companies and their coax cables. And, yes, we do have a smattering of optical fiber, and it’s growing, which is also quite exciting to see and leads to a whole host of other questions going forward.

Also thought it might be of interest to you folks to get an idea of what the size of our market is. So we do have a limited amount of facilities-based players, which does lead to some concerns around the control they could exert into specific markets.

So the chart on the left, the pie, it just shows you the overall market. Can’t read my number. It’s about a $42 billion market overall. And then that red slice is basically showing you that’s how much the Internet portion of the market is worth in Canada.

And on the right-hand side I’ve just attempted to show a little bit what the market looks like split between the incumbent telephone company, the incumbent cable companies, as well as competitors. And the two bars side by side represent the residential market and the business.

So on the furthest right chart you’ll see the residential portion of a competitor is about a 5 percent market share. And that’s really what we’re going to talk about in a little bit, I think, with the proposal that’s in front of you.

So what is the regulatory climate in Canada? In order to foster a competitive market for the provision of Internet services, we, the CRTC, have implemented a wholesale regime from underlying access services.

What do I mean by a wholesale regime? Basically we’ve made it such that incumbent players must allow competitors to use the underlying facilities to provision a competitive service.

So we’ve said we would like to see more competition. The government itself in large has also come to us and said one of the most important things is competition.

We want to see market forces at work, and so that’s where we develop these policies towards making the underlying access available to competitors.

Of course, that leads to having both the incumbent telecos and incumbent cable companies to provide these services. And each have unique offerings, and of course they’re implemented in a much different way.

So these differences have led to both regulatory as well as technical challenges. And, again, I’ll come back to one of the points I made earlier, which is, for our part, the CRTC is technologically neutral. We’re not here to regulate the technologies. We’re not here to tell company X, Y, or Z you have to deploy this particular fashion, this is how you have to do it. That’s not where our interest lies. Our interest lies in insuring, as I said, access to the facilities and to making sure that this runs smoothly.

So we prefer to rely on the industry to address problems as they arise, and that actually is a main reason and a main interest why I’m here to kind of see what happens here, because one of the issues before you is what I would say a technical issue. And so this is a forum where that may be addressed in something that doesn’t involve the government or regulatory policy forum.

So back to the now as far as a synopsis of the specific issue we’re talking about here, so the impact on IP addressing. So the wholesale DSL markets for the incumbent teleco is competitors that manage their own IP address pools. Basically they’re given that pool, and it’s a full Ethernet type of an implementation, so they’re able to assign the addresses where they need to without any problems.

However, under the wholesale DOCSIS offering, so the incumbent teleco’s – cableco’s product, which we’re referring to it as the third-party Internet access in Canada, the competitors generally have to hand over their entire IP address allocations to the incumbent which then distributes it to the network.

Couple of subpoints there. And others can correct me if they want to or add to this. The incumbents are often subnetting their network at the CMTS level or even at the node level in some cases. And this will end up straining IP addresses. So with unequal growth through a network, what I guess is going to happen is that you could lead to stranding and seemingly inefficient IPv4 utilization in that network.

So what is the commission involvement? Where are we in all of this? Well, at this point the shortage of IPv4 addresses at the CMTS locations could lead to DHCP issues and could lead to customers that are unable to even access the Internet through their chosen provider.

If you’ve got a whole one node that’s blown out of IP addresses and you have a new customer that comes on board from the competitor, there’s no way for them to access the network. For us, we’re striving to ensure that the market is competitive and everyone has access to Internet services to the provider of their choice.

So although we’re not directly involved in the numbering, it is in our interests to monitor and to observe this discussion and to find out kind of what kind of solutions can be realized through this kind of a forum.

So we welcome this discussion of the Policy 2012-7 that you’re about to undertake after I’m done speaking, and we’re confident that the parties that are kind of implemented in this will step forward and have their say seen in front of this forum. We look forward to hearing that.

So one of the key questions I feel for ARIN to explore here is: What is the appropriate response? I’m sure what we’ll hear here, there are a number of different things that could happen. There are a number of ways that things could be addressed.

I think what’s important here is that we want to ensure that the v4 space is efficiently being used, but we also want to make sure that the citizens can access the networks as they require it.

So what is my bottom line here? A little bit of motherhood and apple pie. It’s important to bring it all together, I think. Communication networks are obviously a vitally important part of everyone’s lives, Canadians and global citizens. The usage and reliance continues to grow throughout the networks.

However, we do also feel that there is a need to facilitate a competitive market. This is not a uniquely Canadian thing. I mean, we’d like to see – I think the power of the Internet is in the ability for everyone to be connected and to everyone to have their say. And what we see throughout the world is a struggle to make sure that this Internet remains out of the control of central authorities and making sure that it’s available to all.

I think that’s a key point.

So while in Canada we have revenue concentrated in a few major service providers, but we want to make sure that there’s still that other voice in that mix, so the competitors are important to us.

So affordable, competitive rates for Canadians requires a mix of regulation as well as market forces, which includes policies and forums such as ARIN’s here.

Innovation and investment, balanced with the appropriate regulatory regimes, it’s going to ensure that the growth and adoption of services continues to happen.

So as far as our involvement here, we’re going to continue to follow regulatory developments and standard developments as well as anything that’s going on in the community.

Again, I’m very happy to be here, and I hope that we’ll be able to continue participating at least in an observation role all the policies that are happening here.

And we think that the policies that we create as a regulator should be flexible and they should be able to adapt and change over time depending on the needs.

That’s basically all I have to say right now. If anyone has particular questions of me, I’m happy to answer them. Otherwise, I guess we’ll be moving into our discussion of the proposal.

John Curran: Any questions?

Scott Leibrand: Scott Leibrand, ARIN AC. Could you expand a little bit on what your policy process is, your Policy Development Process, how you come to these regulations? The reason I ask is because we have a policy before us that’s depending on your regulations for its reason for being, and there’s a possibility in the discussion shortly that there will be people saying, well, the CRTC regulations should do X or Y. How do you guys set those and what are the timelines and what are the inputs? Can you fill us in?

Stephen Meyer: Sure. I’ll answer it in two parts. First part, which is to say the policy that we created with respect to the establishment of these wholesale services, again, it wasn’t designed to – or intended to cause any issues with v4, honestly. I mean, that wasn’t where we designed it. Policies can develop over a very short period of time or a very long period of time.

The particular policies with respect to Internet access in Canada I would say developed over a fairly long time. And, in fact, you don’t even want to know how long and complex some of the ongoing things are. If you want, there’s a few people in the room that could discuss some of what’s called an R&V process, review and vary.

But essentially the records are formed through – there’s a public record gathering phase where anyone is welcome to write in their comments. And some of the proceedings we have, we have oral public hearings where parties are allowed to come forward and there’s debates and discussions around the issues.

We have periods where we can ask questions known as interrogatories to parties, where they can come in and make submissions and we challenge them on the data.

So it’s really a matter of how complex the issue is. And this one in particular, the issue of wholesale Internet access or broadband at large is such a global issue and of such global importance that it’s really probably one of the more consuming efforts right now at the commission, is to establish what we feel are the correct policies to ensure that there’s competitive access for everyone. I hope that answers the questions.

John Curran: Other questions or follow-up?

Thank you for coming.

(Applause.)

John Curran: Okay. We’re within a minute or two of the start time. So I can at least – I’ll go through the staff introduction, because this is fairly cut and dry.

ARIN-2012-7: Reassignments For Third Party Internet Access (TPIA) Over Cable

John Curran: Staff introduction to Draft Policy 2012-7: Reassignments for Third Party Internet Access (TPIA) Over Cable.

The origin of this was ARIN Proposal 179. Submitted in July 2012. The shepherds, Kevin Blumberg and Cathy Aronson. And the current version of the text is the October 12th version. The text and assessment online – the text and assessment is online and in the Discussion Guide.

The Draft Policy would allow TPIA providers to assign addresses to incumbent cablecos and have ARIN count individual pools as used for the purposes of reviewing an additional address space request from the TPIA provider.

Status at other RIRs. No similar proposals.

Staff concerns or issues. It’s recognized that this would solve a problem that Canadian TPIA providers are currently facing. They have a math problem, effectively, in having assigned space and not being able to show it’s utilized otherwise.

The TPIA provider cannot successfully go back and show that it has utilization if it’s deployed space and then it needs to add additional regions. Under the current incumbent cableco rules, they cannot reprovision any of the underutilized blocks from other market areas, as we understand it. Given that’s the case, this does seem, under the rules as we’ve been told, the only way to solve the problem if they need additional space.

Implementation or resource impact. Minimal. It’s very simple for us to understand. It’s just how we count something as utilized.

Legal assessment. It’s the first of its kind of a policy and deserves comment from a legal perspective. This proposal responds to a single sovereign nation’s regulatory ruling and regards a single named service.

It’s valid for ARIN to make a policy that responds to a single country’s regulatory issue, but the community should take care to consider whether the circumstances in general to make policy is widely applicable as possible.

When doing so, the authors, the community, and counsel should undertake a heightened duty to examine how the policy will impact ARIN members and operators in other countries.

Counsel is not aware of any significant legal issues posed by ARIN members in other countries at this juncture of the proposal.

This enjoyed quite a few posts. 37 posts by 13 people; five in favor, four against.

“This community should facilitate both sides and make sure both sides can adequately conduct their business.”

“This is for the CRTC to solve, not ARIN.”

“Put an expire date on it so the various parties in this stinker know up front they’re on borrowed time. The rest of us expect the incumbent cable companies to fix their tech so it behaves more reasonably.”

That’s some of the types of comments received.

At this time I’m going to ask the shepherds to come up and do the AC introduction to the policy proposal.

Kevin Blumberg: Good afternoon. My name is Kevin Blumberg. I’m on the AC. I’m also an Internet provider in Canada, and I just wanted to give you a very brief bit of history.

I am a small-to-medium service provider in Canada. I don’t do any TPIA. So I have an understanding of what goes on in Canada. But this policy in itself does not affect me one way or the other, and that’s why I think – one of the reasons I was chosen to work on this policy.

So the policy text is right here. I just wanted to very briefly read it, because it has some key points to it that are different from what the original author had intended.

It would add a new section to the cable policy, 4.2.3.8: IP addresses reassigned by an ISP to an incumbent cable operator for use with Third Party Internet Access – and I’ll refer to it as TPIA in the future – will be counted as fully used once they are assigned to equipment by the underlying cable carrier provided they meet the following requirements.

Initial assignments to each piece of hardware represent the smallest subnet reasonably required to deploy service to the customer base served by the hardware.

Additional assignments to each piece of hardware are made only when all previous assignments to that specific piece of hardware are at least 80 percent used and represent a three-month supply.

And this is the limit – or real limited. IP allocations issued through 4.2.3.8 are nontransferrable via Section 8.3 and 8.4 for a period of 36 months. In the case of a Section 8.2 transfer, the IP assignment must be utilized for the same purpose or needs-based justification at a rate consistent with intended use.

Problem statement. Third Party Internet Access Providers are not able to receive subsequent allocations due to existing policy.

Access to incumbent cable networks are regulated in Canada, as we just talked about. And the TPIA provider provides address space to the incumbent to be assigned over the incumbent footprint. The TPIA providers do not have control of those assignments within that footprint.

Once a serving area is full and subsequent allocations – sorry – subsequent allocations are requested, it is likely that the overall utilization rate is well below current policy guidelines.

So the benefits. This policy will help to increase the overall utilization rate of TPIA providers. And I wanted to talk about that, because some of the feedback that I’ve seen on the ARIN PPML as well as in discussion was that because we are giving IPs – or ARIN would be giving IPs in this policy out at a rate lower than the current standard of 50 percent, we’re throwing away IPs.

In fact, when you look at some of the math, you’re actually doing the complete opposite. What you’re doing is – the initial allocation has happened. You have built out the footprint. And with this policy what you’re actually doing is allowing utilization rates to go up over time because you haven’t hit a roadblock where an entire serving area is now not able to have another IP assigned to it.

So over time what you will see is actually the rate increase where they will go above that 50 percent rate. Otherwise they could be at zero percent, one percent, two percent, realize that one serving area, one CMTS is full, but they don’t know in the entire serving area how much has been utilized or where it’s been utilized, so they have to put a stop on that entire area, keeping the utilization down. It will actually increase the utilization of the initial allocation over time.

It resolves immediate issue. This is not something that is theoretical. This is something that is going on with the TPIA providers in Canada right now. They have been turned away. This is an immediate issue.

The other thing in regards to staff comment, we have gone over this, and we feel that it is generic enough to be used across the entire ARIN region.

TPIA in itself is a generic term, and none of the text itself is specific to the Canadian region. And as was said before, it will increase utilization over time.

Drawbacks. The policy would allow for subsequent allocations to TPIA providers below the 50 percent threshold currently in the cable policy. And it adds a requirement that limits the ability to transfer these resources via 8.3 and 8.4.

And let’s move on to the discussion. I didn’t want to add too much to start with. I wanted you all to have your opportunity.

John Curran: We’ll have a discussion now. The vice chair will help moderate the discussion. Microphones are open.

Scott Bradner: Front center mic.

Chris Tacit: My name is Chris Tacit, and today I’m here representing, once again, representing TekSavvy Solutions. You may recall that I was here two years ago at the Atlanta meeting for my very first ARIN meeting raising this very issue.

And since that time, TekSavvy, along with many other Canadian ISPs, have worked very diligently on this matter, coming at it from many different perspectives.

And at the end of the day we feel that this is the best place to resolve this issue. But we are very much in favor of this particular policy. And I just want to give you a one-minute snapshot of the background in Canada to put this in context for those of you who are less familiar with the Canadian environment.

First of all, a little bit about TekSavvy itself. It is very much a – its ethos is very much a part of the Canadian – of the Internet way of thinking. The actual name “TekSavvy” came from the fact that its core base of users were high-powered, knowledgeable, technology-literate people who rely on the Internet and were involved in its development.

So we very much – when we’re asking for this assistance, we’re very much doing it in the spirit of being members of this community.

The problem that is faced in Canada is that without this relief, there will be increasing market failure. The reality in the Canadian marketplace, as you heard, is that there’s only about five to six percent competition from nonincumbents in the provision of Internet access services.

The growth now is very much on the cable side. DSL is much more stagnant now, and because of the higher speeds facilitated by cable, that’s where all the growth is taking place.

So if Canadian ISPs can’t get access to grow – to IP addresses to grow that base, it will artificially suppress the growth of competition in Canada.

As you’ve just heard, this is more than a theoretical concern. TekSavvy, the company that I’m here representing today, has actually had to stop selling in certain serving areas for limited periods of time when it ran into IP allocation problems, until its overall utilization increased above the necessary thresholds to obtain new allocation.

So this is a real problem that really exists. Allowing this policy to go through will allow for more efficient IP addresses overall. It will actually allow providers to provision the fastest growing areas. It will also allow them to open new areas that they wouldn’t otherwise be able to open while they wait for new allocations.

And very significantly, because we will be able to get small allocations of small IP addresses to deal with specific serving area problems and CMTS issues, we’re actually not going to suddenly get big steps of allocations at perhaps less frequent times. So in a way we’re going to be using those allocations much more efficiently along the way as we develop the markets.

It removes bottlenecks to competition, as I said. As you heard this morning, we have to rely often, and we want to rely where necessary, on the CRTC for relief.

But as you heard this morning from our speaker, the CRTC is not a technical regulator. And so it’s a real barrier when we try and get this problem resolved in the Canadian regulatory forum. It’s not a very efficient process for dealing with this issue.

The commission very much prefers that industry get together and solve these technical issues on their own. We have not been able to do so with the cable incumbents in Canada, therefore we are turning to this community.

The commission has certainly been helpful on a complaints basis, but that creates delays, problems, and is a very inefficient way to deal with this issue.

It has basically strived to get industry consensus, but, as I say, that consensus has not been forthcoming.

The other concern we have at TekSavvy is, because we’re very much part of the Internet community, we really want to avoid situations where government policies and regulations have to unduly interfere with technological developments in the Internet.

And if we can’t come up with a solution in this community, then in order to prevent market failure in Canada, that may be become necessary. And that’s quite contrary to what we’re trying to achieve generally and what the bottom-up multistakeholder model for Internet governance is all about.

It’s something that TekSavvy believes in very strongly.

So for all of these reasons, I urge you all to vote in favor of this policy today. Thank you.

Scott Bradner: I assume from what you said you support the proposal.

Bill Darte: I don’t normally speak in support or against policy proposals, but I speak in support of this one because I think we’re a community of at least two-dozen economies, and if we can’t adjust our methods of policy development to account for some of the idiosyncrasies of those economies and try to genericize everything we do to the nth end, I think we make a failure in that.

So I think this seems to be justified to me, in my own mind. I’ve been convinced that it’s a technical problem that we can in fact deal with, and so I support it.

Scott Bradner: Center rear mic.

Ron Grant: Ron Grant, Skyway West. I’m in favor of this proposal. I’m the chief engineer of a service provider in Vancouver, Canada. And I say Vancouver because we’re a cable, but we are a TPIA reseller, and we can’t become a cable provider in Victoria or Edmonton or Calgary or Kelowna, some of the other serving areas, because, well, we got an allocation for Vancouver, and that was it.

So we’re being basically artificially kept out of a market because we simply can’t give telecommunications any address space for those other markets.

We’ve tried a variety of technical suggestions that are just simply not going to happen for various policy reasons, and we wound up with the /19, basically being given an allocation to set up the TPIA.

But the point I’d like to make is that this policy from a technical standpoint is very similar to the one we were discussing earlier today with regards to the v6 subsequent allocations in situations where a maximum – where your largest site is – has determined that you’re overutilizing in some of your smaller sites. And it’s a very similar sort of rationale, because in our region we have TPIA coverage from Whistler on through to Abbotsford, which is an area of about 200 miles, of which Vancouver is in the center.

And the large proportion of that, the Vancouver customers, are of course probably going to be hitting their maximum fairly quickly, whereas all of the outlying rural areas are going to be sitting there having two or three customers in a – out of a /26 or something.

Additionally, the provider uses a common subnetting scheme for all backbone and hub site interconnects, including the P2P connection between ourselves and their point of interconnect.

So there’s an awful lot of waste on those networks. And I believe we could probably show that even if we sold every single possible serving area, that we would still be short of the 80 percent utilization just simply due to waste due to this policy.

So that’s why I’m in favor of this policy. Thank you.

Scott Bradner: Thank you. Center front mic.

Andrew Dul: Andrew Dul, Cascadeo, also known as multiple discrete network guy. So this is a recurring issue we have in trying to find the right balance when different areas grow at different times.

I’m in support of this policy with one caveat.

My understanding of the policy now, and maybe I don’t necessarily know, is that this policy would allow the incumbent carrier to assign a block to a serving site when there are zero customers currently in that serving site. And that seems a little bit extreme to me to preassign address space where there are no customers.

If someone would like to correct that assumption for me and state that that is not the policy, then that would be okay.

But I’m not in favor of that specific part of it. Otherwise, I believe, as long as we at least have one customer in each serving site, that an appropriate subnet can be provisioned.

Peter Rocca: Peter Rocca, Start Communications. We’re an ISP in Canada. I’m also the regulatory chair for CNOC, the Canadian Network Operators Consortium, representing 24 independent ISPs in Canada.

So I can speak to that, and you are correct that the initial allocation does allocate a /29 to every node, including nodes that at the time of initial allocation have no customers on it.

Scott Bradner: Can you get closer to the microphone? Talk to the mic, not to him.

Andrew Dul: Sorry. So it is correct that the initial allocation will go to every node in the network, every node that potentially would have a customer. Generally speaking, it’s the smallest available subnet that can be put on that.

The reason is is for that initial allocation that you don’t know where the customers are going to be coming, and the TPIA or the cable providers generally have a three-month lead time to addressing individual nodes.

So if they were to number a node on demand, you’d be looking at a three-month lead time to be able to bring back up that customer on that node.

Scott Bradner: You have an answer to your question? Do you want to further comment?

Peter Rocca: I appreciate the comment, and understanding – I’m not understanding the three-month part. That seems excessively long to provision a subnet. If you said a week, I would not have a problem with that.

But, anyway, I still support the policy but still have this same reservation that we are assigning address space to places where there is no demand.

Kevin Blumberg: Just to also clarify a little bit. I think one of the hardest things is realizing this is not a commercial negotiation of a best-of-class service. This is a regulated environment. And when we were talking earlier, one of the things that came out was the question in regards to if there’s a policy change within the CRTC, how long could that be. There have been policies that have taken years to go through between review and varies. It’s not always the case. Sometimes it is quicker.

But it is, again, not – it is done to the letter of the law. Not to what we as technology people would necessarily expect to be reasonable.

Peter Rocca: So one other thing just to add to that, we have to remember this isn’t about the initial allocation; that this is about the subsequent. And the subsequent allocation is not being allocated to any nodes that have zero customers; they’re only being allocated in very small portions to the hot spots.

And like Kevin mentioned earlier, it really helps increase that utilization of that initial allocation. So that node that might have zero customers on it today or at the time of the initial allocation, the subsequent allocation that went to area X allows future growth in area Y because of that – because of continued growth across the network.

Scott Bradner: Center rear mic.

Michael Sinatra: Michael Sinatra, ESnet. ESnet is not a Canadian ISP. I do not work for Canada or any Canadian ISPs.

I’m in support of this policy. And I have sort of an open question, which I know there’s still some people waiting to follow up on that last one, but my open question is: What can the CRTC do to fix this? It doesn’t actually seem like there’s an easy way to do it without completely dismantling the policy they have and effectively deregulating this space from the government perspective. But that would reregulate it from the perspective of the incumbents.

So seems like if you’re going to have this policy where you’re going to say the incumbents have to provide this infrastructure, they’re going to need a policy like what we’re proposing here in ARIN.

That’s why I support the policy. I don’t see any other way around it. Thanks.

Scott Bradner: Thank you for your point, but I don’t think ARIN should get in the business of discussing what CRTC should or shouldn’t do or could or couldn’t do. We should be discussing the policy in front of us.

We have a remote participant comment?

Paul Andersen: We do, from Joe Maimon of CHL. He has a statement and a question.

His statement is that he is opposed to the policy as written: “I am not in favor of numbering requirements being shaped by regulations.”

And he asks a question: “Is there any idea or projection of the extent that the allocations that would be allowed under this policy?”

Is there any – do staff have any idea what kind of sizes have been asked?

Scott Bradner: Leslie, do you have any – John?

John Curran: So understand that this addresses the additional allocation that occurs when a provider had an initial allocation and then managed to get a hot spot, needs an additional one. So we have to actually forecast something that’s very difficult, what providers ran out of space in what POPs on their initial allocation based on their growth. It’s not something within the capability of staff to forecast. It’s something we’ll be able to trend once we see this and see the request.

But, no, I do not know how to hedge the size or quantity of these requests coming in.

Scott Bradner: Center rear mic.

Bill Sandiford: Bill Sandiford, Telnet Communications and the ARIN AC. I was the original author of this. And as full disclosure, I run an ISP as well, as a lot of you already know, but we don’t do TPIA either. However, I was approached by several people who are aware of my participation with ARIN to see how I could help them.

Couple of comments to one of Andrew’s questions earlier about the three-month thing. The reality is, Andrew, that we – the ISPs in Canada think that three months is a long time for subnetting as well, too, but unfortunately that’s not something that’s under our control. The cable companies have their policies and their procedures that they follow when they subnet a new area of their network, and we have no choice but to follow through with their policies and procedures. We can’t force them to change those policies and procedures, and I don’t think the CRTC can or will or should either. Although we think three months is extensive. We always tend to gripe about it.

The other thing I wanted to mention, too, and I’ll put people on the spot, I had a lot of people come up to me over the last couple of days that they thought they were in support of this policy but they just really weren’t sure and they wanted some more people to talk to it.

And I notice that we’ve got a record number of Canadian ISPs it seems here, so I want to stand some people up. Gabe, stand up for a sec. Gabe is also from TekSavvy, so if you have some questions, Gabe can answer. Dennis? Dennis is from Distributel, another one of our large TPIA providers. You’ve heard from Pete Rocca and Chris Tacit. Any of us are happy to take the time to sit down with anybody that wants to better understand the problems.

What we’ve tried to do over the past two years to resolve it without having to come to ARIN for a policy change – I mean, we spent considerable amount of time trying to negotiate with the cable companies.

In fairness, I use “cable company” as a generic term. There have been some cable companies that have been much easier to work with in Canada than others. Some are represented here, so I don’t want to try to label –

Scott Bradner: Speak a touch slower.

Bill Sandiford: Sorry. I don’t want to try to label all cable companies as bad actors. That’s not what I’m trying to do here. There are some who have been much better than others.

But we’re here and we’re very eager to talk to anybody who has some challenges with this and would like to learn more. And obviously I support the policy.

Scott Bradner: Thank you.

Matt Pounsett: Matt Pounsett, Afilias. So Afilias is not an access provider. This doesn’t even affect me personally since I’m a DSL user, not a cable user.

But I support this policy. The problem that this is here to solve is a real problem in the Canadian market. And since this can’t be solved really in any other forum, I see no reason for ARIN not to – for the ARIN community not to solve this problem here, particularly when there don’t seem to be any serious negative side effects to the proposal.

Thanks.

Scott Bradner: Another remote participant?

Paul Andersen: Michael Greb of Linode. He says he is in favor, but he would like a deadline added to the policy so that once information is available, like the extent of allocations in this policy, the policy would be automatically revisited.

Scott Bradner: Center front mic.

Peter Rocca: Peter Rocca again, just to make a comment in regards to the question about the trending or what we kind of expect on this.

Scott Bradner: And I assume that you’re going to say whether you support –

Peter Rocca: I’m sorry, I do support this policy.

I think you’ll find the trending will actually taper off, because as the initial allocation becomes more effectively utilized, ISPs that are using TPIA will be able to apply under the standard cable policy and would not need to use this policy here.

Joe Provo: Joe Provo, Google. I’m schizophrenic on this policy. It is in my previous life as operating at a competitive MSO in the US I appreciate the problems of doing line sharing over the cable plant and therefore support it from that perspective, the addressing complexities.

I just have an allergy to language that is highly reliant on a current technology being enshrined in a policy that certainly could apply to future media that is broadcast-based and has similar addressing properties for the downstream customers.

Scott Bradner: Thank you. Center rear mic.

John Springer: I’m John Springer with Inland Telephone. I’m not a Canadian ISP. I support the policy. A lot of the objections that I’ve heard in conversations around seem to be focusing on the idea that this is some kind of corner case. I don’t think a country is a corner case.

Rob Seastrom: Rob Seastrom, Time Warner Cable.

Scott Bradner: Welcome back, Rob.

(Applause.)

Scott Bradner: I trust you’re doing well.

Rob Seastrom: I am, thank you.

Scott Bradner: But do you support the proposal?

Rob Seastrom: Actually, I do. Joe brought up an interesting point, which is that this is a problem that could apply to different other access technologies.

I’ve been burned by this once in the past. Many moons ago I worked for a company that was a Canadian ISP, and we sold DSL over Bell’s infrastructure. And we tried to sell over cable plant as well, but that was back in the days before cable bundles became prevalent.

And in those days it was not one address pool per CMTS. It was one address pool per interface per CMTS. And that made the problem exponentially worse.

Fundamentally, there are two problems we’re addressing here. One is the regulatory aspect, but the other is one that we have been married to since time immemorial. And that is the powers of two problem; that there is always a point at which to add one more address, you’re doubling the address.

So I support this proposal. Thank you.

Ron Grant: Ron Grant, Skyway West. Again, I support the proposal. And I just wanted to respond to the gentleman who asked about the technological aspects as well as the fellow who asked about the time limitation.

I believe that this policy will become irrelevant the moment that the Third Party Internet Access providers, the incumbents, are able to support v6 for us over the network.

I think at that point you can take this policy and throw it away because we won’t need it anymore. Thank you.

Scott Bradner: Center rear mic.

Dennis Hayes: Dennis Hayes, Distributel Communications. I support this policy. We’re one of the TPIA resellers in Canada as well. We operate in four of the incumbent territories. We also sell DSL services through the resale market as well.

It does pose a large challenge for us, especially when we have areas that we recently opened up. And we’re growing largely in certain markets but just entering in the other markets. It does cause us concern on how we’ll be able to serve those markets as we need more addresses.

We’ve had to slow down sales and actually stop some sales, too, in some smaller regions to continue getting our address space back.

So we really would like to see this policy passed. Thank you.

Cathy Aronson: Cathy Aronson, author of the original cable policy a hundred years ago. I support this proposal. This problem exists even if you were a brand-new regular cable provider, right? Like if you were putting out 27 new markets, you’d have the same problem as the TPIA guys do.

It’s just difficult. Used to be harder because you could only assign a /24, and I think that was the smallest, and you could only assign 26 of them, or something insane, to the Motorola, so it was even worse in the days that I was doing this.

But, anyway, I just think – and, oh, my other point was that we have already done specific proposals for other economies and that I don’t see why this would be any different.

Scott Bradner: Thank you. Any other comments? Microphones are still open.

Scott Beuker: Scott Beuker, Shaw Communications. I’ll speak on behalf of the cable ISPs in Canada.

This is a real problem, and it’s a good idea to solve it. There’s no objection to that. But I am opposed to this proposal as written, basically because of the ambiguity of the first bullet point. It basically gives carte blanche for the ISP to, as I can tell, take a ridiculously – the third-party ISP, pardon me, to take a ridiculously large swath of IPv4 space right now immediately before exhaustion.

Now, I’ll totally set aside the point that we’ll all be deploying NAT for IPv4 very soon, and the TPIA providers could probably do this immediately.

But, like I say, if we acknowledge it to be a very real problem, the important thing to note here is that if the TPIA provider is putting a minimum assignment on every router, each one of them by piggybacking on a very large ISP’s infrastructure is going to be – let’s say that very small subnet is a /26, /27, /28, I can’t recall what it is, multiply that by some very large ISP’s infrastructure, literally thousands of routers, and they’re immediately going to justify a /28 on times 3,000 routers for themselves, when they actually in reality only have hundreds of customers, if they’re lucky, maybe they only have a dozen when they’re starting up. There are many of these because it’s so easy for them to jump into the market.

So I’m not trying to shoot down the idea. I certainly acknowledge that there is a problem here. But that first bullet point needs some kind of check and balance that limits how much unused space they can have at any one time.

I’ll make an off-the-cuff suggestion that it should state they can only have – they must have at least 25 percent or 20 percent of their total IP space utilized by customers before they can go back for more. And that might sound ridiculously low, but I bet you a lot of them would have a lot of trouble meeting that within the next year without going into too much detail.

Kevin Blumberg: So my understanding, and we can confirm with staff, is that the TPIA providers are not having any trouble getting the initial allocations to build out the footprint. And this is specific or most importantly around the additional allocations.

The main point of that first bullet was the smallest subnet reasonably required to deploy. So if an additional CMTS goes up in a serving area and the request from the incumbent is to put IP onto that, it will be the smallest reasonable.

The bulk of the IPs that you were referring to are covered under other policy.

Scott Beuker: To clarify, what does “smallest reasonable” mean to you?

Kevin Blumberg: With four different incumbents, each with their own issues, and having talked to some of them, that could be a /27 –

Scott Beuker: Ballpark.

Kevin Blumberg: /27 to a /29, depending on the incumbent, is what I have heard.

Scott Beuker: So if I could respond to the other point. I have no doubt that they’re not having any difficulty getting their initial assignment. But I also have no doubt that they’re almost immediately – because they can so rapidly expand their footprint since they’re not actually really building infrastructure here, they’re just turning it up, go back, go back, go back to ARIN very rapidly because all they have to do is make the assignment, and under this, boom, it’s now utilized, go back for more, and they could instantly have a very large footprint with very few customers.

So I’m not sure you’ve actually addressed my problem here with the ambiguity of the statement.

And I’ll reiterate my suggestion. Just put a very small, very simple check or balance that says they just have to utilize 20 percent of it.

It’s not asking a lot, is it? But I think it would keep things reasonable rather than we find ourselves with a couple of ISPs in Canada who have massive swaths of IP space and they’re only actually utilizing three percent of it.

John Curran: I want to be very clear. The initial assignment situation of TPIA resellers obtaining address space and allocating that, assigning that to the incumbent cable operators and doing their – that’s not part of the policy. That is an existing situation that will utilize address space and allow them to be in business.

So what all this is saying is that at the point in time when they need an additional address space for a specific piece of hardware that is utilized, that is at 80 percent, okay, so there’s customers on this particular device and I need more address space, they can’t get more address space for that particular 80 percent utilized piece of equipment because they can’t count the entire base they have because it has a lot of less utilized.

So they’re not going to be able to sell customers on that piece of utilized hardware. It’s an allocation they’ve 80 percent utilized. There is a check in there to ensure that we’re only assigning address space to a place that has been utilized.

What this does is relieve them from the obligation that all the other pieces of hardware are equally successful. Got it?

Scott Beuker: Yeah, I understand.

Kevin Blumberg: Having read the text, I think the most appropriate change, and to run this by you, is actually just take the word “initial” out of it, because really that is actually not really what we’re talking about. Assignments, subsequent assignments to each piece of hardware represent the smallest. And those subsequent assignments would need to be at 80 percent to be able to justify.

Scott Beuker: I will still hang on to the assertion that there needs to be some other piece to this that says that their overall utilization has to meet something reasonable, 20 percent. That’s a really low watermark that we’ve never seen in any other pieces of the policy. Why can’t they meet that overall? If they’re not meeting that overall, they’re doing something weird.

Kevin Blumberg: Are you referring to 20 percent overall for the entire serving area, 20 percent overall for a –

Scott Beuker: For their entire IP assignment total.

Kevin Blumberg: That’s not something I can answer.

Scott Bradner: Sounds like something that the AC is remitted to work on this to be part of the discussion.

We have a remote participant.

Paul Andersen: Yes. Joe Maimon of CHL makes a statement saying: Fairly shortly technology that is wasteful with IPv4 will become more obsolete than it is already. ARIN should not be solving legacy technology challenges that exist in large part due to regulatory bodies that ARIN may not be properly participating or represented in.

Scott Bradner: I think it’s probably the center front mic.

Leif Sawyer: Leif Sawyer, GCI Alaska. I support this policy for our northern neighbors. It also affects some of our communities where we have native corporations which do TPIA access. So absolutely I want to see something like this go through.

I also support the change of striking “initial” in the first bullet point and replacing with “subsequent.”

Scott Bradner: I think center center mic.

Bill Sandiford: Bill Sandiford, Telnet Communications, ARIN AC. Still in favor of the policy or in support of the policy. Just wanted to respond to a couple points I’ve heard. Number one, earlier when we spoke about the size and how much address space this could take up, I remind everybody that Canada, as the nation that is my home and I love, is only 35 million people, which is smaller than the state of California. So we’re relatively small in the grand scope of things.

With regards to the question earlier, with my friend from Shaw asking what was a reasonable assignment, I would actually turn that question back to them, because it is in fact the cable companies that are determining the size of these allocations, some of these assignments.

The third-party Internet providers don’t actually have the ability to choose the size of these assignments. The way it works is that we are required to provide the cable companies with one large block, and they take that block and divide it up as they see fit and distribute it throughout their network.

We’re happy to go smaller if they’re happy to go smaller. We don’t make the decision today; it’s them that makes the decision.

Another thing to point out, once again, the policy is mainly meant to address the subsequent allocations, and we don’t renumber the entire footprint again with the subsequent allocation.

The subsequent allocations that are going to be requested under this policy are not going to be large swaths, as was suggested. They’re likely to be much smaller, because they’re allocations that are being requested so that we can renumber only those areas that require the relief. We’re not looking to renumber entire large footprints again.

So I just wanted to clarify a few of those bits.

John Springer: John Springer, Inland Telephone. I found it a little odd that policy designed to provide relief to a problem for people that can’t get addresses should be criticized on the basis that it’s going to result in a situation where the aggrieved party is going to get too many addresses. So I’m not sure I buy that.

Scott Bradner: You didn’t state whether you support the proposal.

John Springer: I still support it.

Scott Bradner: Thank you. Center front.

Scott Leibrand: Scott Leibrand, Limelight Networks. I support the proposal. I believe it is a very reasonable solution to a very real problem.

I would take issue to the suggestion that we need to add substantive additional checks on this. I believe those, particularly the 20 percent suggestion that was made, would come with a number of potential conflicts of interest between the different parties involved and would make the game theory of this much more complicated.

I don’t want to go there. And I guess I should put my AC hat on there. I don’t want to be in the situation of trying to do things that would require consideration of the different competitive interests of different people in the community.

What we need to be doing is making sure that everyone can get the addresses they need. And so I would suggest that we should pass this as is.

I also would point out that if we are going to make additional substantive changes, that that’s going to require this to go back to another meeting in six months. And this is a time-sensitive issue. So I would suggest that if this is better than the current situation and not going to break the Internet, which I believe are both true, we should go ahead and pass it as is or with like minor one-word changes or something that the AC can figure out.

But speaking a little more slowly, I believe that the community should consider whether this is better than current and not going to break the Internet, and, if so, tell the AC you’d like us to move it forward this session.

Scott Bradner: Would you consider the removal of the “initial,” the word “initial,” in the second bullet?

Scott Leibrand: I would consider that extremely minor.

Scott Bradner: Thank you. Center rear mic.

Chris Grundemann: Chris Grundemann, ARIN AC. Neither speaking for nor against the policy at the moment. I just want to clarify what I think I’ve been hearing regarding the specific wording of the current policy.

The first bullet point is talking about – in my understanding, I’m stating, is the first bullet point is absolutely talking about initial assignments. It may not be the requirements to get an initial assignment, but it is describing what you must do with your initial assignment in order to come back and get a subsequent assignment, if I’m reading this correctly.

John Curran: So remember this policy could be used multiple times. Someone could be in 15 locations. Location one and seven both get heavily utilized. They come back for initial assignments. They then – two months later those two locations are going great, and they come back for more additional assignments for those two locations.

If it’s initial assignments, then it only really matters how they allocated their first spread, and if it’s all assignments, or if the word “initial” is dropped, then it means that both that initial and the subsequent ones were the smallest necessary to serve the customer base.

I don’t think it matters either way, because if they’ve gotten additional assignments on those blocks because they were at 80 percent, the additional assignments will still meet this criteria.

So it makes sense either way. It can be – it’s totally how you want it applied. I don’t think it will ever affect an actual carrier.

Chris Grundemann: To be clear, the way I read it, there are two separate requirements.

John Curran: Right.

Chris Grundemann: First one is that you spread this as thinly as possible based on the customers attached to each piece of hardware, and the second one is you have 80 percent of the ones you’re requesting more space for.

John Curran: Correct. The removal of the word “initial assignments” actually makes it more difficult. I know people might not see that. But if you drop the word “initial assignments” – initial assignments only applies to that first initial assignment you got from ARIN. If you did it in that way, your subsequent – you can now come back to this policy whenever your particular serving area has hit its limit. If the word “initial” is out of the first block, it implies both initial and additional assignments meet the smallest subnet reasonably required. And they probably do. But I’m just saying removing the additional word isn’t material to this policy.

Chris Grundemann: Fair enough. Thank you.

Scott Bradner: Center front mic.

Chris Tacit: Chris Tacit on behalf of TekSavvy. We still support the policy as written. I only wanted to point out that the intervention of our friend from Shaw illustrates more vividly than anything I can say why we need this policy.

Scott Bradner: Center rear mic.

Heather Schiller: Heather Schiller, Verizon. Not Canadian. And in support of the policy. And I would say that if the concern is about the inefficiency of utilization on the initial allocation, then the – if the cable providers are concerned about that, then it sounds to me like the cable providers can assist their third-party providers by doing just-in-time allocations or being – not deploying the entire block across the entire network or – sounds like – and not taking three months to do the allocation.

Sounds like the cable providers themselves can help increase that efficiency, if that is their goal.

Scott Bradner: Thank you. Any more comments?

Gabriel Blanchard: Gabriel Blanchard from TekSavvy. I’m sorry, I don’t remember your name, but I couldn’t agree more with what you said. We’re forced to sign essentially whatever block the cablecos are telling us, and we have no say whatsoever in whatever assignments they gave them. It would greatly help us.

Ron Grant: Ron Grant, Skyway West, still in favor. I agree with the guy in the back, but I had another point. The /19 that we were originally given was turned over to our TPIA provider, and we were told that they had a minimum subnet size of /26, just to clarify the /27, /28, /29 thing. So that’s the data point.

Scott Bradner: Thank you. Last call for comments. Anybody who wants to comment, please go to the microphones.

No more pending remotes. Now it’s time to call the question. I’ll ask who is in favor and who is opposed to this proposal as is.

Counters ready? Okay.

If you support this proposal as is, please raise your hand. All right. If you oppose this proposal as written, please raise your hand.

I’m waiting for signal of them counting none, but they haven’t signaled that they’re done yet. Now we’ll wait for the results.

Okay. The number of people in the room is 135. In favor, 47; against, one. This information will be passed on to the Advisory Council for their deep consideration. Thank you.

John Curran: Amazingly we have more policy. So we have one more policy proposal, and we have about 20 minutes on the schedule for this block.

I would like to now bring up Policy Proposal 180, ISP private reassignment, and I’ll go through the history of this policy proposal and then we’ll have the AC do their presentation.

ARIN-Prop-180 Isp Private Reassignment

John Curran: This is not a Draft Policy. It’s not yet being discussed for adoption because it’s not – it was not deemed ready to advance by the AC. But they want to discuss it to get perspective.

So it will not be going out for last call. You will get to see this at our next meeting.

The origin. Proposal 180, August 2012. The shepherd, Rob Seastrom. Current version, 16 August 2012. The text is online and in the Discussion Guide.

Status at other RIRs. APNIC policy. Organizations that receive an allocation from APNIC can choose whether or not their customer assignment registrations should be publicly available. If the organization does not indicate a choice, or it chooses to hide its customer assignment registrations, then those records will not be visible in the public Whois database. Whois queries on those records will return details of the allocation.

So that concludes the introduction. And I’d like to have the shepherds come up – I guess, Scott, you’re going to do it? Okay – to do the AC presentation.

Scott Leibrand: I spoke with Yi, who is the author on this. He asked me to give a brief introduction to this idea. At this point, the policy is more of a skeleton of what he wants to do, but the idea is pretty well defined, and I’d like to talk about that and get some feedback from the community and open some discussion. He’s also here for any questions that anyone might have.

So the rationale here, the reason that there’s a policy change that’s needed, is that there is some demand from ISPs who want to make reassignments and want to keep those private and confidential.

Under current ARIN policy, the only way to do that is to create some sort of a legal alias, shell company, or some other DBA, maybe depends on what level of confidentiality you’re looking for, and to then do the reassignment to that legal entity.

That obviously comes with cost and complexities. The thought behind this proposal is that if the reassignments could be made private, the ISP, which is the one that’s responsible for the entire allocation from ARIN, would be listed in the Whois as the responsible party, and that seems to make sense at some level because the ISP is the one that has the direct relationship with ARIN. I said LSA; it’s supposed to be RSA. The RSA with ARIN is between the ISP and ARIN. There’s no direct relationship with the downstream.

So in certain circumstances it makes more sense to contact an ISP about reassignment than it is to contact the downstream of the legal entity.

It’s worth pointing out there if you have a legal entity that’s nothing but a shell company, you’re going to have a hard time contacting them any way. There’s not a whole lot of point in putting that kind of information into the Whois.

So the red represents the stuff that isn’t going to change. This is direct allocation from ARIN to the LIRs, to the ISPs. Those involve signed RSAs. They currently require and would continue to require mandatory registration of full details of the allocation.

What is being proposed is that we could optionally make reassignments from the LIRs to their downstreams, still visible in Whois, but not including all of the organizational contact details.

So here’s some additional breakdown of how that would work. So the current thinking in my discussions with Yi is that this most relevantly applies to single-home downstreams, because there’s some considerations around multi-homing and having to know who has a block that you’re going to route. We’ll talk about that in a minute.

The idea is just to mark that in the Whois as private. Again, this only deals with reassignments from ISPs, doesn’t deal with anything that ARIN assigns or allocates directly.

This is different from the residential privacy policy that you guys may be familiar with. This is not hiding all the facts of the reassignment.

Everything is still there in Whois as in this is a /26 reassignment. What’s hidden is simply the organization details. You can still see this /26 is a /26. It is reassigned to a downstream. You’re just not going to see who that is and their contact information.

And, of course, that information is still used for any usage calculations, all the stuff that Whois does in terms of making it easy to keep track of information for future allocations is unchanged.

The intention is to allow law enforcement to go ahead and request information either from ARIN or from the ISP, if they require contact information for the downstream.

So as was mentioned in the slide, APNIC has a policy that already allows this. They’ve had that since 2003.

And the idea is very much modeled on the success, perceived success, of that model in the APNIC region.

There’s some statistics here. 22.2 percent of the records in their database have been marked private. One thing I noticed in the introductory slides that I didn’t realize before, APNIC seems to have a default of if the information is not marked public then it’s marked private.

The intention here would actually be the other way around. You have to go through an extra step to mark this private. You still have to provide all the same information to ARIN. It’s not any easier to mark things private. It’s actually an additional step.

So that would – for people who just go with the default, would leave the information public as it is now.

So I as an AC member have some open questions on this. And I think the main reason that we’re doing this presentation is to get input from the community on how this should look if we should move forward at all.

So one open question would be if the – if there’s bulk Whois information being provided to private entities, my assumption would be that that would – these records marked private would be marked private in that as well.

If law enforcement is getting bulk Whois information for their purposes, one possible way of making this not have a negative impact on their activities would be to allow them to get a bulk copy of Whois under various NDA and other confidentiality constraints that does include the details.

So I would love to hear from the community if you think that continuing to provide this information to law enforcement is important, if that would be a way to do that.

The other – the second question that I have here is regarding multi-homing. So one of the considerations about having information in the public Whois is if I have a /24 I got from my ISP and I go to another ISP for purposes of routing that with BGP, they would like to be able to look that up in the Whois and see that it really is reassigned to me and not to somebody else.

My suggestion is we might want to have this only allowed for single-homed reassignments and continue to require multi-homed assignments be visible in the public Whois with contact information to preserve the integrity of that process of validating multi-homing.

There’s obviously some implications with regard to RPKI and some other things as well that would lead us to go down the same route.

Third question would be do we need to somehow limit the scope of how many reassignments can be private. We saw the statistics for the APNIC region.

One concern that I’ve heard is that certain ISPs might just say all of my reassignments are private, just because they want to differentiate themselves in the marketplace for that or something. Do we as a community think that that’s appropriate? And, if not, what would we do in the policy to prevent that from occurring? Would we set an upper bound on the percentage of any ISP reassignments that could be private or something along those lines?

And then the final question is: Do you think this is something that the AC should be working on? Do you support or oppose the general concept being proposed here?

So I’d like to open it up for questions and get some discussion going.

Stacy Hughes: Is Bobby in the room? I’m just curious, because for private information, or any information, really, that’s not available publicly, we require a subpoena. So how long does that take to generate?

Bobby Flaim: It can take a while. It depends on what the case is, who the prosecutor is, and how fast that’s going to come out.

So if this is going to require additional subpoenas, that’s definitely going to slow cases down. And I don’t mean to jump the line. I was going to get in line to give my comments, but I guess I’ll give them to you now in relation to what you just asked.

This is kind of what we as international law enforcement just – this is Bobby Flaim from the FBI, just so you know.

As international enforcement, the reason why we review the Whois and an open and accurate Whois as kind of an integral triage tool for our investigations is that that’s kind of where it can start off.

So once you put IP addresses or domain names on the domain name side under a proxy system, which is kind of what this is, or private system, you’re adding another layer to our cases.

And with electronic and digital cases, or any case right now that relates to obviously IP addresses, time is of the essence. So this kind of would from what I’m seeing – and that’s why I’m hoping a discussion would come out of it – it seems like it would create more of a hindrance and more of a time problem for us.

The other thing is for ISPs and ARIN, do you want to receive more subpoenas? Do you want to be burdened administratively with more work?

So that’s also a big issue. And another issue is it’s okay for me as the FBI – you know, you mentioned bulk Whois. I don’t see a real problem with that. But there’s about 18- to 20,000 law enforcement agencies in the United States alone, so do you want to sign 18- to 20,000 NDAs with all of them. And we don’t act as an umbrella for all the law enforcement agencies. I’m not even counting Canada and the other 23 regions that ARIN represents.

Another issue that needs to be thought of is how will ARIN address foreign subpoenas and court orders. Are they going to recognize them?

If you have a case – say Brazil wants to come, they have an issue with one of these companies or they need to look up that IP address, are they going to issue a subpoena to you or to ARIN, and is ARIN going to be like it’s Brazilian, we can absolutely take it? No, it doesn’t work that way. The way it works is you have to go through the Department of Justice who has to work with the Brazilian Department of Justice, and that could take months or even a year if it’s a standard case. Obviously if it’s an emergency case, maybe it might happen in a day or two.

But ordinarily that would take months or sometimes even years. Sounds ridiculous, but that is the reality of the situation. If you want to add something like this into the mix, it’s going to be very complicated.

John Curran: Thank you, Bobby. I get to respond on two points just for clarity. The vast majority of times that you think that law enforcement would come to ARIN, they actually don’t need to because they’re going to the public Whois. And that’s why this scales.

Someone said ARIN – when you do go to ARIN for something that’s not in the public Whois, ARIN requires a subpoena. That is not 100 percent true. I want to be very clear. We cooperate with national and international law enforcement. If you have a life-critical situation, it’s quite possible that ARIN will comply without a subpoena on its own judgment. That is just something to be considered. There’s not a lot of those, but they do happen.

And I want everyone to be clear and on the record that our practice is actually no different than your ISP’s practice in this area.

Tim Denton: I’m going to handle the calls possibly quite unfairly, but I’m just going to go, because this is a goodly crowd that wants to speak.

I’ll go to Aaron and then that microphone and then that microphone and then this microphone. I’m sorry about that if it’s not entirely fair. Aaron.

Aaron Hughes: Aaron Hughes speaking for myself. I’m strongly in favor of wrapping this up into a wad and throwing it in the trash and not spending any resources at all of ARIN’s time.

And a couple of points. If for some reason there were some community support for an effort to continue any effort in this neighborhood, I would strongly suggest reaching out to the internal policy enforcement community and abuse community before doing anything to get a much more reasonable slice of an opinion on how much effort we’d have to put into enabling abuse coordinators to find contact information.

Secondly, the comment about this being harder to do if implemented by ARIN is probably inaccurate given that everybody’s moving away from email templates and using REST systems. It is very easy for a service provider to check the box as default privacy for everything going forward.

It is by design – and I’m pretty sure, unless someone from ARIN wants to correct me, that is the intent going forward, is to automate all of this.

So I would bet that all ISPs as they’re implementing these provisioning systems today would check that box as default going forward, and that 22 percent number you’re seeing in this example would convert to something like 80 percent private and 20 percent public.

Tim Denton: Thank you. I’m going to go to the gentleman on my right.

Sean Kennedy: Sean Kennedy, XO Communications. And Aaron covered one thing I wanted to talk about, which is automation. But my guidance on this is let’s discuss this.

It’s a request that ISPs do get. It is something that people out there do work around. They ask for /29s because they believe that’s one way to get away from reassignment. And they have other providers that sometimes just do this for them and keep the assignment under the provider itself. And I don’t know how they deal with ARIN in that case with reassignment and new allocations. And they come to us and say just SWIP this to this ORG name.

So there is something happening there. And I think that the ARIN AC should decide very simply: Do we want to support this or do we not? If we want to support it, make it simple. Because I get requests, which are law enforcement saying, I don’t want to be tracked and so give me lots of little blocks and don’t reassign those. And we get requests that are people that are doing corporate spying and whoever knows what and don’t want to be tracked for that reason.

So where the ISP law enforcement can come to us for customer information if they need so if the ARIN community says this is a good thing, make it a good thing, make a simple policy, if ARIN says this is a bad thing, make a stronger policy saying this should not be supported and all business records need to be reassigned, and we’ll point to that and say we like your money, but we can’t do this. Sorry.

Tim Denton: Thank you very much. I’ll take the gentleman at the rear microphone in the center.

Warren Johnson: Warren Johnson, Wholesale Internet. We support the spirit of the policy. We feel that our customer data is private and proprietary, and we would oppose anything that would provide this information, the private information to law enforcement in any kind of bulk tool.

The reason being that, again, we feel like it violates the spirit of the data being private and proprietary. It’s not anybody’s business where our customers are.

If you have a valid law enforcement concern, you can go through the legal channels that are necessary, request the information, and certainly we will comply with any and all valid law enforcement requests in that sense.

I would say from some personal experience perhaps what would be useful in a private Whois is that at least showing what country this person’s from.

I know that it is difficult to – if you were in the United States and you were a United States law enforcement agency, it can be very difficult to get cooperation or even to prosecute somebody in another country.

So perhaps knowing whether that person is domestic or foreign could prevent a lot of subpoenas.

Tim Denton: Mr. Springer over on that side.

John Springer: John Springer, Inland Telephone. I have a couple of thoughts about this. I have a bit of a background in network security, and my overall lifetime impression is that bad guys don’t like sunshine and that this kind of a thing would insert an extra layer of shade.

With regard to making the data available to law enforcement in a bulk manner, that’s going to be inherently effectively insecure because there’s no way you can keep that locked up.

Government agencies lose laptops. And I’m all in favor of more talk.

Tim Denton: Thank you. Just to explain, I’m going to go to the front microphone, then handle a remote question.

Front microphone, please.

Leif Sawyer: Leif Sawyer, GCI Alaska, MSO, and CLEC. So I fail to see how this is substantially different from an unlisted phone number.

In that regard, I support this policy, not necessarily as it seems to be written, but the spirit of it.

I have something else to respond to Aaron. The changing of the dynamic from 20 percent to 80 percent, as a CLEC I don’t want to handle an additional 60 percent more subpoenas, but I don’t see that type of growth growing out of my customers asking for private information.

Tim Denton: We’re already cutting into our break time. I see some interest. I think I’m going to go to one remote, and then I think we’re going to put the question which I think is the proper one to be put.

No one else queue up. Okay. Then we’re not going to have our break. Okay.

So Mr. Anderson.

Paul Andersen: A comment from – question from Cristoph Blecker of Mark Antony Group: “Does the data marked private organization information reside only with the LIR, or will ARIN have a copy in its database, just not public?”

Joe Maimon from CHL is “opposed to the concept for many reasons, but thanks for a new one. Any differentiation in Whois data available based upon who is asking and their privileged classification is wrong and should not be done extrajudicially. And, Louie Lee, I want to hear from APNIC on what challenges they have faced with their implementation execution of their policy.”

Tim Denton: I think the rule is we’re not going to have any more people in the lineup. So, sir, over there.

Yi Chu: My name is Yi Chu from Sprint. I’m the originator of the proposal.

I first want to thank the AC members for helping me put my thoughts into words. Actually, it’s harder than it looks.

The main spirit of this when I came up with this proposal is as an ISP the relation between ISP and its customer, it’s really mainly the responsibility of the ISP.

And when ISP agrees with the customer to do this on behalf of the customer, the ISP takes more responsibility. So from that perspective I see this as far and few between. At least I can see from my company’s perspective we’re not going to go from 20 percent, not even close to that.

Anyway, I think I would like to see more discussions, feedback, and it helps getting this proposal. I mean, the community decides what we should do.

Tim Denton: Thank you. Mr. Schiller.

Jason Schiller: Jason Schiller, Google, NRO NC.

My advice is to try and narrowly scope who qualifies for this policy. The more narrowly you scope it, the more likely it is to pass through this community. We’ve discussed policy similar to this in the past, and the concern has been that every provider would love to make their customer base private just because of the competitive disadvantage and preventing other providers from poaching their customer base.

Clearly, there are industry tools out there to actually help you poach other ISPs’ customer base, and some of that information is built from SWIP information.

Now, that being said, even if you make it simply the option of the customer to make their information private, I think that’s not even narrow enough.

There are certainly many classes of customers that would like to make their information private because they’re trying to avoid blacklisting while doing bad things.

Potentially spammers, organizations that are looking for file sharing, they’re trying to break the file sharing chains, things of that nature.

So I think even that is not narrow enough. But if you took a very narrow view of, say, where privacy is legally required, perhaps HIPAA regulations, perhaps national security issues, if you had a fairly short list of legal requirements that needed to be private, I think that could probably find support in this community.

Tim Denton: Thank you. I’m going to go to Mr. Sinatra, and then I’m going to go to the microphone behind.

Michael Sinatra: Michael Sinatra, ESnet, speaking entirely for myself and speaking as an American, so I’m only going to talk about the US here and not other countries that are in the ARIN region.

I think that the number of people you see at the microphones demonstrates the fact that we probably need to continue with this process and turn this into a more solid policy that looks like a Draft Policy and debate it that way, just because there’s a lot of people who want to talk about it.

I think that this policy gets to a number of trade-offs that we have to – that ARIN has to very carefully balance. There’s the trade-off between the accuracy of the Whois information, in particular, the desire of people who may not have a legitimate policy conduit to keep their customers’ information private, working around the policy.

We heard about /29s and things like that. I think that we need to be very careful of that.

ARIN always has to balance between overregulating and creating workarounds, encouraging people to work around policy and then creating a complete Wild West where anyone can do whatever they want.

There needs to be a balance somewhere. We just need to recognize that trade-off. The second trade-off we need to recognize is between our personal freedoms and our personal rights and the needs of law enforcement.

As many of you know, some of my best sisters work for the FBI. So I’m very concerned about the needs of law enforcement, but I’m also very concerned about the – again, I’m speaking as an American here – the very traditional American freedoms and rights that we have come to know and love.

And from my perspective, privacy is one of those things that should be on by default in many respects.

I don’t think in this policy it necessarily should be, but I think as a general rule remember that all of these things that we have, subpoenas and everything else, the reason we go through this, the reason our lives are complicated in a free society, is because we are trying to protect the innocent. That’s what we’re trying to do.

So from my perspective we have to recognize those trade-offs. I think this deserves more discussion. I’m not sure I would actually support a policy that came out of this, but I think you can see why this needs more discussion. Thanks.

Tim Denton: The lady at the back.

Izumi Okutani: Izumi Okutani. I’m from the National Internet Registry in Japan, and we run our own Whois, which is different from APNIC Whois, so I’d like to share our practice for your reference.

So we have exactly the same kind of issue in Japan, the privacy, protecting the privacy of home users.

So what we do is we do require all the assignments to be registered so that we can check the utilization as a registry.

But we allow the information such as the name, the personal name, the net name, and postal address to be hidden. But we do require the registration of Admin C and Tech C, and we allow the POCs to be registered as LIR POCs so that the law enforcement agencies know who to contact if they want to find out more information about it. And, of course, we also disclose information when we get requests from the law enforcement agencies.

So far it seems to be working okay, and we’re not having any issues with the law enforcement agencies.

So just for your reference.

Tim Denton: Thank you.

John Curran: Can I follow up with a question to that one question? Do you keep a copy of all the data so law enforcement could go to an ISP but could also go to you?

Izumi Okutani: Sure. So we disclose any information that’s registered, like including the hidden information, and we can always disclose them to law enforcement agencies.

John Curran: Do you see a workload increase? Does law enforcement prefer you over the ISP one way or the other?

Izumi Okutani: Actually not so much, because the POC is already disclosed, and they can check. So it’s probably faster for them to contact the POCs that’s searchable on the Whois.

John Curran: Thank you.

Tim Denton: I’m going to go to Owen DeLong, Martin Hannigan, The Wire, and you. Owen.

Owen DeLong: Owen DeLong, Hurricane Electric. I’m opposed to this proposal. We’ve discussed this many times in the past. This isn’t about residential customer privacy. This is about allowing businesses that are collecting relatively large quantities of public resources to hide the fact that they’re doing so and/or hide their usage of those public resources, and I just don’t see any justification for doing that.

I think that sunshine is the best disinfectant, and I think reserving transparency is more important than any concerns for privacy for businesses.

Martin Hannigan: My name is Martin Hannigan. I work for Akamai Technologies. And in a former life I was the surveillance programs liaison to law enforcement at a large national CLEC, and I worked to help architect and operate the VeriSign Net Discovery Service, one of the largest surveillance and law enforcement request-processing managed services in the world.

I can’t say either way whether I support this proposal or not. It seems clear that we need to continue to discuss it.

I think that there are many pros, especially in some of the areas that Yi pointed out. I think Bobby Flaim has some very valid concerns, although I think we may disagree on the exigent need.

I think processing exigent requests won’t be slowed down. They may not be impacted at all.

With respect to what the impact is overall, we might be able to gauge some level of knowledge reviewing the annual congressional CALEA report. I think that you would see that there would be little to few changes in terms of the volume.

I think that the impact would be that law enforcement would likely do less than more if they had the process of a subpoena. I can’t say that for sure, but I think that there’s information out there that can help us to determine if this really has that kind of impact.

With regards to accuracy of Whois, I agree. We are wholly responsible for that, but I will also point out that quite often people that use Whois are wrong in the interpretations. For example, if you dig www.cia.gov and the Whois IP address, my name comes up.

Thank you.

Kevin Blumberg: Kevin Blumberg, The Wire, ARIN AC, speaking on behalf of The Wire. Are we getting bad feedback? Okay. Better.

The first thing I wanted to say was that I’ve always used the Whois policy as a security blanket. The security blanket was when somebody came to me and requested a /29 as a new customer and they said they wanted to hide their data. And after I said the policy requires it to be disclosed, that was the strike for them to go to some other company, because what they were doing usually scared me.

So that’s one thing.

But the two things I want to say is I’ve done a number of residential privacy things. ARIN staff have come back and audited me in terms of the levels that I was doing within the residential privacy, because I don’t really do individual commodity residentials usually for people who want a /29 for their residential locations. And they have audited me on that.

But my most important point to all of this is we are a self-regulating industry. And my biggest concern is if we use a big hammer and swing privacy one way on this, we can find ourselves going from self-regulated to government-regulated WCIT or whatever the case may be, so that really scares me.

So I’d rather be fair than regulated.

Tim Denton: Thank you. Mr. Grundemann.

Chris Grundemann: Chris Grundemann speaking as an Internet user. So the first thing is I think that Bobby Flaim raised some really, really good points that we all need to pay close attention to as far as law enforcement’s needs for information on Whois actually using addresses rather than who is a registrant of ARIN.

But I also want to remind everyone that law enforcement is not the only people who need to seek out other parties on the Internet. There are abuse departments in almost all of our companies. There are security folks all over the world who also need this information.

So if we put up a wall where only law enforcement is allowed to get this information, we’re doing a massive disservice to ourselves. I think the spirit of this policy is a massive step in the wrong direction; that greater Whois clarity is the best thing we can do, transparency of Whois using what addresses is part of the deal for using the Internet, just like being able to be photographed is part of the deal for walking down the street.

This is a cooperative environment. Peering agreements that are done on a handshake. The Internet runs on our ability to be open and transparent, and the entire system seems to work very, very well the way it is. And I think the only thing we should be doing is enhancing that clarity rather than diminishing it very, very heavily, as this seems to want to do.

I will add Jason Schiller raised a good point. If there’s a legal point of privacy in very specific situations, that that may need to be addressed. But blanketly allowing ISPs to not do Whois anymore basically is a horrible idea, I think.

Tim Denton: Last comment will come from David Farmer.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I think we need to look at what’s being requested here. I would not support blanket privacy of this information, but maybe what’s being requested is more accountability over who accesses the information. Right now Whois is not only public information but it’s anonymously available.

There is lots of public information in the world. Much public information is not anonymously available. You have to request it from the government, and the government identifies who you are in order for you to get the information.

So maybe we should be looking at our processes of how we deal with the information rather than the equivalent of pasting it all on the bathroom wall.

So that’s just a thought to throw out there. Thank you.

Tim Denton: Okay. I think it’s entirely appropriate that we have a show of hands regarding the proposition should the ARIN AC continue to work on this policy proposal, and so that is going to be the question. We’ll get the tabulators up with their pads and pencils.

Those who believe that the ARIN AC should continue to work on this policy proposal, those in favor of this idea, please raise your hands.

John Curran: Raise your hand high if you’re in favor.

Preferably could you wait until after the show of hands?

Tim Denton: Done. Those who believe that or consider that the ARIN AC should not continue to work on this policy proposal, would you please raise your hands.

John Curran: Everyone knows in a show of hands you raise your hand once, either for or against. Okay.

Tim Denton: Thank you. You can lower your hands now.

Cathy Aronson: Can I say it now?

Tim Denton: Yes.

Cathy Aronson: Cathy Aronson, ARIN AC. I want to say this is one of the first times in the history of ARIN that we’ve talked about a proposal before it became Draft Policy. And any of you who have feedback on the usefulness of this, please talk to one of us on the AC, because we’ve been really trying to make this happen for a long time because we feel there are things like this where we’d like to be able to discuss it, but there never seems to be an avenue to do that.

So if you found this worthwhile – I can’t pull the word out of my mouth – please let us know, because we might be doing some more of this in the future.

Anyway, thanks.

Tim Denton: Thank you, Cathy.

Okay. Proposition – it’s called 180 – ISP Private Assignment. Number of people in the room, meeting and remote, 135. In favor, 19; against, 33. So there we have it.

John Curran: Thank you.

(Applause.)

John Curran: Someone said we were going into a break. We’re not, actually. The schedule is very full, but the break is coming up shortly.

I’d like to call up – we have two RIR updates and a couple of reports. I’d like to call up Juan to do the LACNIC update.

LACNIC Update

Juan Peirano: Thank you, John. My name is Juan. I work as Hostmaster and Policy Officer in LACNIC.

And this is going to be fast. Not furious, but fast. Okay. Here we have the topics I want to talk to you about. But we can skip this.

And regarding membership update, we have, to our last count, more than 2600 members. I think that’s more – 50 – 100 more than last year. We’re pretty excited about it, because this shows how Internet is graduating throughout the region. So it’s a good number for us.

Regarding resource update. Numbers are going up and resources are going down. So we have 3.21 /8 to allocate. This was measured on 15th of October from this year.

Okay. Regarding IPv4 and IPv6 allocation assignations, we have this graphic that shows that we have an average of 130 allocation and assignations per month. So that’s about the average.

Regarding IPv6 allocation assignations in /8, the first graphic is a month-by-month graphic. We can see that we have some peaks; that these peaks show the assignations made. Just right after our meetings, our members request a lot of resources at our meetings. And the graphic shows the accumulated and /8 that is going just up.

Regarding IPv6 allocation and assignations, we have a total of members, and almost more than half of them have IPv6. This is great. We have a lot of IPv6 in our region. Not a lot for us maybe. In 2011 we had the 348 allocations and assignations, and this year so far we have 476 allocations and assignations made.

With regard to resource certification, we have I think almost 200 signed prefixes and almost 6 percent of IPv4 space covered by ROAs.

Something about the FRIDA program. The FRIDA program is our regional fund for digital innovation in Latin America and the Caribbean. It’s an initiative of LACNIC. You can obtain funds in two ways, through FRIDA awards or FRIDA grants. FRIDA awards are for existing projects and FRIDA grants are for further projects.

And the good news. Since February 2012, FRIDA is part of the Seed Alliance, and we are back to back with ISIF.asia from APNIC and FIRE from AFRINIC.

Regarding previous meetings, we held our last meeting in Ecuador in May. It was a really good meeting. We had our general meeting, policy forums, a lot of technical forums, most of them about IPv6. And we had our record of participants, almost 500. It was a really big number for us. And there were four policy proposals. Two reached consensus.

Another meeting was held in Port-au-Prince in Haiti last July, also with a lot of workshops, mostly about IPv4. But it was a really good meeting also.

The two proposals that reached consensus were LAC-2012-02 for registering assignments, and LAC-2012-03 for special IPv4 allocation and assignations reserved for new members. They both reached consensus in Ecuador, and they were both ratificated in August by their boards.

This is a good slide. We have our upcoming meeting next week in Montevideo, my hometown. We’re excited about it because it’s our tenth anniversary. We are pretty old. And we’re going to be back to back with LACNOG. We’ll have outstanding speakers like Geoff Huston, Steve Crocker, and Lynn St. Amour, for naming a few.

And we are going to discuss 11 proposals, so we’re going to be with a lot of work. And we’re going to have recognitions and awards and fancy dinners and all that stuff.

We have also new offices. These are great offices just by the beach. We can see how other people are having fun on the beach. But the good thing is that we are under one roof with other important organizations in Latin America for the Internet like CLARA, LACTLD, ISOC, LAC-IX, AHCIET, and eCOM-LAC.

And that’s about it. Thank you.

(Applause.)

John Curran: Any questions? Thank you.

Next up will be Axel Pawlik presenting the RIPE update.

RIR Update - RIPE NCC

Axel Pawlik: All right. Good afternoon. Something old and something new from the RIPE NCC. I want to do the “something borrowed/something blue” thing. That’s for some other time.

All right. We’ve done it. It happened. In September. Later than we thought. Kudos to Geoff. He was pretty much on time with his predictions.

We didn’t do it as Wile E. Coyote-style as I predicted, just bang into the bottom. We were a little bit softer there. Gave us time to prepare properly. It went well. I’m very proud of my folks at home who actually worked doing this.

Further from that, we’re following the APNIC model. Lots of growth up to the right. We are still growing. We see for this year double the growth that we had predicted. So, wow, hope it stays like that.

Some new stuff. RPKI. We’re working on it, continuing the main things that we are focusing on, obviously security. Brazilians operate autonomy, very, very high on the agenda. And expansion of the service.

Most of the work we’ve done over the last couple of months were on the back-end system, apart from a new interface for managing ROAs.

The take-up remains fairly high. We’ve seen a slide. I don’t have a graph here, but it is up and to the right, as it should be, 1100 certificates, about 900 ROAs, and quite a number of prefixes. It goes better than we thought initially, but of course we obviously put quite a lot of effort into talking about it and looking after people who want to use it.

We have heard complaints that we’re not doing it fast enough, not putting enough resources into that. But I’ll talk to the Board about that.

We have some other new stuff, IP Analyzer basically. It’s a reimplementation of an old tool we had, ASUs that was. Basically this gives you the – or members the possibility to look at the status of their resources and that everything is well organized, helping them with that.

And RIPE Stat is a similar thing that harnesses the depth and the breadth of all the data that the RIPE NCC has hidden away somewhere and puts it into a nice user interface, basically giving you a chance to look at basically any old resources and whatever we have about that in house. Nice user interface, have a look.

RIPE Atlas is in itself not that new anymore, but we’re rolling out what we call RIPE Anchors. Basically it concentrates on nodes for the system, which allow some more powerful measurements. Or something new, of course, is user-defined measurements that we promised we would deploy. We have done that now. There are things going on. We are talking about that on Labs as well.

The Atlas Anchor boxes will probably house some additional services there. Maybe a small cable like that.

The test traffic measurement network will be switched off not too far in the future, and we’ll of course have a talk to the users of the TTM network currently, the service. We will take their needs into account, basically reimplement the thing on the Atlas infrastructure. Similar to DNSMON, measuring of high-level name servers.

Database Software. I hear the software that we’re currently using is about 12 years old. I think it’s not quite 12 years. It might be ten or so, I seem to remember. But it’s a long time ago, so we need to fix that stuff. Basically make it easier to enhance according to the wishes from our community. So we are doing this, and in the end code will be publicly available as is good practice with us.

CPE Survey. Basically Marco Hogewoning has for a long time worked on that, and we’ve gotten couple of a requests: Where is the new version of it?

So it’s out there. Have a look. We’ve just recently reloaded basically the data there.

In terms of outreach, hey, a new meeting. For many years now we’ve been going to the Middle East talking to our friends, colleagues, there, trying to talk to governments as well. I’ve sent a staff member there. You might know him. He’s gotten himself into a lot of more work, basically being on the multi-stakeholder advisory group for the new regional IGF and also for the big IGF globally.

Last week – no, before last week. Two weeks ago we had the first Arab IGF happening in Kuwait. It was quite a nice event. I was quite astonished how many people came and the diversity of people coming. It was a great success. That means we have to do more work for that and support it even more than we did before.

But that’s a very great event that the locals have put up there.

Old meeting. Yes. The RIPE meeting happened some weeks ago. Less members coming – or less participants coming. Shouldn’t be “members”; it should be “participants.” Less participants coming to a LACNIC meeting. That’s a bit – we have to work on that. But for us it was quite good. It was in Amsterdam after quite a couple of years.

The great news from that is the big saga of, oh, we need a new charging scheme and we wanted to do all things at the same time and be very simple also. That is done. We had a couple of proposals to our members who we let vote on those three proposals, because we just couldn’t synthesize what we really wanted to have.

And the surprising outcome is, hey, we have a new charging scheme. It’s not a scheme. It’s a fee. Everybody pays the same. All services are included. Where we have a couple of people using services paying X, some of them not being members, they will become members and services will be included then. 1800 euros per year for next year.

And it says per LIR. It’s not per member. Members are allowed to have several LIRs for whatever operation. We use them for otherwise. So per local Internet registry 1800 euros I think is fairly cheap. And thank God we can get rid of all the other schemes.

Old addresses. We have been talking to legacy holders for quite some time, with quite good results here and there.

We also have made some Comms faux pas where we apparently use threatening language, requiring them to do things that they don’t want to do. So basically we have a bit of a discussion going, which is good, some policy proposal under discussion. There are also some things that result from that that are of course more financially related, so members will have to talk about that.

Old issue. Yes, we have been ordered to freeze a few blocks, then we unfroze them. But these are coming to our – they’re telling us to do that. We basically challenged them saying that what they brought to the table was not the proper court order. It was not a court order at all. So we have a hearing in court by the end of November. So we basically sued the Kingdom of the Netherlands. That will be interesting. The decision will be expected for next year. We don’t know what’s going to come out of it. Basically we say the laws that you have don’t allow you to do this.

And we got this fax to our Chairman and also to your President from the group called United Against Nuclear Iran basically saying – basically saying: You are doing things you shouldn’t be doing, so stop doing them. And we said: Thank you for your fax. We are looking at our due diligence procedures. Obviously we want to be in line with local laws, and sanctions play a role there.

But we also contact the authorities in the Netherlands trying to get some sort of clearance to deal with our members in Iran, because we think providing Internet to them and numbers to them is absolutely important.

Basically we’re looking at these cases from the view of the registry who wants to preserve its members right to change the registry and protect that registry against others taking influence.

We have recently assigned a new MoU with APNIC, basically for a long time we’ve been cooperating quite closely with them. The goal here is to enhance our cooperation on specific projects, not only the political level, IGF enhanced cooperation, but more concrete.

The first things that we are starting on is some developments on the database, certification, user interface, stuff like that that we want to share. Basically the idea is to not duplicate stuff that we’re doing maybe in different places at the same time, but just do it once and share it and share the cost for that as well.

This MoU is open to all the RIRs, just happened to be the first one that we actually signed.

So this is also orthogonal to the cooperation that the RIRs are doing with the NROs. This has nothing to do with it. This is concrete project really.

And a shiny new meeting coming up in Dublin, and you know you don’t really want to miss that. Of course, you’re all invited. Any questions?

Vint Cerf: It’s Vint Cerf. Axel, could you say a little bit more about the Atlas system? The reason I ask is that some of us have been involved in a measurement program called M-Lab, or Measurement Lab, and we’ve also operated in Europe and had a few workshops.

So is the Atlas system similar, if you know anything about M-Lab, or can you tell us a bit more?

Axel Pawlik: I personally don’t know that much about it. But Atlas system is a replacement for what the test traffic measurements were for 15 years or so.

The point that we have with that is that TTM never really took off as it should be. It’s relatively expensive, has big hardware boxes there and GPS antennas on the roof. This is supposed to be or is, as it looks, very simple. It’s based on USB dongles.

And thank you very much for asking the question, because we have a couple of those dongles here. If anybody is interested in taking part of this, basically they take power from your USB port. On the other end you put them onto your network. They don’t interact with your local network. You’re supposed to register them and you can play with them, we can see what’s going on.

I don’t have anybody here currently who knows the depth of that, but I’ll get back to you. Kaveh, come on. That’s a different department, though.

Kaveh Ranjbar: Kaveh Ranjbar, RIPE NCC. So, yes, the probes are small computers, actually, with a small variation of Linux on them. And there are a preset set of tests, so when they’re connected to network they do something, test like that. They send them to the central server. So maybe that’s – and they’re registered. Most of the data is public, but the owner of the program gets to see more. And there’s also user-defined measurements, which users can define any measurement and they can see – like run a test to ping, for example, one house from 1,000 probes and things like that.

John Curran: How many probes do you have deployed right now?

Kaveh Ranjbar: The last number I heard, if I’m not wrong, we gave out around 1,800, and 1,200 are active and operational. Because some users get them, connect them, but then disconnect them.

John Curran: Doing pings and DNS measurements globally?

Kaveh Ranjbar: Yes.

Vint Cerf: The M-Lab system, I don’t know how many nodes we have. But it’s intended to look at other performance measures, broadband in particular, latencies, variability in latency and so on.

I think we should talk a bit, because we have on the order of a petabyte of publically available information about network performance, and that might be of some interest to the research community.

Axel Pawlik: Absolutely. That’s our goal also. We want to put in the end tens of thousands of those things. I think we have about 2,000 deployed right now. There’s also a bit of a lag between stuff that we have sent out that sits somewhere on the desk, behind the desk, or under a desk.

So if any of you should have one of those probes under your desk or behind your desk, please get them and plug them in. That would be helpful. Otherwise, if there are people interested, I think Andrea has a handful of those things here.

John Curran: Any other questions for Axel? Thank you, Axel.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I’ve been hosting an Atlas probe at my house for a couple of years now, I think. I think I was one of the first people to get one. And Hurricane Electric also hosts a couple on our network. It’s really quite a painless process, and you can get some very interesting information about the network from it by hosting one.

So I really do encourage people to talk to Axel and get a couple of these probes and deploy them in the network. It’s very painless and very helpful to the industry.

Axel Pawlik: Thank you.

John Curran: Thank you, Axel.

(Applause.)

John Curran: Two quick topics and a break. Topic number one is the Advisory Council, Improved Communications Committee Report. Kevin, if you want to come up.

Advisory Council’s “Improve Communications Committee Report”

Kevin Blumberg: Kevin Blumberg, ARIN AC. The Communications Group was set up a while back to look at ways at improving the communications ARIN AC has with the community.

There have been some small, incremental improvements over time, specifically related to the PPML in regards to decorum and trying to keep things a little more on topic, things like that. But they have been incremental. And what we have been looking at and what we are continuing to look at and, more importantly, looking for the community to give us help and advice on is how do we get more people communicating on policy either through the PPML itself or through other means.

And if there are other means, we absolutely ask you to please use the ASCP process to make suggestions in that regard, was the first thing.

The second thing is that, especially it sort of came to light at this meeting, there have been a number of fundamental flaws that were found in policies at this meeting, things that I think deserved attention prior to the meeting, and, through no fault of the people that had brought them up, it didn’t happen until the meeting itself.

And that is something that is crucial to having good policy discussion in the future, is getting as many people early on as possible to work on the policies.

So if you have suggestions, please come up to one of the AC members and talk about it. Please put it through the ASCP suggestion process.

John, was there something you wanted to add in regards to things? Perfect. And if you have any questions, let’s do it at the break rather than prolonging things. Thank you.

John Curran: As we get towards the end of the day, we have a couple more reports. I have one on the proposed fee model.

Proposed Fee Schedule

John Curran: Now, we’ve been talking about ARIN’s fees for second half of last year and most of this year. People have gotten up at various times and said: You need to address things.

We do. We have done some minor changes over the years. For example, we have this IPv6 discount that we set up five or six years ago that’s been fading every year, and the Board realized we needed to make sure we didn’t create a penalty for v6. So we extended that discount table a while.

ARIN’s fee structure historically have been based on resources received every year. Now, some people don’t receive resources, and once you end up in a category you stay in a category unless you return your resources. We wanted to change everyone to make sure everyone’s consistent.

We have a proposed fee model between the FinCom and the Board, and we talked about it at the last meeting but didn’t provide the details. We spent a lot of time talking at the last meeting and the prior meeting about the cost, because we wanted to know how much are we trying to budget for and how should we spend that money.

We have a good grip on that, and now we have a proposal for a fee schedule that we’ll put out today for community consultation.

I want to walk through what the changes are. We’ll take comments, but we’ll also of course take them through the consultation process.

So a couple of the goals. Equitable fees based on costs. Members receiving comparable services should have comparable fees where feasible. Not striving for precise cost recovery. We don’t need to make sure everyone’s paying their hours of ARIN’s time or their amount of computer heat generated, but we want to make sure that parties have comparable conditions.

Now, this gets very interesting, because the first thing that comes up is legacy – not legacy, but end users and ISPs in many ways look similar. They get address blocks. They have IN-ADDR. They provide services.

But we’ve been treating them very differently. And that was one of the questions about equitable treatment. Also whether or not you measure equitable costs down to an address block level or down to an IP address level.

I mean, you’re an organization and you have a /24. He’s an organization and he has a /8. You both have one entry in an Oracle table. Congratulations. So we had to come up with some reasonable approaches for these.

But the goal is that if you are a certain type of entity, you’re an end-user or ISP, and you have a certain amount of resources, you are paying fee schedule similar to other organizations of the same type with the same amount of resources.

We want to avoid creating disincentives for the adoption of industry-wide initiatives. So example. IPv6. Oh, you deploy IPv6 and you’re going to pay something more. That will be bad. Resource certification. Even if it’s a minor fee, any fee means someone has to justify to someone else why they’re writing a purchase order to get additional services.

So for things that we know we want to do, DNSSEC, IPv6, resource certification, we’re trying to include those in the service bundle because we don’t want to have a circumstance where someone can’t do something that benefits all of us, because they would have to pay an incremental cost. So we try to include those in the services.

Target a smaller ARIN based on long-term post IPv4 runout expenses. I want to be clear. This doesn’t mean we have to get smaller. We’ll get as large as we need to be and no bigger. And that might be larger than we are today or smaller. But it’s not inevitable that ARIN needs to do more.

It could be a quiet time. Five years, ten years from now we could have less policy. And we’ve already talked about the fact that if we have less policy, well, we don’t need to do as much. We may have less requests coming in. In that IPv6 nirvana world, you get the block and I get to see your grandchildren come in and look for more address space.

So it’s not inevitable that ARIN is going to grow. We wanted to put that on the table.

At the same time, in the last two meetings, people have lined up at the mics and said: I want more. I don’t understand why you’re building up the reserve. I don’t understand why you’re not doing more development. I have lots of features I want. And why aren’t you spending the money? And so we had to balance these goals. We want to make sure we’re aiming for the right target.

We are not trying to build a larger revenue stream than we have today. There’s no reason for that. If anything, ARIN will continue to fill and grow in at the size we’re at.

So maintaining and reduce, where possible, costs for small organizations. Over the last three meetings in the open mics talking about fees and costs, we’ve had many people stand up and say: We need to make this easy for small organizations, and the success of the Internet is based on the ability of small organizations to participate.

This is a challenge, because it requires spreading out the fee categories. Presently there’s a minimum size, extra small category, and it’s still more than a thousand dollars a year, and that’s just what it is.

If we need to lower the bottom category, we actually need to raise the top category to provide the funding to lower the bottom one.

But it was felt strongly. Based on the member discussion, the Board and the FinCom said: We’re going to do this. We’re going to try to lower down the reach of ARIN so that smaller organizations can participate.

We want to promote the open membership structure. We want to make sure we understand what an ARIN member is, and what that means is that we needed to find who has a bona fide interest. While everyone participates in the policy process, and that includes civil society and that includes government and that includes a lot of parties, we want to make sure we understood who would be an ARIN member. And an ARIN member is an organization with number resources receiving services from ARIN.

We want to make that very clear so we all understand, if you’ve got Number Resources, you are very much a member. You’re participating in this.

So let me talk about recent revenue history. And I don’t know if you can see the eye chart. I’m guessing – yeah. Okay. So the line that we’re talking about is the registration revenue line. It’s the third one from the bottom.

And it’s 11.5, 12.4 – I’m going 2008, 2009, 2010, 2011. 11.5, 12.4, 13.1, 14.3, 14.8. In the last two years it’s been 14 and some change. And then we have investment revenue, which, depending on how the market’s doing at any given period, either adds or subtracts from our position to give you the total revenue we’ve received.

And we’re approximately a $15 million organization. So we targeted that number for what the revenue should roll up to when we look at this new line.

So here’s what we’re trying to do. Finalize the transition for fee from numbers to fee for registration services. Add up the total amount of resources you have, v4 and v6, look it up on the schedule, and that’s the category that you’re at. If you’re an ISP.

If you’re an end user, you’re an end user. You pay just maintenance fees. We have two separate categories. We could have tried to normalize end users and ISPs. But it was really felt that that wasn’t exactly fair. A lot of end users have their address block. All they want to do is pay their maintenance. They don’t want to participate in the process. They don’t need to participate in the process. Whereas the policies we do every day, the things we do when we do Internet governance, affect the ISP community in a great material way.

So we didn’t think that trying to lower ISP fees and raise end-user fees and try to meet a harmony in the middle was a good thing. Just didn’t make sense. We did look at it to make sure it didn’t make sense, but it doesn’t.

So we’re trying to finalize the transition. We align the IPv4 and IPv6 fee schedules into a single set of registration service plans based on total resources held, kind of like we do today, but you add up your total v4 and v6. You’re – based on the largest of those two, you’re going to end up in one category or the other.

We did remove the unlimited registry services for $100 annual maintenance fee.

So not all end users are the same. We have end users for organizations who have 20, 30, 40 address blocks, because that’s just how it happened. It might have dozens of AS Numbers. They pay $100 just like an organization with one AS and one address block. We decided that if you’re an end user, you pay per address block, and that’s still going to be much less than your corresponding ISP in the vast majority of cases.

And then, of course, as we said, make sure the registration plans are very low cost and suitable for the smallest organizations, and we’re adding specifically an XX-small category in the proposal.

So our current categories. And that could be larger, but I guess it’s readable. We don’t have an XX-small category. And this laser pointer work? Yeah. We don’t have an XX-small and we don’t have an XX-large. We have based on the held IPv4 resources you’re extra small through extra large, and based on your held IPv6 resources you’re extra small or extra large. And the range is /20 or smaller for extra small or a /48 or smaller for IPv6. And on the large side it’s /14 or /22 for IPv6.

So, again, we’re going to spread out the categories so we can introduce the lower cost one at the bottom. That means adding a larger one at the top.

If you’re out there thinking, well, I have a lot of Number Resources, yes, you’re about to see an increase. Okay? I’m prepping you for it. It’s coming. Okay?

So here’s the proposed fee schedule. Okay? And the proposed fee schedule shows that our new range at the bottom for IPv4 is /22 or smaller, for IPv6 it’s /48. So this is an XX-small category. And then at the large side we’ve added something that kicks in at /12 for extra large for v4 and /25 for IPv6.

And we’ve evenly spread the buckets between. And everyone gets cast in a bucket based on the larger of the two. What does that mean? I want to tell you for the existing fees we actually lowered them all slightly for every category. So the small fee was 2250; it’s now 2,000. The median fee was 4500; it’s 4,000. And similarly. They all went down about five or ten percent.

So every category did get lowered, but people are moving between categories because we have different breakdowns. So every organization ends up in a different category.

This is the migration chart. So if you look over here and you’re an extra-small organization, you should know there’s 948 of you right now. We have about 4,000 members.

There’s 948 of you ISPs, that is. And 363 of you are going to move down to extra-extra small. And 517 are going to stay in the same category and pay a little less, because extra small fees went down just a notch.

And, yes, 68 of you are moving up. 68 of you have enough resources you’re no longer in what is extra small because the ceiling came down, and, congratulations, you’re in the next class up. Congratulations.

And this repeats. You can actually see at small we have 616 moving down to extra small, one moving all the way to XX-small. We have about 184 moving up, repeat all the way up to the top of the chart. You should know that 53 of the extra large get promoted and move into XX-large.

Okay. The categories and the numbers in the new categories are at the bottom. So you’ve got them here: 364, 1,133, 1600 or so, five, and 56 in the largest category.

So what does this mean? Overview of fee changes. 505 of you see an increase as you’re moving up with similarly situated organizations into a higher category. And you can actually see what it is. Some of these are modest. There is one guy here, medium to XX-large. Only one of you moved from medium to XX-large. I don’t know what resources it is that caused you to be honored in such a way. I guess we’ll have a discussion about that.

The Board did talk about phasing this in. We haven’t made a formal – we’d like to know if that’s an issue for phasing in the rate increases.

I want to point out that 3400 or nearly 3500 members see a decrease. You and similarly situated organizations either see a nominal decrease because you’re in a category whose fees went down, or in some cases some organizations that happen to be larger and now under the category have fallen farther see a decrease.

So it is an increase for some of the membership. Have to point it out.

Overall it’s revenue neutral. You can actually see the schedule here. So here were the old fees. So, for example, extra small, 1250, now a thousand. If you’re medium, you were paying 4500. You’re still medium, it’s 4,000. Unless you manage to go up a category, your fees are going down. If you managed to go up one or more categories, your fees went up.

At the end of the day, the sum category here is about 11.3. On the current fee schedule it’s about 10.8. And that’s to be expected because, as I said, we knew we were going to do something to raise additional money to let us handle the small category, and so it’s about 500k net revenue increase through this change.

The breakdown of members as you can see when you look at it, it’s pretty evenly spread. Little slanted towards the lower side.

There are other revenues. And in addition to the registration fees paid by ISPs, end users, legacy holders pay fees. There’s transfer fees. Those are on this schedule. So we start with the 11.3 from ISPs. We add – at 100 per ASN we add what looks to be about a million dollars of maintenance fees.

End-user fees for blocks. Annual. 100 per address block, about 970,000. End-user request fees, one time, about 897,000. ASN – sorry. ASN request fees, one time, when you’re making a request, about 785 expected for next year. Transfer fees. And then everything else, miscellaneous about 170. Should put us at about $15.4 million revenue for 2013.

You know, we have to estimate the one-time fees. We’re guessing address transfers and we’re guessing number of ASN requests, but we’re pretty good at it. We expect to come in about the same.

That’s it. I would love questions at the mics, but I also want them at the break, tonight, tomorrow. We are opening it up for consultation so you can file them online, but the mics are open now.

Yes, Mr. DeLong.

Owen DeLong: So as I understand this, as an end user with two IPv4 blocks and an IPv6 block, you’re going to triple my fees?

John Curran: Probably. If you’re an end user with multiple blocks and you are only paying one $100 maintenance fee, then you’re probably going to be paying 2- or $300, because we’re not giving you unlimited number of blocks for $100 maintenance annual.

Owen DeLong: So one way I can partially solve this problem is I can take two of my IPv4 blocks that are a /23 and a /24, return them under amnesty and get a /22.

John Curran: Sure.

Owen DeLong: Waste a /24 that I don’t really need at a time when we’re worried about IPv4 runout.

John Curran: Yes.

Owen DeLong: And save $100 a year.

John Curran: Absolutely. If your time is worth that, then that would be a reasonable transaction.

Owen DeLong: $100 a year covers a relatively small amount of time to fill out an ARIN request.

John Curran: It’s available to you under policy. Yes. Far microphone.

Kevin Blumberg: Kevin Blumberg. Very quick question. This is now based on the total number of IPs. So if I had 20 /20s, add them all together, versus if I got a /20 once a year over, which is why there’s such long swings in some cases.

John Curran: Correct. Center front mic.

Scott Morizot: Scott Morizot, IRS.

(Laughter.)

Scott Morizot: The fee changes, wherever we ended up, aren’t much more than a blip on our budget, and the Treasury gets that bill anyway.

(Laughter.)

John Curran: Which means we all do. I want to point that out. Keep going.

Scott Morizot: But one question I did have is our IPv4 allocations are all legacy under an LRSA, and then we have one IPv6 allocation and an ASN. So how would that –

John Curran: If you’re under an legacy RSA, you’re under a legacy RSA. And it provides certain caps. I believe we can probably raise the fees $25 per year and your invoice will creep up until it matches all other end users at $25 per year.

Scott Morizot: Okay.

John Curran: Yes. Far microphone.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC, and a very small friends-and-family ISP that has three objects in the database. We have an ASN, we have a /22, and we have a /32. It’s not a /32 of v4 space, by the way.

John Curran: That’s good.

Rob Seastrom: So we have a little problem. We’re pretty small. We’re like really small. And if you take a look at what this does, I put stuff into the ACSP, or actually had my partner in crime there put it into the ACSP.

We should look at this problem of very small organizations that by virtue of adopting IPv6 double their costs.

John Curran: Okay.

Rob Seastrom: And I know that what you would suggest is I ought to get a smaller block than the /32, but I already have a /32. What do you – do you have any suggestions for how we can avoid becoming small rather than extra small? Because under the current circumstances, it’s something where the costs look like they go down, but the discount goes away.

John Curran: The discount goes away. If we don’t deduct this, we will need to continue the discount for v6 obviously.

Rob Seastrom: So at the end of the day we’re going to be spending 2,000 instead of 2250, which represents only $750 for going v6 rather than a thousand.

John Curran: In your case your v6 block is such that it causes you to change category.

Rob Seastrom: Yeah, that’s a problem at the margins.

John Curran: That aspect of this is going to be hard to generally fix. It is indeed. The question of if you have a number of blocks as an end user, as Owen raised, and I’ve got some number of ASNs and some number of address blocks, and I don’t want to pay what is 200, 300, $400 per year in maintenance, this community could provide feedback saying the first hundred covers the first five objects and 100 thereafter. And you could set a floor.

But the ISP whose block sizes cause him to go up with IPv6 is a different problem, and there’s not – there’s not an answer for that if you want to have a graduated scale. Some people are going to be increased when they go to v6.

Rob Seastrom: Understood. Also I believe that I detected an inconsistency on the slide deck on page 8 or 9 where you show an extra small category for IPv6 currently in effect, which I believe is not the case currently.

John Curran: I don’t know whether the current one is correct.

Rob Seastrom: I was trying to reconcile that with current reality so I could figure out where I was.

John Curran: The slide deck has been a year dated on that slide because we’ve been working on this for so long.

The new table would be /48 or smaller. And in your case, if it’s up to a /36, it’s extra small.

Rob Seastrom: In summary I’d like to submit that maybe for organizations that have an extremely small amount of IPv4 space we should have a special case cut out to keep that from being a disincentive to smaller organizations.

John Curran: Okay. That’s probably something you want to make sure you record in the consultation so we don’t forget it when we get there.

Rob Seastrom: I think we did that already, but I’d be happy to do it again.

John Curran: Okay. I wanted to take the center center mic.

Geoff Huston: Geoff Huston, APNIC. Just an observation. There were very few variations in this. There’s flat fee, there’s step fee. There’s also a continuous fee. And, oddly enough, this looks a lot like the fee schedule before the current one for APNIC. It’s stepped.

And we actually had a lot of feedback that the steps were causing problems. And using the awesome power of logarithms, we actually managed to create a flat sort of – a continuous fee schedule where it was actually your precise holdings that determined the fee. If you had exactly a /18 or exactly a /16, it looked like that schedule.

But in between it was actually graduating through. So there was no discontinuity. And the whole issue of I’ll move to a new fee schedule with one address disappeared. It’s only a point of information.

John Curran: It’s an excellent one. And it actually was discussed at length by our FinCom and Board. If that’s the other side of the river, this is the stone in between. You’ll note that the categories are very smooth in that schedule. They weren’t in our present schedule. So this gets us to the point where, yes, you can do a curve fit and end up with an exact curve, but I think we need to get to that first. But thank you.

Scott and then the queue.

Scott Leibrand: So I have sort of a question. I could probably figure this out, but I haven’t thought about it in a little while.

In a situation, small ISP who got a /32 as default, really small ISP, who doesn’t necessarily need a /32 even to give /48s to everyone they have, we’ve had some discussions around being able to get /36s and other sizes, and I believe the current policy allows that in some cases.

John Curran: Yes, it does.

Scott Leibrand: My practice question would be: If I go to you and say I have a /32, I’m not using all of it, can I just downgrade to the first /36 of that /32?

John Curran: Yes, absolutely. Give us back one bit. Thank you. One nibble. Give it to us a bit at a time, but you probably do a nibble to get to the next boundary.

The queue.

Paul Andersen: Joe Maimon of CHL: “I think that a size category per number of blocks for end users should be considered to lessen impact on end users. I also do not believe that IPv6 is at the point where increasing expenses for it is a good idea.”

And question: “And how does the size categorization for the IPv6 line up with nibble boundaries which is how IPv6 allocation policy is now centered on?”

John Curran: Okay. And Mr. Woodcock.

Bill Woodcock: Bill Woodcock, ARIN Board. I’d like to address the community on this a little bit because I put a lot of time into working on it.

There’s basically four years of background work into this at this point, starting from a few basic principles. One of them being that discrimination is bad, and that moving towards something that makes ISPs and end users more similar is good. Fewer special cases and corner cases and loopholes is good. Lower costs overall is good.

So what you see here is a compromise, and you’re hearing from people who are each getting up and saying: Well, in my specific case this makes things worse.

And there are always corner cases. And there was a slide up there that showed how many people were moving in each direction.

What I think is most important to understand here is that the people for whom it is getting better or not changing either aren’t going to notice or aren’t going to complain.

And so you’re going to hear about just about every corner case, but it’s really important to look at the numbers and realize that those corner cases are very, very few.

The number of people who are actually disadvantaged by this is vastly outweighed by the number of people who gain a greater advantage. There is no scheme that we could create that would have enough loopholes to make everything better for everybody.

I myself am probably the very worst of the corner cases. I’m going from paying about $300 a year to paying something over $6,000 a year.

I don’t know of anybody who is proportionally changing more than that. And I am fully in support of this change because it makes things better for more people more of the time.

John Curran: Center center mic.

Heather Schiller: Heather Schiller, Verizon. Math is hard and I have a lot of IP addresses. Is there like a tool that will tell me?

John Curran: Yes. We get to the point now where – right now is there a tool? No. The nice thing about this is we could actually put this in an algorithm and give you a tool and actually let you begin to do that if you want.

Right now we would end up mailing – we’re going to mail you out what your new category would be. If you want to call up, you want to find Bob, he can tell you.

Heather Schiller: Part of the problem is that like today I have a – we have a thing in a wiki that says here’s all the accounts we have and here’s what they bill at. But it doesn’t say – I think for some of them we say like small, medium, large, extra large, whatever, but we don’t have it broken down into the number of addresses.

So basically for us to figure out like whether we think this is okay or like what it’s going to do to our budget, we have to go to – we have to go in the database or ask Reg(istraton) Services or someone and say, okay, add up for us – we have to go through and calculate how much address space we have – I get the word the unusual case, but we’re big and we have a lot of crap, but I’m just saying like is there – it would be like I’m willing to do – I mean, we have to do all that part, but it would be kind of nice if there was some kind of thing that we could just plug in our information and then like –

John Curran: We’re in the middle of billing integration right now. So the billing system will actually know what it’s billing you for, because it’s not a separate system.

And so that, plus the schedule, will let us implement what you want. But you’re going to have to do it manually for this one. And Bob is back there willing to help. I see him nodding up and down. Okay?

Okay. Mr. Hannigan.

Martin Hannigan: Martin Hannigan from Akamai Technologies. You’ll probably be half surprised and half not surprised at what I say. But for the second time in 25 years, I agree with Bill Woodcock.

(Applause.)

Martin Hannigan: I think the fee schedule itself is adequate and it addresses many of the concerns of the community. Although, I think that with that said that the fees are still too high across the board and the organization needs to seriously cut their expenses.

Unfortunately, we’re a captive audience. There’s no competition. There’s little incentive except for us to ask you to cut expenses for you to do so, and I think that should be an urgent priority of the organization across the board and in all fee schedules. Thank you.

John Curran: Okay. Far left mic.

Matt Pounsett: Matt Pounsett, Afilias. I’d also like to agree with Woody. As a fairly large end user, looks like my fees would be going at least by order of magnitude probably more.

But given the size of our organization, I’ll have to actually count up all the objects to see for sure. But at first glance it seems pretty fair.

John Curran: Okay. We have someone in the queue?

Paul Andersen: From Joe Maimon again. He’d like to respond to Bill Woodcock.

“Ideally, there’s a very specific differentiation between ISP and end user. For end users, the number resources are a cost center generating revenue only in most indirect sense, while ISPs utilize number resources to drive revenue directly. Fee schedule should take this into account, and I would not label this in any way as discrimination.”

John Curran: Center center microphone.

Mike Joseph: Mike Joseph, Google. First off, I’d like to reiterate Heather’s comments. I treat them as an organization responsible for maintaining a large number of organization records and resources held with ARIN. It can be challenging to get good accounting.

I know that the FSD is quite familiar with my requests and have been fairly cooperative. But it’s unfortunate that I have to bother them to give me spreadsheets. It would be nice if I could get that myself. Particularly, it would be nice if I could figure out what we should budget next year for this.

That said, I also would like to make a separate request that I mentioned last time we talked about fee schedules in Vancouver, and that is I would like to suggest that ARIN should move to a completely post-paid model.

There are a number of times in an ARIN request cycle where the fulfillment of a request would block on paying of a bill. And for large organizations which need to cut POs most of the time to pay bills, this can be particularly problematic.

So I’d like to suggest since almost all other resources held by ARIN are on a post-paid model that we move to an entirely post-paid model from everything from initial assignments to membership conversion fees, et cetera.

John Curran: Including request fees?

Mike Joseph: Yes.

John Curran: We tend to seek request fees up front because, whether the request succeeds or fails, we need to offset the cost involved.

Mike Joseph: The request fee is only paid only if the request succeeds.

John Curran: Not always. There are request fees that are not necessarily in that case.

Mike Joseph: Which ones?

John Curran: For example, if you’re applying to be validated for transfer, we charge the transfer fee regardless one way or the other.

Mike Joseph: I’m not familiar with that one because I’ve not done transfers. But I would point out that I would apply this to initial request fees for going to ARIN and as well as ASN fees, et cetera, where this is a one-time fee. I’ll point out the resource can still be revoked if it’s not paid.

John Curran: Understood. We’ll talk about that. It might be possible. I just don’t know what the side effect is, but I have that one down.

Mike Joseph: Thank you.

John Curran: I’m closing the microphones. Those people with their last comments, this way you can get to the break. So last chance.

Okay. Jason, center front.

Jason Schiller: Jason Schiller, Google. I wanted to follow up on Joe’s comment that not all ISPs get direct revenue from IP addresses.

Some do charge a fee for address usage. Others do not. So if that thought process is going to weigh on how the fee should be structured, please don’t blanketly apply that thought process to all ISPs, because not all ISPs engage in that practice.

John Curran: I think Joe’s comment, I’m not sure, was that ISPs use the addresses to provide services that generate revenue, whereas end users use the IP address to support their network which only in the most obscure way helps them generate revenue.

Jason Schiller: Then never mind, then.

John Curran: At this point, thank you for your comments. I highly recommend everyone come in, we’ll do the consultation. And I recommend everyone please file comments so the Board can look at it.

But at this time we’re going to go to break, and we will be back from our break at – let’s be nice. We’ll be back from our break at 4:10. 4:10.

(Break.)

John Curran: We have a few presentations, and then we’re on Open Policy Hour. So one of these presentations is the Proposed 2013 Policy Development Process.

PDP Update

John Curran: This is yet another epic work of many meetings. We started – Lee and I started – actually Lee, Scott, and I started two and a half years ago. We worked on it and got a Draft Revised PDP. We brought it to the community and the AC. We got lots of feedback. And we think we’ve got it right. This actually went to the AC at the last meeting, and they gave lots of comments.

We flowcharted this out and took out a couple of little process tweaks. I’m going to cover it. It’s going to be published online, the full PDP. It actually was materially the same PDP as we’re talking about now four months ago. So you can go find that call for consultation. We’re going to do one more after this meeting, and then it’s quite likely it would be adopted once that consultation is done.

So this is kind of a last call. Let me talk about what will change.

So here’s the issues that we have with the current PDP. And actually the AC’s really cool. The AC has figured out really cool workarounds for most of these issues already. But we’d like to formalize them in policy.

So one of the problems is it’s not always clear whether and when the proposal author or the AC controls the proposal.

This gets to be really interesting because sometimes people want to see it changed, sometimes the author wants to see it changed. We need a brighter line here. Policy proposals can be abandoned by the AC before the community has had time to consider them.

Now, if you submit next week’s grocery shopping list as a policy proposal, it should be abandoned and shouldn’t take up the community’s time.

But if you submit something that’s just a bad idea, and I know it’s a bad idea, and most of the AC knows it’s a bad idea, that does not mean the community thinks it’s a bad idea.

So things that are policy proposals should actually make it to you guys, and things that are completely not policy proposals, those are about the only thing that the AC should be dropping.

It’s not clear when policies are being presented at a Public Policy Meeting are going to be recommended to the Board for adoption.

And it makes a difference. The discussion you’re going to have, if you know you’re going to see this again, is materially different than the discussion of and, by the way, we’re going to recommend this potentially at the end of the meeting. And so people want to know that.

Probably one of the most significant issues is there’s no clear record of the consideration of the concerns raised in Draft Policy. There is the transcripts of the Public Policy Meeting and there is both the staff and the AC presentation slides, but it’s not actually enshrined in the actual Draft Policy that here were the issues that were raised that were significant and here’s why we don’t think those are an issue.

This is pretty important. So revised PDP attempts to clarify those and other issues. For example, policy proposals under the Revised Policy – Proposed Revised Policy Development Process, policy proposals are under the originator’s control until the AC says okay, it’s a Draft Policy.

The AC can give lots of feedback, but the originator is the one who edits it, changes it. And he may say I’m sick of getting feedback, thank you very much, I want this to proceed.

But it is the originator’s control until the AC picks it up and puts it on their docket. Once the AC picks it up and puts it on the docket, it’s under AC control and they work with the community to figure out what that does.

Clear criteria for valid draft policy. If it has a problem statement, the current policy has the following problem, and it’s in scope, it’s actually a statement about something wrong with the current policy, it’s not a grocery list, it’s not a request to change the fees, then it’s in scope.

And things that are not suggestions to change policy or suggestions to put things in policy that don’t belong there the AC can knock out. But otherwise, once we know we have a clear problem statement, then the AC takes it on to its docket, you get to see it, and the process begins.

It may not be long before it’s killed, if it’s not a great idea. There’s nothing to prevent the AC from then knocking it out. But you will get to see it. It won’t die a silent death if it really is a policy proposal.

AC shepherds are charged with helping – helping. You’re charged with helping policy originators become valid draft policies and only reject if incomprehensible or out of scope.

So the AC’s job is to nurture, help that originator make a clear problem statement and get it to you.

And this is important because, I’ll tell you, the first few versions of a policy proposal often cycle fast and furious.

It’s at least good to get it in writing what people think are wrong and possible ways of changing it in a small group and then bringing the issue of: Is this really a problem that we all want to work on as a draft policy.

Draft policies are under AC control. But you involve the originators, if they’re available and responsive.

If the originator is responsive and wants to know what’s happening with the proposal, wants to hear what you’re changing, you include him in the loop because he’s part of – you’re a shepherd and originator drafting team.

But the AC controls the docket. Once it’s accepted as draft policy, it’s under AC control. But if you’ve got a responsive originator, you should try to work with them as much as possible.

Draft policies are discussed in the PPML, considered by the AC, and recommended if good; abandoned if bad.

This is where you make that judgment call. And there’s some criteria in the new PDP that actually call out some things like fair, technically sound. Things we’ve all talked about. These are – in the old PDP they’re just called out a lot clearer for what the AC should be measuring policies against.

All active draft policies are presented at the Public Policy Meeting. So even if something is still in work, as long as it’s a draft policy, it gets discussed. As soon as we know we have a clear problem statement, it’s a draft policy. And if it’s a draft policy, it gets discussed.

Now, it may be that we’re discussing it because we just want to get feedback. It’s not ready. It’s not ready to go anywhere. Draft policy doesn’t mean ready. Draft policy says it has a problem statement.

But they all come. You get to see what’s in the docket. It may be that the author’s like we’re in the middle of re-editing this and I’m only going to put it up there to tell you what problem we’re trying to solve, and that’s it and it’s a three-minute discussion.

Because if it’s in the middle of being reworked, there’s no reason to have a lot of time here. But all draft policies get presented by the AC so you know what’s in their queue and what they’re working on.

Again, the presentation may be to collect input. The presentation may be: This is the middle of an edit cycle and it’s not yet ready to be considered, but here’s what we think is a problem. They may ask: All I want to talk about isn’t the text, I just want to talk about the problem statement, not the solution, but do we think this is a real problem.

We sort of did that a moment ago. We sort of said, yeah, we know privacy. Do we want to work on it at all? And that may happen. Poll the community and say: Is it a real problem?

So all active draft policies are presented at the Public Policy Meeting. And the thing that gets adjusted is the agenda time: I only need five minutes. I need 15. I need a half hour, et cetera.

We want to clarify the policy documentation issues. And this is important because you have to put yourself in the shoes of someone coming to ARIN N years later.

For example, we have some parties in the room who might not have been at ARIN two years ago or three years ago. They know what NRPM is. They can find it. They can even see the policy archive, but a lot of them are like: Did you consider this or did you consider that? It’s like, yeah, we did. Well, where is the record of the consideration? There is none.

There’s no clear record unless you want to read through the minutes of many, many transcripts of many meetings.

What we want to make sure is we have a clear problem statement with the current policy. We want to make sure we have suggested changes to policy text. And then we want to make sure that there’s an assessment. And the assessment should be that the policy text solves the problem and that it’s fair and impartial. It’s technically sound and it has the support of the community.

If you’re going to advance, you have to have the support of the community. You have to be able to say the discussion on PPML was pretty good, the discussion at the last policy meeting was pretty good.

And the AC’s consideration of significant objections, if someone’s raised an objection, I think this will cause the following, and the decision of the AC is that we don’t think that’s material.

The shepherds working on it are thinking, well, that’s a valid issue but we don’t think it’s as important as the problem. You put that down so everyone knows it was heard.

It may not be the view of – the AC may not be what you personally think. It may be that the community comes back and tells the AC, no, that’s a big problem and you need to fix the text.

But we want to document that we’re producing policy changes that solve particular problems and that they are fair; if anyone raises something that’s not fair, if anyone raises something that’s not technically sound, we want to document that in the actual policy proposal, because this way we have better consideration what we’re working on.

For anyone who has worked in other regions, a couple of the regions are really good at this. Some of their policy documents are impressive because of the record of the consideration of the pros and cons of the policy. And that’s what we’re trying to generate. We’re just trying to look at – the best practices sometimes aren’t in this region.

Okay. So we actually have three states: Policy proposals that the originator owns, Draft Policies, the policy proposals that we’re working with the originator to understand the policy problem as they see it and any proposed solution so it’s clear in the proposal.

Once we’ve gotten that, it’s advanced to a Draft Policy. All that means is we have a defined problem. We have some sort of proposed text or solution and we want to hear discussion about it, we want to hear if it’s unfair, unsound, or not supported by you guys. And if we can fix any of those, we’ll fix it. But otherwise it’s probably going to get killed.

And then Recommended Draft Policy is what happens when you have a Draft Policy and the discussion says it’s not unsound. It’s not unfair. It’s not – it is supported by the community. Then the AC can say, okay, we’re going to recommend this. And that means this is a good policy and we’re going to advance it after the next Public Policy Meeting.

Now, that may slow down things, obviously, because they’re going to have to come to you and say: Here are the ones that are good policies that we’re recommending based on your input, and here’s the ones that we’re still working on, but you’ll know that, you’ll know which ones could be recommended to the Board after the meeting.

It’s a bunch of small changes to our existing PDP. There’s matching changes in the petition process. It’s all in the last consultation, and it will all be in the next consultation because we’re opening one today on the final proposal for the revised PDP.

I’ll take comments and questions. We’ve already discussed a lot of these issues already. But if someone wants to jump up and say something, they can do so.

This isn’t probably a surprise for anyone. If we have remote participants who wish to say something – a lot of the folks are looking forward to this. I will say it formalizes the ability to do policy consultations at other bodies such as NANOG.

ARIN is busy working with NANOG so we can actually do a policy consultation complete with online participation at a NANOG meeting. And that’s to help increase the people in the room but also to – that the operators get more relevant operational input that’s also included in this policy change. So it’s a good thing across the board.

Yes, I see someone approaching the mics.

Sean Kennedy: Sean Kennedy, XO Communications. Just a quick comment. The staff comments, I think there’s a lot of cases where something gets to the Public Policy discussion and the staff is not – they say this is what we think the intent of the community is and this is how we’re going to interpret it, but there’s some issues with clarity and we’re not 100 percent certain.

Is that going to get moved up so that perhaps the AC and the staff could work on that and there’s more clarity and the staff – there’s more clarity in what the staff says they interpret it and how they’re going to implement it?

John Curran: Right. We actually do do review before it gets here. The problem is you often have policy proposals that basically replace this text with this text, and the intent and the problem you’re trying to solve isn’t actually described anywhere. So we’re hoping if we can see that, we can do a better staff review in the process.

But, yes, the intent is to try to get that done earlier rather than later.

All right. There is a consultation being opened. Comments are definitely welcome. The Board is going to have to sign off on this, and if there are issues or concerns, I ask everyone to look. You’ll see it go out tomorrow for community consultation.

I’d like to thank people who aren’t here. Lee, are you still here?

I’d like to thank Lee Howard, who is not here, who started the committee a year and a half ago. Scott is still here. I’d like to thank Scott. They’re my Board compatriots who helped me through this process. I’d like to thank the ARIN AC who was enormously helpful in going through this over the last year and a half.

Okay. That concludes the proposed PDP update, and we’re now going to have an RPKI demo. We’ve had people say we heard you have production RPKI. We’d actually like to show it to you. So I’ll invite Tim up. Tim, RPKI.

RPKI Demo

Tim Christensen: Howdy. I think I’m supposed to say it that way because we’re in Dallas.

So in a small homage to Nancy Sinatra, these boots, like the one you see here, are made for walking. So we are going to take a walking tour of RPKI.

And the trail map looks like this. We’re going to do a little bit of orienteering on RPKI, give you an idea what the math looks like, what’s the path that led us here. And the question that we all get asked when we take our kids on vacation: Are we there yet? Then: Yes. And we are, yes. The answer is yes. Stacy, you’re right. And then the path that is yet to come.

So what is orienteering and why are we talking about that? Orienteering, according to a website, is navigating from point to point in a diverse and usually unfamiliar domain. If that doesn’t describe RPKI, I don’t know what does. And normally you’re moving at speed. As a matter of fact, regarding speed, this is going to try to describe an enormous system in 17 minutes.

So we’re going to have to move at quite a speed. If you want to chat later about any details, I’d be more than happy to.

So what is RPKI? RPKI is Resource Public Key Infrastructure. It essentially issues certificates for network resources to resource holders, the kind of numbers we play with all the time around here at ARIN. And it allows the network holders to be able to associate networks with AS Numbers so that you can do route origination and have it be signed, cryptographically.

It also is going to allow relying parties to be able to validate that the ROA is authentic and actually came from the person who has the right to be able to say this is how I want a particular amount of space announced.

So it can be used as a reliable and checkable trust model for route origin announcements, for routing decisions.

We’re not telling you what routing decisions to make. It only lets you know that what you’re looking at is authentic from the person that’s entitled to say so.

It could be used by routers to validate origin. As a matter of fact, we’ll talk about that in a little bit. And it only needs minimal bootstrapping information. Essentially it needs some kind of a Trust Anchor and some kind of a mechanism so that people who are out there that want to validate such things can validate such things.

The entire thing is managed through the ARIN Online system, or we also have opened up the ability to manage some of the bits and pieces of RPKI through the RESTful interface.

So the RPKI system essentially creates a repository. It’s a holding pen, if you will, that’s going to hold some objects that have been cryptographically signed, generated out of ARIN’s systems so that they can be distributed for people to end up looking at and potentially relying upon.

So what is it that’s inside a repository? What’s inside a repository is an RFC 3779 X.509 certificate. That certificate essentially has all of the material that’s necessary to know that you’ve got a valid signature, and it uses an extension in order to identify the IP addresses and AS numbers that the certificate actually represents that are held by whoever it is that holds the private key to that certificate.

There’s also ROAs, or Route Origin Attestations. Those are essentially announcements that come, that are defined by the customer that holds the space but that are signed by the certificate so that they can be validated.

Also what you’ll find in a repository is a CRL. That’s a common thing in RPKI. Certificate revocation list lets you know if somebody’s come along and either lost their key or they decided to change some stuff and they want to kill off a certificate, or if it expires after a certain period of time.

The last thing that you’ll find in a repository is a manifest record. Manifest record essentially is a record that sits there, which, by the way, it’s also signed and it tells you what you’re supposed to find in the repository.

This allows you to make sure that everything you’re finding in the repository is actually what’s supposed to be there and alerts you if for whatever reason what is supposed to be there isn’t, which keeps people from surreptitiously removing things from the repository in order to be able to subvert what the intention of the person who actually generated these Route Origin Attestations – keeps them from – keeps them from – I’m stumbling over not wanting to use a bad word here. It keeps them from undermining the process, let’s say it that way.

(Laughter.)

Tim Christensen: You were all thinking it and you know it. Okay.

So all of what I’ve just said sounded all convoluted, but really the contents of a repository are pretty straightforward, because it’s nothing more than a bunch of files in a file system. And this is a picture of it. Won’t go into the details, but you can see that there are essentially files there, very kind of cryptic looking files, but they have extensions on them that makes them pretty clear what they are.

What do you use a repository for? Well, what you use a repository for is it is shared via distribution mechanisms if people so desire to do so. You can use it to validate objects; essentially you’re going to want to validate ROAs that are in the repository.

It can also be used to communicate with routers for marking routes as valid or invalid or unknown. We’ll talk about that a little bit later.

But it’s important to understand, especially for our operator community, this is entirely up to local policy on how this content is used. It’s up to the operator to decide whether or not to rely upon information that’s in the RPKI just like it is up to them to decide any other input for what they’re going to put into routers.

So what does ROA validation look like? I’ll mention that I liberally borrowed these slides from my friend Geoff Huston, and I appreciate his art here, and it’s very good at helping to understand what this really means.

You’re going to recognize on this particular slide that it represents a top-down picture of the allocation hierarchy. You can see there that at the very top of the allocation you can see ICANN holding some space, and they’ve given a bunch of space to ARIN, usually in /8ish type of shape or v6 in 23s and 12s.

Beyond that, ARIN typically will allocate space or assign space to someone like an ISP, we’ll give them some space, and we’ll call this guy ISP two. Furthermore, ISP two may then reallocate that space to a smaller ISP. But eventually it ends up in the hands of somebody who is actually going to want to route the space.

Now, what the holder of the space can do, and you can see it in the blue box at the lower left of the page, is that they can issue a route origin attestation, which essentially tells the following: I’m an ISP for – and I permit, in this case, AS65000 to originate a route from 192.2.200/24.

Now what happens here is the system will sign this attestation with a signature, and you can see that the signatures are represented by those little certificate guys with keys on them. In some cases you’re seeing where there are pieces of keys and in another case you can see where there are two keys together that represents both the private key and a public key.

Alright. Now, once this material has been signed and distributed through a repository, what happens is that when someone wants to rely upon it, the first thing that they are going to check is: Did the matching private key that was in this ROA actually sign the text of the ROA?

Let’s presume that it did. There’s all kinds of failure paths if it didn’t. But let’s presume that it did.

If it did, we go on to the next step, which is we look and see is the certificate actually valid? Is it in its validity period? Has it been revoked by a CRL? Those are the kinds of questions that are going to get asked. Beyond that, the third thing that you want to check – and this is where the important part comes in – is did the certificate actually come from someone whose certificate will validate all the way up the chain to the top of a Trust Anchor.

In this particular case you’re seeing that the Trust Anchor is housed at ICANN. Wherever the Trust Anchor is, and right now in ARIN’s system and in the other RIR systems they each have a Trust Anchor at the RIR level, but wherever that Trust Anchor is, the key is you want to be able to know that the certificate – excuse me, that the ROA will validate all the way through valid certificates going all the way back to whatever Trust Anchor you’re trusting.

If you’ve successfully checked all of those things, you’re good to go.

So what is the path that led us to where we are today? Well, you’ve heard it previously and heard it here again today; that the other four RIRs had RPKI running for various amounts of time, okay, and that ARIN is the last one completing RPKI, so that now all five of the RIRs are running an RPKI system.

The reason for that is because there were specific concerns that were raised that led ARIN down a customized path and they essentially amounted to the following: Number one, we needed to make sure that we could ensure nonrepudiation from when somebody says: Hey, I want you to go generate a ROA, we want to make sure that we have the security of knowing that we generated the ROA you actually asked for.

And that you can’t go back on that or change your mind without actually going through the system and doing the right things to make the correct ROA come out.

The second thing was to protect from rogue insiders. Staff members, for example, who might otherwise be able to leverage the system so that they could, oh, I don’t know – these IP addresses people seem to think that they have some value these days. It would be handy to have a /16 in your back pocket to do something with, right? We wanted to ensure we had a system that would not let that happen.

So that took a significant amount of work to ensure that we could protect the system from these risks.

So what did that look like? Well, essentially what we did was we have enabled on the Web browser front end that folks will use a mechanism that helps to automate the way that you generate a ROA or use keying material.

We’ve made some changes to the way our database works. We’ve made some significant changes to an RPKI engine which allows us to drive on the back side a hardware security module where keying material is actually held.

Now, because we needed the protections I just described, a significant amount of custom programming that no one else on the planet truthfully has done for this particular device that we used, a lot of significant work had to go into programming that device such that it would protect the process even from, say, for instance, ARIN’s development team, the engineers, system operators; nobody can get into that system and do anything with it without an enormous amount of collusion.

I’m not going to describe all the details of how we went about doing that, but I will tell you that you’d have to corrupt an awful lot of ARIN staff members to be able to get anywhere and to leverage this system.

Are we there yet? Stacy gave away the answer. Yes, we’re there. RPKI services are being offered now through ARIN Online and REST for a hosted model. I’ll talk in a minute about what the hosted model means. We’re generating repositories periodically that contain all the objects in the RPKI.

I talked to the Sys Admin team today and it’s happening twice a day right now. Anyone can be a relying party. Someone floats a ROA in front of you, you can be a relying party and check the validity of the ROA that’s being asserted by the person that’s holding the space.

And any number of validators – and right now there are three of them out there that work well – any number of validators can be used to check the validity of any given ROA.

Now, since we’ve gone on this road trip I took some pictures, and this is how I want to show you the four steps in being able to use the RPKI system effectively.

The first two are specifically going to speak to if you are a holder of resources, how I get a certificate, how I generate ROAs. The last two are going to talk about what if I want to be a relying party and somebody hands me a ROA and I need to be able to do something with it to check that it’s actually authentic.

So those are the four things that I’m going to cover here.

So on to the first one. Taking the first step is to be able to get a certificate. When you go to ARIN Online and you use our system, you can look at your organization information. And when you click on your organization handle or ID, you’re taken to a page that shows your name, address, and all the resources you have.

Everybody who has an ARIN Online account that’s managed their ORG information, you’ve seen that. There’s a new button over on the right-hand side and it says: I want to create a resource certificate. And you can see it here on this slide.

When I click that, a few things are going to happen. First thing that’s going to happen is I’m going to be asked to accept a terms of service. It’s essentially information that’s going to tell you how the RPKI system works, what are the limitations of the RPKI system and so forth. You’ll need to accede to the terms of service, and then you’ll be able to proceed to generating a ROA request key.

Now, the reason you need to do this piece is because we need a mechanism for knowing later that it was really you that came along and wanted a ROA actually signed.

So, by generating this key material, you’re going to hold onto a piece of it. We’re going to hold onto a piece of it. This is how we’re going to know you’re you later.

So you’re going to generate using the instructions that I’ve linked to here – you’re going to generate a key pair. And the private part is going to be kept on whatever computer you do this on, and the public part only is going to make it to ARIN.

Now, this is something that everyone will need to do if they want to participate in the RPKI.

When you go through this process, and it’s not complicated, but there are a few steps to it, and we’ve got them well outlined, you will end up with a little piece of a text box which you can see right next to the “looks like” there. It’s a bunch of gobbledygook, but it’s important gobbledygook. So you don’t want to mess with it.

And you’re going to take that and drop it into the page that you had arrived on and submit it. When you do, you will end up in a couple of minutes after our system does its chewing on it – it’s going to come back and give you a certificate.

And, as a matter of fact, in this display you can see – and this is where I’m going to struggle with my eyeballs, because this is a little bit on the small side for me – you’re going to see that this particular certificate, this is actually one of ARIN’s certificates.

ARIN – of course, we hand out number resources. But the other thing we do is we actually run an operation. We run networks. We have servers. We do all that stuff.

So we’re eating our own dog food. We have a certificate that we applied to ourselves for. That was fun. Then what we did was we went along and you can see the results of that certificate request right here. I know the ARIN ops organization now has a certificate and is a player in RPKI land.

That means we can now go forward and we can create ROAs, which is what that button on the right says. So we’re going to proceed to that next step, which is create a ROA.

To create a ROA, the first thing that I’m going to do is I’m going to arrive at a page that contains a request about what kind of an announcement do I want to put into the system.

Now, the important part here is you’ll notice at the bottom there’s a yellow block that says your key isn’t loaded. What key is that? Remember a couple of slides back – I’ll go there – when I said you need to generate key material? Yeah, it’s that key.

So whatever that private key was that is sitting on your computer, now what you’re going to do is you’re going to load that key into the browser. This is one of those mechanisms I was telling you about that you can load this into a browser and it uses some AJAX goop to be able to do all of this work for you.

If you don’t trust that, that’s okay. You can click on that other tab over there that says I want to submit my own signed ROA and you can do it the hard way, if that’s what you want to do.

But this process works very cleanly and it does not divulge your private key to ARIN under any circumstances here. Okay.

So let’s say that I’m going to use this process. I go ahead and I say, yeah, I want to load that up, and you can see it’s going to pop a window open that says so point me at your private key.

I’m going to go and point at that private key. Once I select it, it’s going to say, yes, I got it and it’s loaded. If it doesn’t turn green, you probably picked the wrong one or you gave us the wrong file.

Once that happens, you can put in the rest of the information for your ROA, which prefix, for instance, you want in the ROA, what AS number you want to be allowed to announce it. And then you can hit the button, and when you do it will say now this is the ROA we’re going to make for you. This is important. This is the ROA we’re going to make for you. You need to review this and make sure it’s right before you submit it.

Once you submit it, you’ll get a little notification that you have a little ARIN ticket, and the little ARIN ticket will float down to ticket land. It will do its thing. And about two or three minutes later it will come back and say: All done. Your ROA is complete. You’ll see a message in your message center and you’re the proud owner of a ROA.

That ROA ends up in the repository. We generate that repository I showed you a little earlier, and that repository now contains your ROA and your certificate.

That’s now going to be published so that any relying party can look at that information and validate that that ROA is good.

Okay. Now, on to what if I want to be a relying party? So jumping over to the I’m just a user side instead of I hold address space side, let’s say I’m an operator and you come to me and say I really want you to announce this and, oh, by the way, here’s a ROA and it’s signed.

Well, I don’t know to trust you. But I have a way to verify that, and this is how you do it.

It’s a really straightforward and simple process. You go to ARIN’s website, you follow the links through Manage Your Resources. You can go down and read the RPKI stuff, and down there on the bottom there’s a part about becoming a relying party.

Now, you can do this if you have an ARIN Online ID. You can also do this if you don’t have an ARIN Online ID. Either way, you can do it. You don’t have to be an ARIN customer.

Like I said earlier, anyone can be a relying party. So you arrive at this page and it essentially is going to present you first with a very straightforward relying party agreement that basically kind of describes, A, if you’re going to rely upon ARIN’s system, this is how ARIN’s system works.

I’m not going to read that to you. It contains a bunch of legal stuff. But when you click yes, I understand what I’m getting into here, and it’s not a big getting into, it’s going to take you to a page that says, okay, we just want to know who you are.

All you have to do is give us an email address like [email protected] , something like that. It’s also going to ask you the hardest part of this entire process, which is to do math, so that we know you’re not a robot.

So it’s going to ask you a simple math question, like today was what’s 0 plus 9. I think I got it right. And when I did it says: Congratulations, I just e-mailed you what’s called the Trust Anchor Locator, or TAL. The Trust Anchor Locator is the actual location. It’s a URI that will take you to the location of the Trust Anchor Locator. That’s where the Trust Anchor is.

Remember in the slide about 15, 20 slides back we had a Trust Anchor at the top of that allocation hierarchy? That’s the Trust Anchor you’re getting.

Once you get that, you’re halfway there. Here’s the rest of the way. You then need to get a validator. Now, on our RPKI pages, we have a list of the validators out there.

Today, I chose to use RIPE’s validator. Kudos to the RIPE folks. This is good stuff. The RIPE validator, and you’re looking at it right here, a sample of the output from it. You download the RIPE validator, install it, and you tell where the TAL is, that Trust Anchor Locator. The validator can now go and get the Trust Anchor and use it to validate all your content.

So you pull the repository. You’ve got the Trust Anchor. You start up your validator, and now you look for the ROA that you’re trying to make sure is actually legit.

And you can see right here, there’s a bunch of ways you can get to the data. You can sort and select and do all kinds of things. But you can drill right down to see that AS 65000 for 192.200/24, I see it in there, it’s valid, and I know I have a good ROA and now I can rely upon it.

Now, I’ve described this in a lot of relatively mechanical terms, but it should be fairly obvious that a good deal of this is very automatable. So you can rapidly get to the point where you’ve got a body of ROAs that you can rely upon to be able to make routing decisions with.

So where do we go from here? Now that we have a mechanism for you to be able to generate ROAs, and a mechanism for people to be able to rely upon ROAs, what do you do with them?

Well, that validated content can be used to make decisions about routing, and there is a variety of work in this area in and among different working groups and folks.

I’m not going to describe them all. But, for example, one of them that you may want to take a look at is that you can learn more about how you can transfer RPKI data into routers using a protocol that’s an Internet draft called the RTR (Protocol), and RTR can be found at that link there at the IETF, and it’s a way to be able to get content from the RPKI and actually use it in a router.

There’s other mechanisms and other thoughts in this space. This isn’t the only one, but this is a good source to learn about so how could you do it this way?

It’s important for me to repeat, though, that local decisions always apply here. You don’t want to use that technique, you want to use another technique, you’re totally entitled to do so. Operators can do whatever they decide with their routers.

Alright. So what’s left? As I’ve been reminded a couple of times: So are we done? Or are we done done? We’re not done done just yet, because there’s a little more to do here. We are currently actively in development of another way to participate in RPKI.

Right now you can participate in RPKI using what’s called the hosted model. That’s where ARIN essentially does all the hard work for you. We run a certificate authority. We store the keys inside of the hardware security module that nobody can get to and if you look at it cross-wise, it blows up. That protects everybody’s key material. We are doing all that hard work for you.

But there are folks who are going to want to run their own certificate authority. And if you’re the kind of folk that want to go do that, you’re going to be able to do that once we complete the delegated model.

The delegated model actually lets you establish a trusted relationship with ARIN but pull information from us so that you can then go do things with it and run your own CA.

It will require a protocol for you to be able to gain the authority to do this using your 3779 cert that ARIN issues to you, and it will give you that ability.

That’s what I have to say for today about RPKI. I realize I ran through that very quickly, and you may have questions. I can entertain a couple of them now if I have time. John, are we good? I didn’t have my clock out. I’m not sure where we are.

John Curran: We’re good. Go ahead. Microphones are open.

Ralph Bischof: I’m with Ralph Bischof. I’m with SAIC and NASA. One of the questions that always comes to mind when I see something like this, especially when you’re talking about a shared key pair and such, is the actual mechanism of validation.

Have you done any type of tests or things of this nature to show what type of load you’re actually putting on? I assume the load is on my public-facing routers.

Tim Christensen: First of all, I’ll caveat that with I’m not a router jockey and don’t play one on TV. But largely there’s been two thrusts of work – and I saw Sandy Murphy line up behind you; she probably has something to say about that.

There have been two thrusts in the arena basically, Ralph. One thrust has been do the validation offline, get content, and just use routes I like, for lack of a better term.

No crypto happening on public-facing routers. But more recently there has been some work that I’m going to let somebody else describe that actually attempts to do some of the crypto work and some of the validation inside the router.

I know and have heard that large router manufacturers have been doing some work in this area. I know that there’s been some protocol work in this area as well.

I’m not hypertuned into that, but there are people in the room who are and they may have comments about that.

Vint Cerf: Vint Cerf again. That did go rather quickly, I must say. I would also say that what you’ve described is what we would see, which I think was your intent. What that doesn’t necessarily tell us is more about what’s going on inside. Now, I’m sure there must be a bunch of RFCs that describe a lot of this.

Tim Christensen: You bet there are.

Vint Cerf: However – however, an RFC doesn’t necessarily say much about the actual implementation.

So there’s really three pieces here: It’s what we see, what processes and steps do we take to make use of the system; and the other one was what were the basic specs; and the third one is, for the systems you’re describing, what can we know about how they’re implemented? Is that kind of information available for scrutiny?

Tim Christensen: Yes, it is. And that’s published through the CP and the CPS. And those are both publicly available.

Now, the CP – and Sandy may correct me here, but I believe that the CP is a cohesive document that everybody played together with in the CIDR working group, right, and then each of the Trust Anchors’ certificate policy statements will describe exactly what those mechanisms are. And, yes, that’s available.

Vint Cerf: So before you answer, it would be nice if there were a concept of operations somewhere, even diagrams of what’s supposed to be going on.

The second question is: Have interoperability tests been done to show the generated certificates for – that are done by multiple parties actually interwork correctly?

Tim Christensen: Yeah. The validators cover that ground. So the answer to your second question, Vint, is yes. And point well taken on the concept of ops, like a “you are here” picture.

Sandy.

Sandy Murphy: Sandy Murphy, SPARTA. I’m getting pointed to because I’m the only co-chair of the CIDR working group who is actually here. Chris Morrow wasn’t able to attend.

Let’s see. Crypto on the routers. There is no requirement for crypto to be done on the routers. The generation of certificates can take place offline.

The download of the certificates and validation of the certificates can take place offline. What the router needs is the origin and the valid – I’m sorry, the origin AS and the prefix.

And the RPKI router protocol is a protocol designed to talk from where you’ve downloaded all this stuff to the router and just pass it, that little snippet of information that it needs.

If you are using the RPKI data to generate filter lists, that’s another possibility.

You could use RPKI data just when customers come to you and you want to look it up someplace.

So there’s no requirement in origin validation for crypto on the routers. And, as you said, there are major router vendor releases which do that.

There’s work going on in the CIDR working group to go past origin validation to full path protection. That’s another thing entirely. It’s not the origin validation part.

Specs, there were RF – a draft of 12, 13 RFCs issued in February of this year that describe the architecture, the res-certs. Is Geoff here? Geoff did like the majority of those RFCs. He was a co-author. So any questions about the res-certs – I’m sorry, the resource certificates, go ask Geoff.

There is a document that’s called the Origin Ops document, which is some guidance as to how it’s envisioned that people might be using the information that’s in the RPKI.

Did I miss anything? Was there something else? Oh. CPS. The CP is explicitly mentioned in each certificate. So all of the resource certificates have the same certificate policy.

There’s the Certificate Practice Statement, the CPS, and that differs with everybody who is signing certificates. So ARIN has –

Tim Christensen: Exactly. Ours will be different from RIPE’s and so forth.

Sandy Murphy: Yes. I’m sorry, that was answering questions. I did have a question.

Tim Christensen: Sure.

Sandy Murphy: RIPE and some other folk who have been generating certificates have noticed that sometimes people haven’t quite understood what the ROAs they were creating were saying.

And they added another step to go look at the routing table and say we’re about to create this ROA for you, the following currently announced routes would be invalid if you created this ROA. Are you sure? And RIPE started that, and the open source implementation does that also. There are two different pieces of code that I know of that are open source. There may be others.

John Curran: Is that a suggestion of a feature enhancement?

Sandy Murphy: It is indeed. Other people have found this to be a prudent thing to add as a service to their members and a service to the certificate requesters. It might be useful.

John Curran: Seems useful if someone’s playing with a gun and bullets to tell them which direction to point it.

Sandy Murphy: Someone I know who happens to be standing in front of me talks about playing with sharp swords.

(Laughter.)

Ruediger Volk: Ruediger Volk, Deutsche Telekom. In other areas I’m known to be a pain in the butt for RPKI work, because I always have something to complain or to ask for.

Well, okay, you’re not too really done yet.

But, well, okay, let me first chime in on the CP, the CPS comments. First of all, the CP is one of the RFCs and is well known.

However, it has been, after much scrutiny, published or, well, finalized – publishing always comes later – quite some time ago, and what I’m seeing is that the concerns that the CA operators such as ARIN have when turning the system actually into production may actually warrant that we do a little bit of review whether we actually cover all the things that came up when people went really serious.

And, well, okay, that may be very important because with the current – with the existing CP, we may end up in a situation where the variations of a CPS of the various CAs, plus the terms of service that each of them may impose, gets to divert and for the whole system and the poor relying parties will be the huge majority of the players, and many of the relying parties will not want to get to become experts, will not have a real chance to seriously understand what they are getting into. Something that’s been seen as a very evil thing for the standard SSL certificates in the past.

Okay, just that mentioned, and, well, okay, actually this comment comes from my looking at what the ARIN terms of service are, which came as a little bit of a surprise and did not match exactly my model of expectation of the whole system.

Well, okay. Good stuff. Good intentions. And unfortunately more work. So let me throw a few nasty questions to you, Tim.

You had a slide that showed an ARIN member subdelegating address space. Does the ARIN-hosted CA actually support creation of certificates for such subdelegations?

Tim Christensen: It does not yet.

Ruediger Volk: Another point for the path yet to come slide is I didn’t see – I didn’t see any mention of targets for doing a single root Trust Anchor. I think it would be nice to actually publicly say, yes, we are committed to this and we want to do it and, well, okay, then maybe actually more work.

John Curran: So I’ll answer. I think this came up before. The RIRs are working – also working with our friends at ICANN to spec out what a Global Trust Anchor would look like.

And once we spec it out, then we will then turn around and contract probably the back end to have them produce that if the RIR community says they want it. But there’s a little bit of work involved in making that happen.

Some people will note that ARIN threw a wrench in that work because our Relying Party Agreement says you don’t get our Trust Anchor without signing the RPA and that would be a property that would needlessly have to be propagated at the Global Trust Anchor level.

So it’s a work in progress, and we’re working on it. We haven’t given up the vision of a Global Trust Anchor.

Ruediger Volk: Thanks, John. Let me suggest that – actually, I think some of the requirements that you are discussing for doing the root Trust Anchor I think could be candidates for going into a revised CP.

So I would very much suggest that you not only do your negotiations and figuring out all of the nasty and hard details behind closed doors but at least bring those parts that may be of interest for enhancing BCP, and maybe I think from the drafts we dropped the CPS template thing that once was around.

Maybe we actually want to revive doing a document that gives a standard starting point for a good CPS.

Okay. I guess Sandy will be happy to provide you with slots in Atlanta in two weeks.

John Curran: Two weeks is a little soon, but we are going to be working with the SIDR working group for anything that comes out of the RIR ICANN work on a Global Trust Anchor.

We have said we will work with the IETF on the SIDR working group on some – there are technical issues involved in generating that that we want to make sure the community understands how it’s built.

Geoff Huston: Geoff Huston, APNIC. A really quick comment. Part of the work that we’re currently doing jointly with RIPE is to actually work on a common user interface.

It’s often the case that a tool looks like it’s a user interface, and we were certainly concerned that we were starting to develop five different training things, five different views, and certainly with APNIC and the RIPE NCC we’ve decided that we’ll actually try and see if we can actually produce one look and feel of this sort of hosted environment that then allows us to do a single training material and actually create a single view. And certainly as you progress with your interface, you may want to have a look with that work and see how it chimes in. Thank you.

Mark Kosters: I actually have a point of clarification I’d like to make. That is, we will only sign resources – by the way, I’m Mark Kosters, ARIN CTO. We’ll only sign resources where we have a direct relationship with that particular organization.

So if that resource is downstream from – it’s reassigned to someone else, we will not sign that. We will only sign ISP, which we have a direct relationship to.

John Curran: I do have to tell people we have one more presentation and the Open Policy Hour, and it’s 5:16. So I’m going to close the mics. If you’re going to speak on RPKI, definitely get on the mics now. Going to close them in a minute.

Go ahead, Sandy.

Sandy Murphy: Sandy Murphy, SPARTA. I suddenly realized that if I’m ever a witness at a terrible accident and someone from the media comes up and puts a microphone in my face, I’m going to say: Sandy Murphy, SPARTA.

(Laughter.)

Sandy Murphy: When Ruediger asked the question about Global Trust Anchor, I think it came up before. I said before I was the one that brought it up, I’m piling on, I realize there’s another question that I always have to ask.

Okay. So ARIN is now in production on RPKI. And so is APNIC. And ARIN and APNIC have a common inter-RIR transfer agreement. Have you worked out how that’s going to work with RPKI?

John Curran: That actually is the largest portion of some of the work going on between the RIRs right now, is how to handle the little issues that we handled in DNS. Because this same thing, hierarchy and pieces going back and forth, have occupied us for several months with DNS, particularly with inter-RIR transfers and ERX.

Trying to do the same thing with certificate chains turn out to be really amusing, like what signs what and where you swing the chain. And so that’s what we’re working on before we do a Global Trust Anchor is making sure we understand that model. And that model is something we need to validate with the IETF.

Sandy Murphy: Thank you. I always like to hear the answer.

Vint Cerf: Vint Cerf again. Just a short question for anyone who is prepared to respond. This might be a Geoff question.

You showed a lot of user interaction screens and things of that sort. Would there be any utility in having a more mechanical interface that would allow much more automated generation requests for and generation of these certificates? I’m just thinking about scaling and wondering whether the moral equivalent of the command line interface that a computer could generate would make any sense.

Tim Christensen: So I’m going to ask if our Chief Engineer, Andy Newton, wants to address Vint’s question.

Andy Newton: No, Geoff, you can go ahead and answer.

(Laughter.)

Andy Newton: So Tim alluded to the REST interface which we will use to allow people to leverage to create tools to automatically create certs in the hosted CA.

The other thing is once you get into a delegated model and you have people running their own CAs, then they’ll have their own tools available for doing it. And it’s however that the vendor of those tools allows them to create their CAs and ROAs and so forth.

Does that answer your question?

John Curran: Okay. I’m closing the mics. Tim, thank you for that demo and handling the Q&A.

(Applause.)

John Curran: Okay. We have one last session. It’s actually two parts. It’s the Open Policy Hour and Open Microphone.

Open Policy Hour

John Curran: Open Policy Hour allows parties who want to raise an issue for further consideration to do so at this meeting related to number resource policy.

We’ve only had one folk say they want to speak. That’s Matt Pounsett. Matt, are you here somewhere? You have slides. And then once Matt’s done we’ll go to Open Microphone.

I don’t see him. That’s interesting. What’s amazing is I probably could do these slides. Is he coming? Okay. Why don’t I start off with the issue, because I know it pretty well.

There’s this group called ICANN, and ICANN made a decision to do some new gTLDs.

And there’s going to be – well, there’s 1900 parties who have applied to have a new gTLD and some 1300 unique strings being fought over, estimated 300 to 500 organizations that are fighting over the 1300 unique strings out of the 1900 applications.

No matter how you look at it – hey, look at him. I was going to do you first – no matter how you look at it, this going to be exciting, if you consider the critical infrastructure and issue them address blocks.

Matt Pounsett: Sorry about that. So a bunch of people know who I am. Some don’t, I think. I’m Matt Pounsett. I’ve been around ARIN for nine years. I was on the AC for a while.

Haven’t really had time available to myself to run for the AC lately, but I noticed recently that we haven’t had an official bad idea fairy in a while, so I thought I’d audition for that today.

I work at Afilias. It’s a domain registry. We’re the registry operator for Info, Mobi and Pro, which means we have these delegations directly from IANA.

We’re also a Registry Services Provider, which means there are registry operators who contracted us to run their technical operation for them.

The reason I bring this up is so that I can point out these two, which are actually new TLDs. Even though they’ve technically been around for a long time, we’ve just brought them online for the first time in the last year.

So we have a little bit of experience with bringing new TLDs online recently. Even though it’s under the older procedures, we’ve run into a couple of issues with those that brought up issues that we think existed with the new system.

And some of those are conflicts between what ICANN would like people to do and what ARIN needs people to do.

So a week ago I thought I was going to be giving a very different presentation here. We had run into a problem where ICANN was going to require us to have nameservers up and operating.

In fact, our entire registry infrastructure up and operating for a new TLD before giving any clear indication that the registry would actually be receiving that TLD, which made justifying address space for any of this work with ARIN essentially impossible.

In the last week or so we’ve got a bunch of clarifications from ICANN, and things have sort of straightened out in that regard.

So we have new procedures. This is how things will run. The first thing that happens after ICANN sorts out all the objections and conflicts and all those things, we get down to the point where they have a fairly good idea of who they’re going to give a particular name to.

And the first thing they do there is they provide what they call a notice of eligibility. It’s essentially a letter of intent to the registry operator.

Next thing after that, contract negotiation takes place. But most importantly it’s not signed. It’s to make sure that ICANN and registry operator can come into agreement on what’s supposed to happen.

Then they do predelegation testing. And at this point the registry needs to be up and operating on the production addresses that it will live on for the foreseeable future.

And then the contract signing and actual delegation happens. So this is happening in a bit of a slow rollout. ICANN’s releasing these, they’ve said, at a rate of about 20 a week for the next couple of years.

So that’s 20 notices of eligibility going out a week. And for the very large service providers, very large registry operators, this could mean we’d be going back to ARIN several times a month for address space.

Now, the problem here is the critical infrastructure policy is the only place where we get the option to do anycast DNS. There’s really nowhere else in the policy where a registry operator can obtain address space; no matter how many TLDs they’re putting on that address space, we’re using one address out of the set of /24s is kind of considered acceptable.

The issue is that this policy was really never intended to cover a situation where there would be a massive increase in the number of TLDs over an extended period of time.

In this case registry operators are starting to look a lot more like service providers than end users, because of the way this is being rolled out.

So the policy gap here that we see is that ISPs are able to justify resources based on their planned expansion over a period of time. But because of the way that the policies are – and procedures, more importantly – written, TLD operators have to justify the resources they need based on each individual TLD or each individual client, after that client is already there and waiting for their service to be up and running.

And we feel this is a problem. So the result that we’d like to wind up with is that registries and registry service providers would like to be able to go to ARIN and say, look, I’m going to have – I expect to have this much service that I’m going to be running over the course, by the end of this year. There’s a certain amount of it that is – what’s the word I’m looking for?

We know for certain that we’ll get a certain percentage of what’s being requested. We can plan for – we plan for a minimum, and then if we have to expand, we can do that.

So we’d like to be able to go and request this in few requests for larger sets of address space, essentially.

So a proposed change to policy. I’ve written this out as a proposed change to policy because it’s easy for me to do that.

There are possibly ways for this to be addressed in procedure. But that would still require direction from the community to ARIN for that to change, because this is the way it’s been for so long, this is the way the community expects it to work; it’s unreasonable to expect ARIN to change their procedure without significant input from the community.

What I’m suggesting here is an additional subsection for the NRPM 6.10.1. It’s the section that covers critical infrastructure for microallocations.

In this section there will be a exception that says ARIN will accept as justification for DNS critical infrastructure one or more applications under ICANN’s gTLD application process.

Currently ARIN would be expecting this letter of intent as justification. Under this proposal, simply having the application would be enough to initially get resources.

Resources allocated under this section would not be allocated from the free pool or the critical infrastructure reservation. This pretty much means that anyone who wants the privilege of using this extension to the proposal would have to go to the transfer market.

And, finally – to make sure that this can’t be used easily for any sort of speculation – if resources that were justified under this subsection of the policy are no longer justified at the conclusion of the ICANN process for that particular TLD, for example, if it’s awarded to another organization or not awarded at all, then the resources that were justified by that TLD in the initial request would go back to ARIN.

(Laughter.)

Matt Pounsett: Fully expecting that I’m going to have – yeah, thanks.

John Curran: Microphones are open. I want to make one thing clear. We’ll take – the point I wanted to make clear is that the current gTLD process, we would have an impossible-to-solve problem if we wouldn’t issue address space under critical policy until they were under contract since that happens after testing on production addresses.

So we will accept the letter of eligibility that ICANN issues to say you’re going to be a critical infrastructure operator. But that does still mean these come out only after they’ve been through objections and considerations and they dribble out to individual operators one by one.

A proposed change like this would mean anybody who applied and paid the fee could immediately come to ARIN and say I’m going to be getting a block. Now, they’re going to be transferring a block I see; they’re not going to be getting it out of the free pool. But I just point out that there’s 1900 applications out there right now.

Microphones are open. I want to spend ten minutes on this because we still have the Policy Experience Report and Open Mic.

So ten minutes. Go ahead.

Matt Pounsett: I think you were up there first, Louie.

Louie Lee: Louie Lee, chair of the ASO AC. What’s the expectation for the duration between the application and the award? And maybe there should be a kind of timeout so at some point the person, the entity will have to rejustify just to show that it’s still in process rather than something happened and it withdrew.

Matt Pounsett: Probably not a bad idea. It’s potentially quite a long time. It’s part of the problem we have. So I’m a DNS operator. I’m not in the names registration part of the organization. And so I’m not as plugged into everything that’s going on there as some other people.

But my understanding is the applications are essentially in now. And in some small number of months, ICANN will start handing out these letters of intent, hand out a few a week.

So there could be a year, maybe longer for some of the extreme cases, between when the application was submitted, or in this case since most of those applications are in already between the time when the address space might be requested and to when the application would be finalized, contracts signed, all that.

Vint Cerf: One small point. I think it sounds pretty pragmatic, so I would be favorably disposed to pursuing this path.

I have a question about the term “critical infrastructure,” and I’m nervous about it because it’s become a term of art in the Homeland Security/national security world. We might want to consider whether that term is the best one to use. I don’t suggest we debate it here. There are some side effects.

Matt Pounsett: There’s a decent argument to be made that we need to refine that definition.

I deliberately did not raise that question here. So I’m – what this is intended to do is modify the existing policy as little as possible in order to get sort of an entire segment of the industry moving.

Paul.

Paul Vixie: Paul Vixie, ARIN Board, speaking for myself. ICANN is in the process now of making the root zone look as much as possible like the dotcom zone, and in so doing they’re changing what it means to be a TLD, where it used to be the TLDs were probably critical infrastructure in the sense that we use that term in this room.

But that, I think, is not going to be true. So I challenge the need for this proposal because there’s no criticality here. If .beef doesn’t work, it doesn’t mean that everybody in the world has a bad day.

To the extent that it was critical infrastructure, I question why we need unique IP address blocks for each name server of each new gTLD.

I think that it should – anyone who applies for address space for this purpose, assuming it was still called critical infrastructure, should have to explain why they can’t share address blocks among several or more than one, at least, or many different new GTLs.

And I want to point out again, as I did the other day, that if every time ICANN releases another thousand names into the dot zone, we all have to tolerate 10,000 more routes in the global routing table. That’s bad.

Matt Pounsett: So your first question regarding critical infrastructure, I agree, and it’s unfortunate that this is the language that we are currently stuck with. We should fix it.

I think it’s impossible to argue that com, net, for example, are not critical infrastructure. I think it’s equally impossible to argue that ccTLDs for various political and economic reasons are not – should not be treated as critical infrastructure.

It’s probably hard to argue that dot fishing – I don’t even know if that’s an application – is critical infrastructure. That’s an impossible argument. But there’s probably going to be, over time, some sort of – there will be a range in there eventually, I think.

But, as I said, it’s worth refining what we consider to be critical infrastructure.

The issue we have here is not really that it’s critical infrastructure, it’s in order to do anycast DNS. Operators need the ability to make allocations where no matter how many TLDs we’re running on that /24, we’re still only raising one address out of that /24. And that’s really what’s at issue.

So your second statement about the – operators are being responsible will group things, both for their own financial reasons and for the good of the community.

I would hope we don’t see a situation where we have operators running many TLDs all within their own unique sets of address space. I’m not sure how to put that into policy to make sure that it can’t happen. But I would hope that ARIN staff, in looking at justifications for address space, would take that into account and allow what is realistic.

John Curran: I am closing the mics. We have another topic before 6:00. If you’re in the lines, you’re good. But don’t approach the lines. Only those in the lines.

Andrew Sullivan: I’m Andrew Sullivan. I work for Dyn, and I’m occasional ICANN weenie. So I have two questions.

One is, is there a special reason why you decided to stick only with gTLDs here? Because ccTLDs presumably have this problem too. I’m just nervous about enshrining too much of that distinction in this policy.

And the second thing is, how does this work the next time ICANN does this? Because of course there’s no plan on ICANN’s part not to do this again.

Matt Pounsett: cc’s, as I understand it, are not part of this new process. They would be treated the way TLDs have been treated up until today. And essentially that means that once – there’s also another difference in that they are typically not rolled out in the hundreds per month.

So the ability for an operator to take a little more time with it is a little more reasonable, and there’s also the – as I understand, the order of procedure would – for those would be much more like it’s been in the past where a contract is signed well in advance of a delegation actually occurring, where that contract can be given to ARIN as proof that the resources are needed.

Yeah, it’s a very different process. So, I’m sorry, your second question?

Andrew Sullivan: The second one was related to what Paul was asking; that is, there’s no reason –

Matt Pounsett: Next phase. Next round. I don’t know. A part of the reason I’m proposing this this way is we have very limited time to get something that registry operators can use.

There are probably better ways to do this. I would love it if somebody can suggest something that doesn’t risk our resources quite so much. I’m not sure what that is, though. So I think with another year to look at it or maybe another two years before the next round, we could probably come up with something a lot better.

And if Geoff’s projections are right, may not even be an issue at that point, and we may just be able to run our DNS servers all on v6 and be done with it.

Ed.

Ed Lewis: Ed Lewis, Neustar. I’m kind of following up with what Paul was alluding to, too, is that you’re not going to need a new set of blocks for every TLD. Operators are going to be running many TLDs, and they might be able to put more than one TLD in one block.

So I don’t know the scale of the problem is that we have 2,000 new TLDs, we have to have space for 2,000 new things. I’m just questioning the size and the need for having – for making this change. I’m not saying we don’t have the problem, but I don’t know that it’s as bad as saying we have 2,000 new strings to look at.

Matt Pounsett: No, not at all. Like I said, I expect that responsible operators are going to be grouping things up. The trick is that a very large operator may have issues trying to get that address space piecemeal. Even grouping things up.

Ed Lewis: Kind of biases towards the large operators today who already have space. It’s easier for them to bring in more new TLDs. It’s the new operators that need it.

I’m not saying yes or no on the idea, but it’s – the scale isn’t quite as drastic I think as has been painted that the raw numbers are these.

Matt Pounsett: Middle.

Martin Hannigan: Marty Hannigan, Akamai Technologies. I don’t think this is such a bad idea, Matt. I think, as Vint noted, critical infrastructure has become a term of art. And perhaps it’s a little too wide in terms of the definition we have in the NRPM and that tightening it up to be more specific to perhaps root servers and ccTLDs, for example, might be the way to go.

Although the reason ICANN is releasing them slowly is because there’s unknowns. We really don’t know. It says, sure, it’s going to work, no problem. They could probably load them all in. And when you think about queries and things like that, they’re just going to change to the destinations. The volume may or may not go through the roof. I don’t know.

But I think that taking this approach is probably a bit more cautious than perhaps saying expand the CI reservation to a /14 or a /13 or /12.

Although, I think there’s probably a hybrid approach here. I think that tightening the CI definition is a good step.

I like your idea about the – here on point one, but I think the gap between “ask” and “use” is probably a little too wide and perhaps the right step is the LOI. Although, I think you said the LOI comes way too far in the process.

And ensuring that we do have some in the event that this is a fail, I think that we still should look at the amount of reservation for CI just in case we have to actually do something, which I really can’t see why we would. But better safe than sorry. Thanks.

Rob Seastrom: Rob Seastrom, Time Warner Cable, ARIN AC, and I used to work with Matt. I’ve talked with Tom Daly and talked to my colleagues back when I was at Afilias about this interesting dichotomy that we have, and I want to say up front I don’t have an answer to this.

This is just something I want to throw out here for people to consider, is that to allow this for something like dot burger to be critical infrastructure, yet an anycast DNS service bureau like DynDNS, for instance, that has millions of customers, doesn’t count as critical infrastructure. That creates an interesting dichotomy.

We see what kind of problem multiple people have when big shared platforms like, oh, let’s say, for instance, EC2, to name something that gets sick on a regular basis, is unhappy.

You see the ripple effect through all sorts of hosted things.

And I think that inasmuch as anycast DNS is good for dealing with one particular DOS attack, that that’s something that we need to think about, whether this is something that we would want to expand in the direction of being able to accommodate those sorts of folks.

The other observation I wanted to make was in response to Paul’s comment about segregation of space.

It’s not always possible, and the result, the reasons for that are often layer eight and nine.

I have the dubious distinction of being the guy who actually turned up .xxx as in put the routes in the routers. And we weren’t allowed to do that on other prefixes for the test period. And because we were concerned about certain governments and certain countries deciding that those /24s were going to be permanently bad and do bad things, that would have collateral effect on other customers. And you can’t predict all of that sort of thing in advance.

So I think that there needs to be a certain amount of latitude on ARIN staff’s part to address legitimate concerns that DNS operators – I’m not going to say TLD operators, because I personally think that we ought to figure out a way to extend this without creating an environment where things can be gamed – to address legitimate concerns that these operators bring on a case-by-case basis.

Thank you.

Matt Pounsett: Yeah, I would agree. Part of the problem of trying to combine too many TLDs or indeed too much of any DNS infrastructure onto the same set of anycast addresses is the shared fate problem.

That using our two latest ones as examples, if we had put up .xxx and .post, which, by the way, is the TLD of the Universal Postal Union, who is responsible for getting your mail from one country to another, if those two TLDs were on the same address space and .xxx came under attack, post would be down as well.

Rob Seastrom: If those two were on the same address space, the jokes would again just write themselves.

Matt Pounsett: They would, yes. So we separate things. So we separate things as much as is reasonable so that when one thing comes under an attack, we can, if necessary, completely withdraw its routing announcements to make that attack go away and allow the rest of our infrastructure to continue to operate.

Jason Schiller: Jason Schiller, Google, NRO NC. I wanted to plus one R.S.’s comments, but it’s not just shared fate in terms of DOS attacks, it’s also shared fate from a maintenance perspective.

So it’s not clear to me that a DNS operator is going to want to coordinate all the maintenance activities of one or two hundred gTLDs at a particular location in terms of pulling the anycast address down in order to do maintenance.

But beyond that, I also wanted to point out that our current microallocations for critical infrastructure policy states that these come out of specified blocks out of known ranges. And the reason why we did that is for filtering purposes.

Now, one might argue that pretty much all ISPs on the Internet route /24s today. And that may very well be true. But as routing table slots get tight, it’s not unreasonable to imagine that some ISPs might start throwing away more specific routes.

And if these new gTLDs are not in known space or not easily aggregated by some larger aggregate you can put in a filter, they may get filtered out. And that could be problematic if we do truly believe that these are as important and as critical as the other things that have come before them.

Matt Pounsett: Okay. Just one quick comment about that, I guess. I think it makes sense. I think it’s been fairly well demonstrated that 24s continue to be routable.

As you say, that may change as the routing table continues to grow. We don’t know. However, having done some quick math the other day, if we do want to do this out of the critical infrastructure allocation, we’re going to have to make that a 13, I think.

So, I mean, that’s a lot of space that needs to be reserved.

Bill Woodcock: First, I admire the ingenuity of this proposal as a way of solving a set of problems in a relatively elegant way. Stepping back one level, this, however, is an example of yet another special case.

And we’re having more and more special cases, and as things get tighter and tighter there’s going to be more constituencies showing up and wanting a special case that gets them what they want.

And I try to always push back when I can towards the general and the simple and the fewer words. And so I’m going to kind of reiterate what I said yesterday, which was essentially that the fundamental problem we’re trying to solve here is people’s belief that if they need one IP address, they need a block of 256.

And that is not our problem.

Matt Pounsett: I disagree. Well, in terms of this particular proposal, I disagree.

If /32s were demonstrated to be routable, I would do that. That still doesn’t solve my problem. My problem is the rate of justification, not availability of addresses.

Bill Woodcock: If they’re /32s, then we can keep going all day out of a relatively small block and it’s not a problem.

Matt Pounsett: It is a problem if I have to justify those one at a time over the course of two years.

Bill Woodcock: Is that ARIN’s problem or is that your business problem where you can pass a charge along to your customer, who has already demonstrated their ability to pay $185,000 for a paperwork fee.

Matt Pounsett: Fair enough. And I think it’s an excellent idea. If we can demonstrate that that works, I’ll do it. That would actually even simplify a lot of my internal operations, but I can’t be the experiment. So I need somebody to demonstrate that that works.

Bill Woodcock: We need, like, a class of people we can experiment on that we don’t like very much. No.

(Laughter.)

Bill Woodcock: Just hypothetically.

John Curran: I’d like to thank Matt for coming up and presenting this. Excellent discussion. People interested in pursuing this, find Matt.

(Applause.)

John Curran: People might notice I skipped a presentation because it’s the Open Policy – sorry, the Policy Implementation Report.

I’m going to have – Leslie isn’t here, so I’ll have David Huberman come up and give the Policy Implementation Report, quite expeditiously.

Policy Experience & Implementation Report

David Huberman: I’m David Huberman of ARIN. This is Leslie’s slide deck, and it’s my privilege to present it to you today.

We’re just going to do a quick overview of some policies that we’ve implemented that you’ve passed that the Board has ratified and let you know how they’re working.

The three policies we’re looking at today are the inter-RIR transfer policy; the policy to clarify the requirements on v4 transfers, which can be easily summarized as an anti-flipping policy; and the addition of ASNs into the 8.3 transfer regime.

We have as of two weeks ago completed our first inter-RIR transfer. We took a relatively benign /24 not in use in the North American region and transferred it to Australia where it will be used in a sunny and happy environment.

(Laughter.)

David Huberman: The ASN transfer policy actually had a line of folks waiting for it. And those folks were able to quickly queue up once it was implemented, and we’ve already transferred two of them.

A couple of cycles ago we changed how we do v6 allocations and assignments to be more classful. And so we present a little bit of slides. We’re still giving out mostly /32s, of the allocations we’ve given out since the policy changed. But we’ve given out some /28s and just a handful of /24s to some really large networks.

What’s more interesting is the end users. We’re only giving out about half of the end-user space as /48s now and a quarter of the space is given out as /44s, which I think clearly shows it’s nicely meeting the intent of the policy.

We’re also saving out /40s, /36s, and even /32s. And a /32 is not easy to justify on the end-user policy. You’ve got to be pretty darn large. 582 assignments and a nice stratosphere of assignment sizes.

That’s the end of that.

We’re going to go into something a little bit different. This is an opportunity – this is a Policy Experience Report. And this is an opportunity for the staff to inform the community of some challenges we’re having with requests from our customers where policy is deficient in giving us guidance.

Today, we want to talk about two different things. We want to talk about this idea of efficient utilization and initial versus additional allocation policies as it respects a pure legacy holder. So efficient utilization. What do I mean? I’m talking about spam.

Is the use of IP addresses in bulk to avoid email filtering considering to be efficient use? Let me explain.

We receive requests regularly from small and new email marketing providers and they need a lot of IP addresses. They don’t need a /24; they’re not asking for a /22. They’re asking for a /19, or an /18, or a /16.

And they do this for a number of different reasons. Well, David, we want to assign one IP address per customer and we have 60,000 customers right now. That way we can filter based on reputation.

Also, we have to limit the volume of IPs, of email we send from a particular IP address, because if we send too much we get filtered and then we’re ineffective.

And then there’s the worst-case scenario, which is we want 16 /24s: We’re going to use one /24 on Monday and use a different /24 on Tuesday and so forth. They rotate to avoid filtering.

And the staff get a little stymied here because we’re just trying to do the best thing for our customers. And we look at some of the most successful ones, who I’m not going to name right now, but who you can probably think of.

And if you look in Whois at the most successful email marketers, the ones that everyone in this room knows, they only have a couple of address blocks.

The largest email marketing marketer I know in North America operates their entire business on a /22. So that creates a bit of an ethical conundrum, if you will, for the staff. Because we’re here to help you, help our customers. We’re seeing the successful folks doing the most with the least, and the new folks who want to be the successful ones saying I need everything.

So that’s our problem statement. If a successful marketing company can do it on just a couple of hundred IP addresses, what are we supposed to do as a staff when someone comes in and says I need tens of thousands of IP addresses?

Currently, we’ve had no choice. We have to consider one IP address per device or one IP address per customer as acceptable. Because policy doesn’t tell us it’s not. We don’t think it’s efficient. It doesn’t feel efficient. But policy has no legs for us to stand on and say no.

So our question for you, our challenge for you to think about, is would clear guidance from the community – is it possible with respect to this issue that I’ve discussed?

One more thing to discuss, and this was found on PPML relatively recently: Should a legacy space holder – that is, someone who only has legacy space, has nothing from the registry – they haven’t been here in 14 or 15 years or longer, when they come to us for the first time, should we be reviewing them under the initial policies or the additional policies?

Okay. Here I’ll make it a little clearer. Today – I’m going to skip slides for a second. Today, an organization may have legacy space and they may have efficiently used all of it. But they may not qualify for an initial allocation from ARIN. So allocation, we’re talking about ISPs here.

If you’re a multi-homed ISP and you only have a single /24, you don’t technically qualify for space at ARIN because at ARIN you have to be using a /23 to get our minimum allocation size of a /22. Those are the rules.

Similarly, you could have 15 /24s fully in use but you’re single-homed, you’re only one provider. You don’t qualify under the current policy because you have to have 16 /24s.

The same is true – same is not true for an end user, so I won’t say that.

Today, here’s what we do: We’re reviewing them under the initial allocation policies. If they have enough to qualify, they come in. And if they’re doing it under the multi-homed policy, we just ignore the renumbering because that doesn’t make any sense; they’re not renumbering anything, they’re not returning anything to their providers.

It’s counted towards policy justification and, of course, they must be well utilized.

So when thinking about this, it’s like, all right, well, what if you said, David, don’t worry about it, just pretend they qualify because they’ve efficiently used what they have, they have space from a registry. So use it, justify it. They’ve shown they’re using it, so give them more.

Well, that creates a little bit of a dichotomy here or an advantage here for the legacy holders, because if I just have a /24 and I’m multi-homed and I’m an ISP and I’ve used all of it, David, give me a /22. You can’t do that if you don’t have a legacy block.

So that’s it.

John Curran: Thank you, David.

(Applause.)

Open Microphone

John Curran: Okay. So we’ve seen some interesting issues with existing policy, and there’s AC members out there and you can find them and talk about them and try to coalesce around ideas if you think that’s necessary.

I will open up for Open Mic. I’m only going to keep the open mics open for five minutes, even if you guys are all at the mic. If you wish to speak on one of these or anything from today, five minutes, please. I’m going to close the mics promptly.

Go.

Kevin Blumberg: Kevin Blumberg. I’m going to be speaking not as The Wire, not as a TorIX Board member or an AC member. But in regards to the CI discussion we had yesterday – thank you – the question I had was this: There is a lot of issues surrounding what is critical infrastructure, especially with the new gTLDs.

I think this is going to be a hot issue that’s going to have a lot of discussion and a lot of work. But the one thing that is missing from this and that I’m actually concerned about is what is actually critical infrastructure as far as that overall policy.

And so my question to the audience now is: Should we be looking at carving out IX space for the IX as a /16, as an example, which we do feel is critical infrastructure and separating the discussion between the two?

Because I think that by the time we finish the discussion on the gTLD side, it will be too late for the IXs and they will be left in the lurch.

John Curran: Excellent question. Okay.

Center mic. Go.

Dani Roisman: Dani Roisman from SoftLayer. I wanted to make a comment about the email as efficient utilization. This is a subject matter I encounter an average once a day, although ironically, or curiously, it happens much more on Thursdays and Fridays than Monday, Tuesday, or Wednesday. Can’t explain that.

One point of discussion. When we look at large successful email providers and we look through Whois to try to determine how many IPs they’re using in order to be successful, one of the things we can’t see is how many worker bees, sender nodes they’re utilizing that they purchased from other providers.

We definitely have many large successful email providers which come to us and buy one, two, three servers and put on 16 IPs per server and use those as worker bees, and they will not show up in Whois because we definitely don’t SWIP them out. You’d have to walk everybody’s RWhois service.

So, just to be clear, that the successful folks with small Whois assignments, some of them can only get that many IPs from ARIN, period, and find they can’t get any more and they just go ahead and pick up BPSs and small servers, managed servers as needed.

It’s definitely a topic that needs a lot of focus. It would be really nice to try to – I think we need to quash the practice. But in the meantime, until we quash the practice, I think we all need to agree on how to do it.

Typically what I do, when I speak to the email providers – and, again, this is at least once a week I’m personally speaking to an email marketer or a campaigner – I tell them that what they need to do is they need to recognize amongst their industry that IPv4 run-out is here. And if it’s not tomorrow, it’s a year from now.

And I tell them that any business that relies upon additional access to unique IPv4 addresses for growth is one that is essentially going to be very short-lived.

And I also tell them that what they need to do as an industry is determine a way – to find a different way to determine reputation and authorization to send email that is not hinged on IPv4 addresses. Use some other way to communicate that information, not by IP addresses.

John Curran: Good advice. Thank you.

Rear microphone. I’m closing the mics. Mics are closing in ten, nine – Paul, go ahead. Microphones are closed. Just for people in the queue.

Go ahead, Paul.

Paul Vixie: Paul Vixie speaking for myself. With regard to the scorched earth that Huberman was talking about, I think that policy certainly doesn’t specify this, but it could on the following two bases: Using a different IP address for each customer is necessary if you’re speaking certain protocols like https and you have clients that are busted and so forth, but if it’s not necessary, then it’s not justifiable.

Now, furthermore, if you are planning to use one and then discard it and use the next one and discard it – in other words, rotate through the whole mess – then I would say that policy should require you to be using all of them at the same time in order to be counted as efficient.

John Curran: That would be a great clarification to policy for staff.

Final comment, center rear mic.

Mike Joseph: Mike Joseph, Google. My comment is not about any of the email stuff. Earlier today we discussed a policy concerning private registrations. And I held my comments there because it wasn’t related directly to that policy.

But one thing that’s come up often in our operations has been the idea of private POCs. And I’d like to throw out a thought for the community as to how people here feel about the ability to have technical admin POCs private in ARIN Whois.

Currently the DMR POC is private by default. But to have ROA POCs be private for technical and admin purposes, given that you can publish NOC and abuse POCs, I think it’s actually now mandated on new records.

So obviously no one can get to the mic and comment. So perhaps people can think about this and talk to me afterwards or during open mic tomorrow. But I think it would be a good thing to consider given that the roles of inbound email and interactions with ARIN, which are the tip of domain of technical and admin POCs, are quite distinct from the internetwork communication and basically abuse complaints that come to all of the published POCs.

And I would throw a question out for staff is potentially: Is your view that this would require a policy change, or this would require an ACSP process?

John Curran: The moment you create the ability to have a private POC, you have to make sure that anything that depends on POC is clear in policy. I don’t know if that answers your question.

All right. We’ve got one remote? No. Okay. That’s it for today. We’ve made it. Everyone give yourself a round of applause.

(Applause.)

Adjournment

John Curran: Excellent two days of presentations and policy discussions. Tomorrow we’re going to have our Members Meeting, and that will include reports from the departments, the Board of Trustees, the ARIN Advisory Council.

So I’d like to tell people: Don’t forget the meeting survey. It’s online. And you can win a Samsung Galaxy Note. Very nice.

Vote. If you have not voted, please vote. Again, the elections are open. We’re electing ARIN Advisory Council members and ARIN Board of Trustee members. If you have any questions, see Jud in the election help desk.

Okay. Reminders. Tomorrow, breakfast at 8 AM, meeting at 9:00. The Member Meeting is open to everyone. Come one, come all. It’s where we do the business of the organization, but everyone’s welcome to attend. You can view the meeting materials online.

That’s it. Thank you. I’ll see you all tomorrow.

Network Sponsor

[](http://www.terremark.com)

Happy Hour Sponsors