ARIN XXVII Public Policy Meeting Draft Transcript - 11 April 2011
"This transcript of the meeting 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. "
Table of Contents
- Opening and Announcements
- AC On-Docket Proposals Report
- Regional PDP Report
- Draft Policy 2011-2: Protecting Number Resources
- Draft Policy 2011-6: Returned IPv4 Addresses
- Draft Policy 2011-1: Globally Coordinated Transfer Policy
- RIR Update - LACNIC
- Draft Policy 2011-4: Reserved Pool for Critical Infrastructure
- RIR Update - APNIC
- Internet Number Resource Status Report
- NRO NC Report
- Specified Transfer Listing Service
- Policy Experience and Implementation Report
- NRO Activities Report
- Open Microphone
- Closing Announcements and Adjournment
John Curran: Good morning, everyone. We're going to be starting. We're going to be -- our jabber monitor is a few minutes behind the rest of the meeting but it will catch up shortly.
I want to make sure we get started because we have a busy morning. I'd like to welcome everyone to Puerto Rico. I'm John Curran, president and CEO of ARIN. And welcome to our ARIN meeting.
I'd like to move ahead with some announcements, and talk about the agenda for today.
So, attendance stats. Here is our attendees list. We have six attendees from Canada, 76 coming from the United States, nine from Caribbean, seven from outside the ARIN region, and remote participants 26 at present.
Board of trustees, our Board of Trustees is in attendance at this meeting. That includes Paul Andersen, the treasurer; Scott Bradner; myself, president and CEO; Vint Cerf; Tim Denton, our chairman; Paul Vixie, our secretary; and Bill Woodcock. Bill's arriving a little later on today and you'll get to see him when he arrives.
Advisory Council, I won't name off the 15 names. Members, please raise your hand or stand up. I believe we have every member in attendance or arriving shortly.
The Advisory Council is the one that works on policy proposals. You'll see them in and about the meeting. Their badges identify themselves. If you have any questions about policies, they're a good group to talk to. They're elected from the community at large.
NRO Number Council. Ron da Silva, are you here? There's no way for me to see; he could be standing up right in front of me and I would not see him right now. Louis Lee? Louis probably is, and I wouldn't see him. And Jason Schiller.
The three members of the NRO Number Council, also known as the ASO Advisory Council, sit on a 15-member group, which is a group that works on confirming global policy. So three members from each region, from the five RIRs there's 15 members, the 15 members of the Number Council. I think that's Ron. Ron, is that you? There's one of them, Ron. I can see people back there. Barely.
The 15 members of the Number Council get together and make sure when we working on global policy among the regions that it's actually the same global policy and it means materially the same thing before they send it off for ratification by the ICANN Board.
RIR colleagues. Our RIR colleague sister organizations have sent a number of representatives here. So AFRINIC, Mark Elkins. I know you're here because I saw you yesterday. And from the RIPE NCC, Andrew, Sam, Jochem and Alex. One, two, three, four, I think I got you all. And LACNIC, Sofia and Raúl. And from APNIC, Geoff Huston and Mario.
Very good. And that's good to know you have other RIRs here if you have questions about their policies or practices. We were all allowed to make our own local policy in our region. But there are interactions, particularly as we get into a world where we're running out of IPv4 addresses in the free pool. There's a lot more interactions between the regions than you might have had before. It's good to have experts from other regional policy available.
The ARIN management team is here. I introduced those people at the First Time Luncheon, and I introduced them all yesterday. I'll go through it again today.
Susan Hamlin, who helps run everything, Communications and Member Services, Mark Kosters, CTO, is somewhere. Yes, I see you, Mark. Mary K. Lee in charge of HR and administration. Leslie Nobile in charge of registration services, and Bob Stratton, CFO, is over there.
Myself, president and CEO. Nate Davis, chief operating officer. Could be in front of me. Nate, are you here? Nate is off getting work done. Got it. And Cathy Aronson, Executive Director of Government Affairs, is in the back over there.
Unidentified Speaker: Handley.
John Curran: Thank you. Handley. Apologies to Cathy Aronson.
Fellowship Program. We have a Fellowship Program where we help bring in people to ARIN, introduce them to ARIN and help get our message out to other people in other -- to other people who may not be able to attend ARIN themselves. This includes sponsorship for the travel and meeting costs, obviously.
And we try to pull people not just from one part of the globe but diverse throughout the ARIN region. This time around from Canada, we have Jack Zhuang. Jack, where are you? Yes, thank you.
And Clarence Johnson from Washington University, the U.S. region. Thank you, Clarence.
Okay. Zephaniah Joseph from the Caribbean region, from the Communications Authority.
First-timers, all first-timers got an introduction to ARIN yesterday. Got a chance to meet with the elected representatives and the staff. Learned about ARIN, the RIR system, policy process. We now get to have a prize drawing. So there's going to be a drawing for all those first-timers who were in the room who filled out their surveys. Come on up. And we will draw the name for those people who completed their surveys. I will ask someone from the audience to come up.
Yes, I will ask -- this is a lot harder when you can't see anyone. Bill Darte, come on up.
Draw a name, Bill. This is for all the first-timers who completed their surveys. One of them will get a wonderful ThinkGeek certificate.
Members of the ARIN staff, Board, not qualified for this.
Darren Norman of Microsoft. Darren, where are you?
You will get a certificate. We will mail it to you from ThinkGeek. Thank you for filling out the surveys. They're important to us to make sure we're getting the right targeted information going out.
Okay. So last night we had the foosball tournament. And as a result of having that, we have the prizes. Winners that we have to announce. Without further ado, in the Knuckles of Furry foosball tournament, third place goes to Dan Alexander and Axel Pawlik. Yes.
Pictures of them holding their statues.
Second place, Phillip Eshelbrenner and Darren Norman.
Our number one, number one winner in the foosball tournament, Raúl Echeberría and Bob Stratton. Ringers if I ever saw a pair.
At ARIN we sometimes want to recognize everyone tries hard, and but a lot of people come up first. There's also prizes just for getting involved. And we sometimes have prizes for actually getting involved even if it's that extra effort and you don't score, that's okay.
So the -- at the end of the list Scott Leibrand and John Springer, the Bringing Up the Rear prize. Thank you. Thank you for everyone's effort. It's a good time. We don't do this annually but we try to get to it every now and then.
It's always a lot of entertainment.
Now, programs. Yesterday we had our tutorials. Please let us know if you took a tutorial, whether or not you liked it. We had RPKI for the Internet community, a tour of the new registration services system, and a tutorial on our RESTful provisioning interface how you link to ARIN and do automatic requests.
If you took a tutorial we'd love to have feedback and let you know is it worth offering the tutorial, are there things that could be improved? It's very important to us, it's part of the educational mission of ARIN to get this information out there.
Remote participants. Welcome, remote participants. You have access to the webcast, the live transcript, the downloadable meeting materials. There's an online chat room, one for On the Record, which is the virtual microphone, things you say there when we get to the microphones are open, if you speak, we'll actually have it read at a microphone so you can ask questions and participate in the meeting just as if you were here.
Then there's another room for hands up, which is when we do a show of hands regarding support for a policy or opposition to a policy, you can be identified in the hands up room and be included in the count.
So we count remote participants just as we count people in the room. Again, this is open to everyone interested in policies in this region. You don't need to be a member. You don't need to be present. You don't need to be particularly located in this region as long as you're interested in policies that affect the community.
So it's wide open. We try to give everyone equal participation. You don't need to -- we love to have you here. It's a beautiful place to be, but if sometime you can't make it to an ARIN meeting, remote participation should be an equally good way for you to participate.
AC lunch table topics. When we break for lunch, we found something that's been a little helpful is to get people sitting and talking about a common theme. So we've actually sprinkled table topics at the lunch tables. There will be AC members, members of the Advisory Council there to talk about that particular topic.
So some of these are about policy proposals that are out there. Some of them are about concepts.
So, for example, AC Policy Proposal 126, Compliance Requirement; 137, Global Policy for Post Exhaustion Allocation Mechanisms; Policy Proposal 138, the IPv6 Size Category Alignment; the generic question of LIR versus ISP to connect or not to connect; the question of is the current RIR structure right for the future; and then one ensuring ease of entry into the transfer market.
So at lunch if you see a table talking about something that you're interested in, go ahead, sit down, start up a conversation. We'll have these lunch table topics running today, tomorrow, but not Wednesday because we're gone by Wednesday. Wednesday afternoon, that is.
So today and tomorrow. Step in, sit at a lunch table that might have a topic you're interested in.
Participant survey. In your package you'll find the meeting program and survey. You'll find the Policy Discussion Guide. This is the document that lists all the policies up for discussion at this meeting.
And then also an overview of the Policy Development Process. So you know how we're following that as we go forward.
You'll find a copy of the current Number Resource Policy Manual. The Number Resource Policy Manual is the current set of policies. It's the base to which we're applying the changes being discussed in the Policy Discussion Guide.
And then you'll find a brochure how do I do that, how to interact with ARIN, describing how to interact with registration services or billing or outreach purposes.
So I hope this is all helpful, particularly for the discussions we're about to have.
If you need help working with ARIN, registration services is actually out in the ballroom foyer. There's a registration services help desk. The hours are 8:30 to 5:00 today. They'll be here all week. If you have a particular problem in getting something registered or an application and you want to meet face to face, this is the best time. Swing by. You have a brochure in your program on how to make an appointment. Or just stop by the desk.
Financial services also here. If you want to talk about your bill, fees, send us a note and we'll get ahold of you and meet with you during the meeting. Not a problem.
There's a NewNOG membership desk which we can probably call NANOG now because NewNOG is making great progress.
As people are aware, the community known as NANOG, after many, many years, is actually now setting up a formal structure and working with Merit and ARIN, they actually have organized a membership organization.
They worked with Merit to get the rights to the name, NANOG, and have completed that. So they're now actually seeking memberships. If you're part of the network operator community and you want to support NANOG, they have a membership registration desk. That's a good thing. We find it's easier in the ARIN region to discuss policies that have operational impact.
If there's an operational body that we can go talk to about it. So very essential to having a good balanced policy process.
Okay. Monday night social. Tonight's social is the Salsa Dance, the Take a Chance Salsa Dance. It will take place at the club downtown in Old San Juan, the Latin Roots, from 6:30 to 10:30. Salsa instruction, buffet, open bar and rum tasting. Buses will leave at 6:30 and come back to the hotel between 8:00 and 11:00. Recommend you all get out, come out, enjoy the club, one of the premier clubs in San Juan. It should be a great time. And it's sponsored by the Puerto Rico -- the PR Top Level Domain. So let's have a round for our sponsor.
Speaking of which, we have network connectivity thank you to AT&T. I'd like to give a big round of applause.
A huge part of the meeting is making sure we have the connectivity everyone needs, and a network sponsor like AT&T is always helpful in that.
So what do we have going on? We have something different in the lobby going on. At the breaks you may see someone going around with a video camera. They're recording a few of you saying why you're excited about ARIN and what keeps you participating.
If you're interested in being recorded for a two-minute video saying what you think about ARIN, why you're excited, why people should participate, then approach these people. They'll give you a little bit of paperwork to sign, putting in writing you are interested in being recorded, you don't mind us putting it in the video we use to introduce people to ARIN, that we use in like our trade show booths.
We felt that I could be a talking head on video in a monotone voice for five minutes and put everyone to sleep, or we could actually take people who are excited about ARIN and record them and put them in our video.
If you're interested in being recorded, being part of the ARIN video, find the people with the cameras at the breaks. We'll have a couple of them that we intersperse. Again, only if you're interested. Don't worry about it if you're not interested. You're not going to end up on the film.
Rules and reminders. The Chair moderates discussions of draft policies so all can speak and all can be heard. Please state your name and affiliation each time you are recognized at the mic. People want to know who is speaking and what your affiliation is.
Please comply with the rules and courtesies outlined in the program. There's a whole bunch of them. If you're at the microphone and you're speaking about a policy, please state whether you're in favor or opposed to the policy. That's helpful for people to understand. And if you can get that up front, that will let people pay more attention to your comments. A lot of times someone's listening trying to look for keywords because they can't figure out if you're in favor or opposed. Say if you're in favor or opposed and continue with your comments.
Today's agenda. We have the Regional Policy Development Process Report. We then have the Internet Number Resource Status Report, Internet numbers in the ARIN region, what we've done with them.
We have some RIR updates today. We have the NRO Activities Report and we have the Policy Experience and Implementation Report. We also have, in addition to a number of reports, policy discussions, and today, in the morning, we have three important policies up for discussion: Draft Policy 2011-2, Protecting Number Resources; Draft Policy 2011-6, Returned IPv4 Addresses; and Draft Policy 2011-1, Globally Coordinated Transfer Policy.
We'll talk about draft policies at 9:35 a.m., which is very soon now. And if we run over in other things, we'll move them. We try to keep the policy blocks starting at the appropriate time. So this morning we'll start from -- we'll talk from 9:35 to 10:30. We'll take a break. We'll come back at 11:00, and from 11:00 to noon we'll talk about policies.
If we have to rearrange the schedule, I'll try for the remote participants to keep the policy blocks on the schedule as shown. We'll move everything else to accommodate.
Okay. At the head table, we have members of the Board, the AC. So we have Bill Sandiford; we have our chairman, Timothy Denton; we have Cathy Aronson of the AC; we have Paul Andersen, who's our Board member; we have Scott Bradner, our Board member; and we have Daniel Alexander, who's a member of the AC.
Okay. It's the lights that make it hard to see these guys. Okay. Without further ado, I'd like to start right in. We have time for the On-Docket Policy Report from John Sweeting.
John Sweeting: Good morning, everybody. I'm John Sweeting, chair of the Advisory Council. And I'm just going to go over a few quick slides so we can stay in the 9:35 time for the policies.
Okay. So proposals that we currently have on our docket that won't be presented here at this meeting is ARIN Proposal 126, Compliance Requirement, which is basically a tightening up of the rules on allocated ARIN resources and the Whois records and what has to be maintained in there.
Two of the highlights are ceasing to provide DNS services and revocation of address space. It was added to the docket on 28th of January and revised in February and it's still being worked on and it was not selected to be presented here. Chris Grundemann and Owen DeLong are the shepherds.
Two new policies. These really just came in too late to be presented here. We got them at our last meeting. Put them on the docket at our March meeting.
It's ARIN Proposal 137, Global Policy for Post Exhaustion. Mechanisms for IANA to be able to take in and give out address space. David Farmer, Chris Grundemann are the shepherds.
And also the other proposal we have on the docket is ARIN Proposal 138, IPv6 Size Category Alignment. Cathy Aronson and Chris Grundemann are the shepherds on that.
We also have a proposal that just came in a couple of days before this meeting, 139, which we haven't even assigned shepherds to yet.
John already ran through the table topics. I just want to add who is going to be at those tables. So on Monday for 126 will be Chris Grundemann; David Farmer will be on the table today for 137; Cathy will be on the table for 138; Heather will be on the table for LIR versus ISP; Bill Darte will be on for the current RIR structure; and Scott will be on for ensuring the ease of entry into the transfer market.
Please participate and give your feedback to that. The shepherds that are hosting those tables will gather up that feedback and post it to PPML. A few references where you can find the policies and proposals and also the Policy Development Process.
And that's it. Thank you.
John Curran: Thank you.
John Curran: Okay. So moving right along. We have time for one more quick report, I guess. Leslie, do you want to come up and give the Regional PDP Report?
Leslie Nobile: Hello, everyone. I'm here substituting for Einar. We left his name on so everybody remembers who he is.
So this is the Regional PDP Report. It's basically the comparison of all the proposals that are being discussed in the various regions.
This is Einar's slide. It's a bit complex, but he basically looks at the past two years, the total number of proposals that are being discussed in all of the regions, and he breaks it down by quarter to coincide with the ARIN meetings.
So on the right side you're going to see, going back to 2009, all the way through right now, 2002 Q2, the total number of policy proposals that have been discussed in the various regions.
You can see right now the blue box, the blue chart, there's 50 proposals being discussed in the five regions right now, which is the highest number that it's been in a couple of years.
The bottom axis shows the various categories, the different topics that the policy proposals fit into.
And sort of the interesting thing about this is most of the proposals right now in Q2 deal with IPv4. Obviously someone's paying attention to IPv4 run-out and everybody's talking about it. So that's the majority of the proposals right now v4 related.
Einar put down a little chart at the bottom that shows the breakdown of the ARIN proposals, the total number that are being discussed in some various state in the ARIN region. And that's it.
So this looks at the six proposals that are on our docket that are going to be discussed today and looks to see whether a similar proposal is being discussed in any of the other regions.
So the first, the Globally Coordinated Transfer Policy, it's only being discussed in the APNIC region, a similar policy. And it's in last call.
Protecting Number Resources, the only other region that has a policy that is similar is the LACNIC region, and that was actually adopted a couple of years ago. And that's where they're going after unused resources.
Better IPv6 Allocations for ISPs was discussed in the APNIC region only and that was abandoned.
Reserved Pool for Critical Infrastructure, that's actually been adopted both in the APNIC and the RIPE region.
And the other two policies that are unique -- are unique to ARIN. There's no one else talking about them.
Einar picks a couple of policies that he thinks are interesting in some of the other regions to highlight. And I actually found these to be really interesting myself.
In the AFRINIC region there's two different policies being discussed. The first one is called the last /8, and that mandates that 90 percent of the last /8s that AFRINIC issues has to be used within their region only. We're preventing RIR shopping perhaps.
The other proposal that's rather interesting there which is kind of the opposite, is called Limited Out of Region Allocation of IPv4 Resources. That would actually reserve one /8 for use by organizations outside of the AFRINIC region. A /16 would be the maximum size issued, and they would charge higher fees for anyone outside of the region for that proposal -- I'm sorry, for that allocation.
And in the APNIC region, there's an IPv6 policy of multiple discreet networks, which is very similar to the one we have in the ARIN region.
That was it. These are references to the various websites to the policy proposal process and the policy proposals in the five regions. And that's all.
Would you explain the difference between a discrete network spelled d-i-s-c-r-e-t-e and a discreet network spelled d-i-s-c-r-e-e-t? The APNIC representative might wish to explain this interesting new kind of network. Geoff.
Geoff Huston: Vint, we don't talk about the d-i-s-c-r-e-e-t networks.
Leslie Nobile: That's all we've got. Any more questions? Thanks for your time.
John Curran: It's now time for us to start into the policy discussions. We're going to start out with the first policy up for discussion, will be Protecting Number Resources. That's ARIN 2011-2.
And what happens when we give each one of these policies is we give a history of it, summary of the Policy Proposal, status of the other RIRs, staff legal assessment, a PPML discussion overview.
I'll cover that. Is there a presentation from the AC on this? Marc Crandall will come up and do that. And then our chairman, Mr. Denton, will help moderate the questions coming from the microphones.
I'm speaking slow to make sure we're really at 9:35 when we start. So Draft Policy 2011-2 history: Was originated as ARIN Proposal 120 on the 5th of November. AC shepherds, Marc Crandall and Scott Leibrand. AC selected it as Draft Policy in January. And it was posted to the PPML with the staff assessment in early February. The current version of the text is dated the 28th of January. And the text and assessment is online and in your Discussion Guide. Again, 2011-2.
Summary: Policy directs ARIN staff to proactively identify and research abandoned, unused, or fraudulently obtained number resources for the purposes of trying to reclaim them when appropriate. It would require the staff to report on the activities associated with this without improper disclosure of details on individual matters during ARIN's Public Policy meetings.
So status and other RIRs: LACNIC has a similar policy in effect for years, a policy to reclaim under- and incorrectly utilized resources.
Staff comments, issues and concerns: It was noted that by the staff that the issue of reclaiming -- identifying and reclaiming resources particularly due to fraud and misuse can take anywhere from days to weeks in order to complete. And there's a significant time, both clock time and staff time, involved. This means the financial implications could be quite severe, depending on the level at which we pursue this.
We currently do pursue misuse of resources for reclamation. But a directive from the community saying expend a significant focused effort in this area probably would have financial implications, and we need a guide as to how large people would like those financial implications to be.
Reclaiming legacy resources is more complex than reclaiming ARIN issued resources.
We also need to carefully consider that aspect of this when trying to prioritize the effort.
Legacy resources that have been abandoned because a company, for example, has dissolved don't really pose a problem. Misuse of legacy resources could be problematic, could take more resources than handling other cases. And, again, we need to know is there a prioritization here that the community would apply if we adopt this policy.
Resource impact: Moderate. Significant staff training, additional staff, software tools, all could be required. Some of these are already out there. We all know how to hunt down various uses of IP addresses and the tools that are used both by the anti-DDoS and anti-spam community. But there's also use of those tools making training available to the staff, and getting more than this to be just an ad hoc effort but a focused effort means there's resources.
And then how much time, again, we put on a monthly basis into this as opposed to other matters.
Legal assessment: No legal comments coming back on the assessment.
PPML discussion: Limited discussion of the Draft Policy. Earlier discussion of the proposal, 39 posts by 11 people. Two in favor and none against.
Selected comments. Again, these are just ones we pull out representing views that we've heard.
Supporting the concept, though believe it needs better wording and guidelines to appropriate fit better. Not worthy of being of an emergency. The most important thing is that ARIN has taken active care of the space.
Unfortunately, one of the duties of a good steward is to clean up the mess when someone else just walks away. And someone noted: How big of an effort? Should ARIN dedicate one individually, 20, 100?
So some of the concerns and general issues raised during the discussion.
Okay. That concludes the introduction of Draft Policy 2011-2. I'll invite Marc Crandall up to do the Advisory Council presentation.
Marc Crandall: I can see everybody. I don't know the problem with the lights (chuckling). In any case, one thing we should point out with regard to this proposal is that currently on the books, you should probably -- if you want to follow in the guide, it's page 6 of the Discussion Guide.
One issue right now is that what's currently on the books, particularly in Section 12, is that the obligation for ARIN to actually reclaim the space is actually -- I wouldn't say it's proactive; it's a lot more reactive.
In other words, ARIN does have the ability to respond to complaints if it so chooses but there's nothing that compels ARIN to do something or proactively investigate these reports.
And the rationale for the policy is that ARIN really is in the best position to be able to determine whether or not there is space that's been fraudulently obtained or abandoned.
So ARIN should be more proactive in reclaiming the space. So as John had talked about this previously, the proposal would require ARIN to proactively seek out these fraudulently obtained or abandoned number resources. And then of course we'd seek the return of these resources. And just to make sure ARIN is taking care of business, the suggestion is that there would be a report made to the community at each of these meetings.
Now, we have some implementation suggestions. It's not in the Policy Proposal itself or the Draft Policy itself. But you'll note that there are implementations and suggestions noted on page 6 of the Discussion Guide.
This is just a very brief summary. We know it's going to cost a lot of money. It's going to take a lot of time. So in implementing it, we're going to leave it largely up to ARIN to determine how they would implement it.
So it would be -- really you need to balance the proactive work versus the impact financially. And I think one thing that ARIN would want to start with is to reach for resources that are relatively simple -- and I'm using the term "relatively" here -- simple to try to reclaim. As you can see on the screen, it would be resources at valid POCs that would be a good starting point or suggested starting point, reclaiming resources that aren't being routed.
And then as far as the reports go, because we want to keep the community appraised of the progress, we talk about how many resources have been returned, how much it's cost. Because, again, cost versus return is very important.
And then get feedback from the membership about the process itself and suggestions for moving forward.
We've already talked about the text itself. So I'm not going to go over it in detail. It's also in the book, if you'd like to read it. It's not particularly long. And we've already talked about the staff assessment.
Really what it comes down to is that this is going to cost money. It's going to take time and cost money. And the question we have to decide: Is it worth providing or is it worth mandating that ARIN have a proactive obligation to seek out these resources and reclaim them versus a reactive position, which is what ARIN currently has.
Is it worth the money to go out and investigate this? It's going to cost a lot of money. It's going to take a lot of time, as John talked about. And there may be additional legal concerns with regards to the reclaiming process.
Now, we don't have a legal comment with regards to the overall legal liability of the Draft Policy itself, but when we're actually in the process of investigating and reclaiming the space, that's when legal issues may come up, especially with legacy space.
So just a heads up there. Now, as far as the resource impact, as John had mentioned, we talked about moderate with implementation.
Although, I think also there was a concern that it might be significant when it comes down to the actual implementation of the policy down the road. Because, again, it could be complex.
And that is the overview. And I think we're ready for discussion. So, again, should we maintain the status quo and be reactive to reports of fraud or should ARIN spend the time and money and be proactive. And so we're ready to take comments from the floor.
Tim Denton: So you all know the drill: Come to the microphones, you identify your name and your association and state whether you're for it or against it and proceed to explain. Three-minute time limit.
Owen DeLong: Owen DeLong, Hurricane Electric. I support the concept of this proposal. I'm not sure I completely support the language as written. I think that the "any means practical," et cetera, wording at the beginning might be a little too strong for what we want to do at this stage, but I do think we should encourage ARIN to take a more proactive role.
I don't think reclaiming IPv4 is the path to IPv4 goodness or extended life of IPv4. I'm perfectly willing to be the first person to admit that IPv4's lifetime is limited, and I think everybody in this room knows that of me at this point.
So I think that it's more a matter of, as somebody put in one of the emails, the discarded soda can on the side of the road. We should make an effort to go pick those up.
Tim Denton: Lee.
Lee Howard: Lee Howard, Time Warner Cable. I agree with Owen on the principle that this is -- the usefulness of this proposal is not in extending the life of IPv4; it's in finding bad guys and blocking snowshoeing.
However, I saw the word "significant" in the staff assessment several times. I don't know how many zeros or maybe more importantly how many commas are in the number "significant." And I can't make a good decision until I have more data.
It sounds to me like this is a project proposal, not a Policy Proposal. And as such, I would probably support this as an ARIN project, if I knew the resources it was going to take.
But that's probably a discussion for the members, not the community. And it's maybe a topic we need to defer over there, once we have a clearer level of assessment.
So in principle I support this. I would like to see ARIN doing something like this. If it's more money than I want to spend, because I don't know how much we're talking about, then I would rather somebody else spent the money to identify the empty space and then ARIN spent the resources as current policy dictates to clean it up.
Tim Denton: Thank you.
Kevin Blumberg: Kevin Blumberg from The Wire. I agree with Lee in regards to this not necessarily being a policy but a project. I also feel like all projects that happen the first time you go around it, you get the best bang for your buck as you keep doing it so your rate of return drops.
So I definitely think a first go-around should absolutely be done, but I would be -- I don't see the point in codifying something long term like this when it's got a continual significant impact from a cost point of view.
Tim Denton: Thank you. Paul.
Paul Vixie: Paul Vixie, ARIN Board of Trustees. So I'm personally for this proposal, although professionally I'm against it, because I think that spending the company's money on this might be a little bit open-ended.
So I want to kind of make a middle-of-the-road suggestion, which is can we -- instead of this -- instead of proactively going out and seeking this, can we change the way we do outreach to the existing security community, various analysts, various volunteers, various vigilante groups -- I don't mean that in a bad sense -- who are already doing this research, and possibly by offering bounties or sort of hall of fame or some kind of an incentive mechanism to get the community to use the reactive method that we already have; in other words, just a simple matter of outreach and maybe some kind of bounty -- I don't necessarily mean cash -- we might be able to get this done without any cost, any real cost to the organization.
Tim Denton: Over there, please.
Mike Joseph: Mike Joseph, Google. I want to oppose this proposal. I think this is an unjustified waste of ARIN's resources to mandate a specific amount of enforcement activity.
I echo Paul's comments. I think that simply providing a venue for those who are particularly concerned with abandoned resources to more efficiently report those abandoned resources to ARIN and allow ARIN to act on that would be the best use of both ARIN's time and the community's and allows for those community members who are particularly interested in the cleaning up of abandoned resources to determine what amount of effort they want to spend in that endeavor.
I'm also not sure that codifying mandatory fraud evaluation and audits by ARIN makes sense for the community at this time because particularly we're not likely to see a substantial return of our investment in terms of gained IPv4 space. And I think the open-ended nature of this spend makes it questionable as to how far this policy could even progress with the Board and implementation.
Tim Denton: Thank you. Point of information from Mr. Curran.
John Curran: I'm one of those gentlemen who doesn't need a microphone. So one turned up on high is very exciting.
Existing practice, so everyone understands, we actually do respond to fraud reports that come in from the community from many of the organizations that do this sort of research on anti-spam or anti-fraud DDoS networks, things like that.
But the threshold that's needed to get someone added to a block list is a different level of threshold than what I need in order to permanently and irrevocably update a database.
So what happens is that what is seen as a simple slam-dunk "why aren't you revoking those resources" for us could be a prolonged dialogue with multiple parties asking for more information, identification, corporate documents, until eventually they realize they'll get caught and they disappear.
So I guess the thing that people need to realize is we currently liaison with these organizations. I'm not sure they appreciate the threshold we need in order to know that we're doing the right thing for due diligence of record changes.
And this policy doesn't affect what we're doing in response to current fraud reports, but what it does do is have us proactively look for certain sources of information such as companies going defunct or deceased individuals and looking to see if there was resources associated with them.
So I just want to be clear, whether we do this or not, we'll still liaison with the fraud organizations. But organizations reporting fraudulent use of resources will continue to do that, but that hasn't proved to be an easy route because our threshold for action is higher than many of them have at present.
Tim Denton: Gentleman in the middle.
Wesley George: Wes George with Sprint. I'm opposed to this policy. I have sort of two comments about this, first sort of directly related to the way the policy is currently written. This may have been more about the way the rationale was written, but I think it's worth mentioning here.
Unrouted does not equal unused. And you need to make the stipulation that it has to be both unrouted and abandoned before you can even consider using that as a criterion to identify what may be potentially space to be reclaimed.
Because you know there's been plenty of examples of folks that are very actively using their space but it's not routed on the public Internet.
The other thing I wanted to mention is that I think that this policy is a nice idea, but it's unlikely to gain a lot of results for much the same reason that we have not seen a great deal of "just to be a good Internet citizen" returns of address space.
There's a transfer market. There's the incentive to do the difficult work to identify address space that is available for reuse.
I think at this point what we're going to have to kind of do is let the transfer market handle some of the stuff that's out there that's sort of on the borderline, could be fraud, could be not, and that's going to take care of a lot of the low-hanging fruit.
So I'm opposed to this from the perspective it's going to be a waste of resources to do something that is going to end up happening organically anyway, in my opinion.
Tim Denton: Thank you very much. David Farmer.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the concept of this proposal. I think it probably still needs a little more work on the actual wording. Responding to a couple of comments that I've heard at the mic.
Adding on to Mr. Curran's comments about the other organizations making reports, it possibly can identify things, but it does not relieve ARIN of its obligation to fully investigate that.
So ARIN still has to investigate it, even if it's a report, because just because I tell John that those guys are bad guys doesn't mean John can go do anything about it.
He has to know that for a fact through his own investigation. Same goes when you report something to the police. They have to have evidence, not just my report.
And then secondly, on the transfer market will take care of this, actually the way the transfer market's currently set up, if there isn't a valid entity to transfer the resource from, then the transfer cannot be completed. This is one of the things that ARIN needs to clean up what I call the dirty cans on the side of the road or the raisins that have fallen off the tree, whatever metaphor you want to use.
That's something that I believe ARIN has to do. And I'll leave the mic.
Wesley George: Wes George. If I can clarify what I mean: I'm not necessarily referring to this from the perspective of invalid context and things like that.
What I'm saying is that a lot of the -- if we're actually talking about fraud, those resources are the ones that are going to end up being handled by the transfer market because it will be more advantageous for things to be made available and done on transfer than to be hidden in some way or lost in sort of accounting issues within large companies.
The ones where it's just kind of in limbo because there's no owner anymore, deceased, defunct companies, those kinds of things, I think what will be happening is you'll have companies that will start seeking those out and they will say, look, we think this address is defunct and we'd like to maybe transfer it, and they will look to ARIN to kind of say can you figure something out with this?
It will be kind of like a fraud report, but I'm not certain -- one of the things you probably when you think about it from a staff's perspective do you already have the wherewithal to manage those kinds of issues? Or does the need to be additional policy in order to direct how staff manages that when a third party comes in and says we think -- it's not fraud. They're saying basically we think this address is in limbo. We think there's no valid contact for it anymore.
We'd like squatter's rights, essentially; do you have a way to manage that.
Tim Denton: Thank you.
John Curran: I can answer that.
Tim Denton: Mr. Curran.
John Curran: So note that it is true that presently there's some parties who create interesting company and email registrations and attempt to appear as the valid registrant for an existing space that may have been abandoned, delayed follow-up for some time.
These are actually doing a community service, because when they come in we vet the resource holder, make sure it's valid. It proves not to be. We send them on their way and we reclaim the resources to the available pool.
So it's a feature, because people tend to pick these up. Squatter's rights are sort of interesting, they don't exist. So when someone comes in with a most innovative application for transfer, they're actually doing -- they're picking up cans on the side of the road that aren't theirs.
And so we actually get a benefit from that. I guess the most important part is we do have the wherewithal -- to answer your question -- we do have the wherewithal to vet those and we're successful at it.
The difference between vetting them as they come in through the transfer reporting process or the fraud reporting process and proactively looking at lists of certain categories of things, defunct companies, deceased individuals, is one that involves proactively engaging in those sorts of reports just based on data, based on raw data that we can get from third parties.
If we do that, there will be a cost, because instead of responding to reports from the community, we will literally be proactively creating work for ARIN, with the potential benefit of additional resources being put available in the free pool.
Tim Denton: I believe we have a jabber question.
Bill Darte: Joe Maimon from CHL. I do not support the proposal as written. I believe ARIN is best served as being the responder to an issue and not the instigator. Automatable processes are another matter.
Tim Denton: I think we'll close the microphones.
David, what you have to say, is it essential, or can we get on with the vote?
David Farmer: Real quick. I just want to point out it was brought up that if someone goes around hunting this stuff, they're going to need a motivation to hunt it, and that motivation would be for them to recover the space, which is not possible under the policies today as I understand them.
And so if the community wants it to work that way, we're going to need a policy to do that, I believe.
Tim Denton: Okay. We now declare the microphones closed. Our vote takers are Mary K. Anyone else? There you are. Good. So those in favor of the proposition, would they please raise their hands.
Those against the proposition, please raise their hands. Got it? Okay.
We're breathless with anticipation.
So those in favor number, 7; and those against number 45. There's a total number of people meeting in the room and remote are 116. That's where we are for that proposition. So next one.
John Curran: Thank you, Marc.
John Curran: Next up we have ARIN Proposal 2011-6, Return to IPv4 Addresses. I will introduce it and we'll have Cathy Aronson come up and give the AC report on it. I'll introduce it without a remote. Someone take the remote on me? Okay. Next slide.
Okay. 2011-6. History: Started as ARIN Policy Proposal 131 in January 2011. AC shepherds, Cathy Aronson and Chris Grundemann. The AC selected it as a Draft Policy in its February 17th meeting. Was posted to the PPML with assessment on the 21st of February. Revised on the 10th of March and a revised assessment came out on the 30th of March. The current version text is dated the 10th of March, and it's available in your Discussion Guide and online.
Next slide. Summary: This Policy Proposal would require that ARIN retain any address space that is or has been returned, revoked, or recovered for redistribution to customers within the ARIN region, except as otherwise directed by policy.
Next slide. No similar policy or proposals in other regions.
Staff assessment: The wording of the proposal seems to indicate that any address space, including a /8, that gets returned to ARIN gets added to ARIN's inventory and made available. In all other instances where a legacy /8 has been returned to ARIN, ARIN has returned the space to IANA. This proposal would change that standard practice.
Staff would continue to implement its own operating procedures for recycling any returned address space. So to the extent that space comes back, we have things like a hold-down policy to let it drop out of routing, similar things.
The community should consider amending the rationale to state, status of existing and future returned addresses, IPv4 addresses, if that matches the policy's intent. The clarification would avoid any misinterpretation and implementation when handling space returned, recovered, or revoked before policy adoption.
To make sure, obviously that we're not talking about just space that's come back after adoption, but space that may be already returned but currently in hold-down at ARIN.
Legal assessment: No legal comments.
PPML discussion: 35 posts by 14 people. Zero in favor, three against.
"If all this proposal is saying is that ARIN will not return space from its region to IANA under any form and under any reason, let's just say it."
"I do not support 2011-6. I believe hoarding resources within a region is poor stewardship of global resources. Perhaps this is overly idealistic, but I believe that while ARIN's mandate is to manage address resources within the region that we should be responsible to do what is best for the entire Internet community."
"It's understandable that people would want IPv4 resources to stay in the region when they're scarce, but what happens when the ARIN region starts to reach parity with IPv6 services? IPv4 resources will start to lose their urgency but they'll still be needed in others."
Those are some of the comments. I recommend people to read the PPML because that's where all the discussion takes place.
Okay. That's the summary of Draft Policy 2011-6. I'll now turn it over to the AC for their presentation. Cathy.
Cathy Aronson: I didn't use the fancy template. Really sorry about that. I didn't get the memo.
Anyway, this is, again, the policy text, and we've already been through that. So this policy started slightly different than what the text is now and the AC kind of worked on it based on the comments on the PPML.
So we changed the text. Originally -- I guess there's slides for this. Okay. Originally there was a 30-day hold period and there were a lot of comments that perhaps that wasn't long enough or maybe too restrictive on the ARIN staff because some blocks are not as nice as other blocks. And so like if you're getting a block back that's been used by spammers, maybe you want to wait longer than 30 days.
It only applied to legacy blocks, and there was a huge discussion about why that was. And we removed that, because it shouldn't matter. They're all address space.
And then it specified originally that blocks would be allocated to ARIN members, but you can go as a nonmember and apply for address blocks. Like corporations, like end sites are not members of ARIN unless they pay, but they can get resources. So we changed that as well.
Again, John already went through the staff comments. We're discussing the existing and future part of their comments, but the text was frozen for this meeting.
So we'd like your input on that. Let's see. Yes, so we changed the 30-day hold to as quickly as practicable, that way the ARIN staff had some latitude as to what they might do in different cases.
And then we changed legacy only versus all ARIN region. Let's see. And the other thing about this proposal is that right now if ARIN gives back a block longer than a /8 to the IANA, they have no policy under which to hand it out and it would be stuck there.
I was thinking about it as I was making these slides if ARIN -- in this depletion stage we're in now, if ARIN gives back a /8 to the IANA, there's not a clear policy. They can hand out a /8. But it's a different regime now. What do they do? Do they give it to the first RIR that applies? Do they do it on some sort of fairness mechanism?
So I'm not entirely clear personally whether there's really a policy, an effective policy if a /8 goes back at this point. Anyway, that's just my opinion.
Anyway, so this gives ARIN a clear policy of what to do if a block is returned, and it keeps address space, like you said, from being stranded at the IANA because there's no policy to effectively give it back out.
The cons are that it's not fair in all regions. So maybe most of the legacy space was originally handed out in the ARIN region.
So most of the space that might potentially come back would be within the ARIN region, and some people feel that that might not be fair to other regions. And that's what I have.
I was wondering if I could ask a point of information from the IANA, if I see -- yes, I do see Elise. Could you address two questions. One, if address space is returned to IANA and there's no policy to reissue it, can you hold it? Are you capable of the stewardship of that? And then the second one, if a /8 were to be presently returned, would it be reissued to an RIR or would it be held?
Elise Gerich: Oh, nasty questions. I'm Elise Gerich from IANA, ICANN. Yes, we will receive addresses and act as stewards while the RIRs come up with a global policy. So I'm assuming that's bits and pieces of address space. If we get a /8, right now we'll have to go back and review all the different global policies that we've received and see how they would apply, because we are allowed to allocate a /8.
However, there was a final global policy that once we got to the last five /8s, they were to be equally redistributed, and that's been done. So we would have to go back and see how the two policies relate to each other.
But right now we will accept addresses, if you'd like to give them to us, and we will hold them for the benefit of the community as the IANA has for a long, long time.
Tim Denton: Okay. The microphones are now open for people to speak on the topic.
Alain Durand: Alain Durand from Juniper Networks. I have a question related to this. When you reclaim some address before you actually give it back, do you recycle it? Besides just keeping it for 30 days, do you go and actively try and clean it up and export it from a blacklist and other nasty databases?
John Curran: Yes. The short answer is yes. And we actually have a good relation with a lot of the people who operate blacklists of various types. We do publish it. We let them know of our practices for holding address space, and they can see the daily file. So a lot of them are now following that and they know it's in hold-down and they drop it from their lists.
David Williamson: David Williamson from Microsoft Tellme. I'm against this policy as written. It feels somewhat parochial to just kind of say that any addresses we currently have no one can ever have them ever again.
There should be some way, once the kind of global policy for IANA has been worked out, to hand some sort of space back that seems useful. The current policy of just simply if there's a whole /8 we'll return that seems pretty good for the moment.
The whole thing seems a little academic in my book just because IPv4 is going to become less useful. There's a concern listed in the discussion about as we have lots of space available what would we do with it. Well, by then I don't think anyone is going to care what we do with it. So it's perhaps a nonissue. Thanks.
Tim Denton: Thank you.
Cathy Aronson: David, it does say in the policy, though, as otherwise directed by global policy. So if another policy -- if there's a global policy passed, then it wouldn't be like this forever.
Tim Denton: Mr. Curran would like to raise a point of privilege.
John Curran: To the extent that you're coming up to a microphone or you're at a microphone, I would ask that you not only identify yourself and your affiliation, whether you're in favor or against, but I would ask that you don't act like me -- i.e., talk slowly and clearly. My normal speaking is sufficiently fast that the court reporters are unable to do the live transcript when I do my utterances.
So I'd ask everyone to speak slowly and clearly and not overrun so we can have a good transcript as people are putting it online for the remote participants. Thank you.
Tim Denton: I believe, Heather, you're next.
Heather Schiller: Heather Schiller, Verizon Business. I'm in favor of this policy because I don't think it's good stewardship to let address space that could be used for a community sit and be locked up waiting on the rest of the community to come to agreement about what to do about the global policy.
So if the address space is needed and can be used, it should be put into use.
Tim Denton: I believe the gentleman over there is next.
Mike Joseph: Mike Joseph, Google. I support this policy. And in particular concerning the transfer to other regions, we have another proposal on our docket, 2011-1, which allows for the transfer of space from one entity to another.
I really don't see it very likely that ARIN will end up with massive amounts of free space in our region that simply has no use when other regions are stranded, are struggling.
I think that worldwide there's going to be strong demand. And I agree with Heather's consideration that we really should not strand this policy in IANA for however long it may take to maybe come up with a global policy.
Tim Denton: Thank you very much. Raúl, I believe you're next.
Raúl Echeberría: Raúl Echeberría from LACNIC. Actually, the current championship of foosball tournament in ARIN. I don't know which designation is more important.
I would like to share with you, I think that in previous ARIN meetings I have already shared with you what is the LACNIC's position regarding legacy, return of legacy address space, and I want to do that again, since it has been recently ratified by LACNIC Board.
We think that no single RIR have authority over the legacy space returned, and we think that we should find mechanisms for make returned addresses available to all the global community based on the needs, of course. And I think this is an important point of agreement.
So we think that the IANA should be a perfect steward for the recovered address space independently or in which region those addresses are recovered.
I appreciate -- we in LACNIC appreciate very much the IANA willingness to act as the steward of any address space that is returned to them.
We have a problem with the lack of proper global policies for resolution of the address space, but I think that IANA should be the right place for placing those addresses until we have those global policies.
And regarding those global policies, I think that at some point people will -- people that is proposing different proposals should start with each other in order to find a compromise, because we really need those policies.
Tim Denton: Thank you.
Scott Leibrand: Scott Leibrand, ARIN AC, Limelight. I oppose this Policy Proposal. I think that it is both unnecessary and harmful. Unnecessary because I believe ARIN staff has done and will continue to do a good job of invoking the correct operational practices for what to return to IANA and what not to return to IANA. Harmful because I think it goes against the grain of global cooperation and would be less than helpful in terms of making good policy to work with the other regions, both for transfers and for other things.
So I oppose this Policy Proposal.
Tim Denton: Lee's next, and then I believe -- are you waiting? You're waiting. Lee, you're next.
Lee Howard: Lee Howard, Time Warner Cable. First of all, I want to applaud staff for clustering these three proposals together, because there's an interaction that I want to amplify in response to Mike Joseph's and Raúl Echeberría's comments that ARIN might recover space in ways other than voluntary return, especially if a project like the one we just considered is undertaken.
So there may be address space that's returned. This particular proposal has two fundamental elements that I see. The first is that address space should be reallocated as soon as possible, rather than being held down for some -- for a long time.
And the second is it should be reallocated within the ARIN region as soon as possible. And it's within the ARIN region part that concerns me a bit, because I don't want to be overly parochial.
We're part of a global community, not just an ARIN community. And there are organizations and networks in other regions that need address space, too.
And, however, having said so -- so that part of this proposal concerns me. Having said that, I would have a very difficult time allowing addresses to be reallocated or especially transferred out of region to an RIR, to a region that did not have a needs-based policy.
Of course now I'm talking about the next proposal, but that's why they're all grouped together here, right?
So I only partly support this proposal, and that is the part of reusing quickly. There's nothing wrong with that.
I don't think that addresses necessarily must remain within the ARIN region, because addresses are used for global uniqueness and routing and not for national pride or even regional pride.
Tim Denton: Thank you. The lady over there.
Sandra Murphy: Sandra Murphy, SPARTA. I have a question and no opinion yet on this Draft Policy. There were comments about ARIN's outreach with blacklist providers with respect to recovered addresses.
And it occurred to me that I didn't know the answer. Could you comment on ARIN's proactive outreach to service providers about recovered addresses to ensure that they are not being operationally used?
John Curran: So we actually have some daily report files that come out that cover address space that we've recovered. And so we've made it known to parties that these files are available, that they can see resources that have come back in.
The challenge is it's up to each service provider to decide they're going to pay attention to those lists and drop the routes.
That's not ARIN's job. So I will tell you all, you can go get ARIN's daily file, which will tell you about the adds and deletes, all who operate service providers.
We've talked about that in multiple forums, but at the end of the day we make the information available. It's up to the service providers to actively proactively go and get it.
Sandra Murphy: Thank you.
Tim Denton: Jason Schiller.
Jason Schiller: Jason Schiller, UUNET, Verizon, and the NRO NC. Like Lee, and for many of the same reasons that Lee stated, I partly support this. But I'd like to call attention to another factor, which Lee didn't state, but in order to do so I'd first like to ask a point of clarification.
This community has already passed a global Policy Proposal with regard to IANA allocations post exhaustion. It's clear that policy is not moving forward.
But if that policy were to move forward, or a similar policy was to move forward that did not make the return of addresses to the IANA mandatory, and this policy passed, what would staff do if a /8 was returned.
Tim Denton: Mr. Curran.
John Curran: Right now if a /8 was returned there's actually an agreement among the RIRs documented from 2003, 2006, that says a party can return a /8 directly to IANA or return it to the regional registry in which it's registered.
If they didn't opt to return it to IANA and they returned it to ARIN, our policies would apply.
At present, our existing practice has been that address blocks of /8s that have been returned to ARIN, we have, in turn, referred them to the IANA and said return the address block, if it's a /8 in size. If it's smaller, that's not the case. But for a /8 it certainly is.
At this point if a /8 were turned into ARIN, I would confirm with the Board the existing practice and I would just say: Unless the Board wishes to direct me otherwise, I'm going to take that party that has a /8 and direct them to the IANA to return the space.
Unless the ARIN Board said we will change our existing practice, normally we would not handle space of /8 or size.
Jason Schiller: My question was about a hypothetical future return where a global policy was adopted in all five regions and ratified by the IANA and that global policy is similar to the one that this community already passed, that does not make the return of addresses to the IANA mandatory. It's the way that the text was passed in this community, the word "may" was in there, "may" return space.
My question is: If a global policy such as that passed with an optional may return address space, and this policy also passed, would staff reading this policy say, because they're not specifically directed by the global policy to return the space, that they must keep it within the region.
John Curran: If the hypothetical global policy you're talking about is one that says returned space shall be handled as follows but doesn't require return one way or the other, then it doesn't speak to return of space.
In which case, because it doesn't speak to the return of space, we would hold it in this region.
Jason Schiller: That's my additional concern that I wanted to tack on to Lee's long list. My additional concern is this makes the bar much harder to pass a global policy, because now, in addition to passing the global policy such as the one that this community did move forward, we would have to also include a clause to make the return of those addresses mandatory to the IANA if we wanted to override this policy that we're discussing here.
John Curran: Let me just be clear, Jason. Really what you would do is you would have a global policy that speaks to how returned space is handled. That global policy doesn't talk about how space is to be returned or not. That's a local matter.
If this policy was adopted, it would say we would never return space. You would have to change this local policy. You wouldn't have to put it in the global. You would have to revise this local policy.
Jason Schiller: You'd have to do either or.
John Curran: Correct. It would make it harder on the global level, but I think the global policy was written envisioning that everyone was going to have local policy for return.
Tim Denton: Cathy Aronson.
Cathy Aronson: It's Cathy Aronson again for the reporters. Would it be helpful if this proposal had some sort of text that said once the IANA can deal with space this goes away? Or do you have a suggestion?
Jason Schiller: Yes. Like I said, along with Lee's long list, and my other concern, I personally support this, if the text was amended that stated that this policy would be revoked at the time that there was a global policy to deal with returned space to the IANA that this would get revoked, I would support it, because I think it is good to make sure that space that's available to be used is used.
And I would rather see space right now returned to be used in this community rather than to be left in limbo in the IANA.
Tim Denton: Thank you. I see in order -- I see Matt Pounsett and the gentleman over there.
Matt Pounsett: Matt Pounsett, Afilias. I hadn't thought about it until now, but I think I might support this proposal with a change like the one that Jason just suggested.
But I kind of feel like this would be a policy that we would never really see come into effect. I'm not really anticipating us getting a lot of space returned by any means until such time as most people have transitioned and v4 isn't really in as much demand anymore, and then we might see some returns.
But at that point we're not going to care if it stays in this region or not, because we don't need it as much. So I kind of feel like we'll just never use this if we pass it.
Tim Denton: Thank you. The gentleman over there.
Yves Poppe: Yves Poppe, Tata Communications. As a member of four of the five distinguished registries, I oppose this because I would like to have a new /8 if one or more come back the highest probability to see them in the ARIN region.
But, again, I don't know where I would need my future address space, more likely in Asia or even in Africa. So I would prefer to see the /8s returned to IANA and disposed of later on once all registries agree.
Tim Denton: Thank you, Yves. I don't see any more speakers.
Raúl Echeberría: I want to make a clarification. The fact that the addresses could be returned to IANA doesn't mean that those addresses would be necessarily useful in other regions, because I think all of us agree -- at least most of the people agree in the community that the policies for reallocating the addresses should be based on needs.
Regions like -- sorry. I didn't say my name. Raúl Echeberría.
Tim Denton: We know who you are.
Raúl Echeberría: For example, in LACNIC we promote a solution, an option to return the address -- recover addresses to IANA and wait for development of new global policy for dealing with those addresses, in the understanding that we will never receive addresses from that source, because we don't need them.
So it's probably the addresses will be used in the same region in which the addresses are recovered. Not all addresses will be used in the same regions, but more or less I think it's Asia-Pacific, North America and probably Europe will be the only regions that will be in a position to receive addresses from a new global pool.
Tim Denton: Thank you. Louis.
Louis Lee: Louis Lee, Equinix and also on the NRO Number Council. I think we forgot that there's one more thing that can happen to return addresses; that it would get transferred between regions if there's a policy that allowed a transfer between compatible regions, or, sorry between regions with compatible policies.
So if we were to say that rather than saying not held in ARIN region but just say not returned to IANA until there's a clause that says that there's a global policy for IANA to return space, then we don't prevent space from being transferred between regions. Did I make myself clear on that?
Tim Denton: I need to get, are you in favor or against the proposal?
Louis Lee: I would be in favor if there was a clause. So I would be opposed as written. I would be in favor if there's a clause to allow this proposal to be revoked if there's a global policy and also if there's a way for it to be transferred between regions without going to IANA.
Cathy Aronson: Louis, just to respond to that, I believe because that sort of global policy would directly pertain to blocks returned in this region that this policy would let that happen.
So you know it says unless otherwise -- there's a clause about global policy. I think those are compatible as opposed to IANA can hand it out, one, which is it.
Tim Denton: I think it's time -- unless there's more -- yes, one more. That's it. And then --
Chris Grundemann: Chris Grundemann, ARIN AC. As one of the shepherds I'd like to ask possibly -- well, two things. This is a clarification. I think Cathy's right. I think the first line, "Except where otherwise directed by policy," allows future policy to change this.
So if we were to adopt a policy that allowed global transfers, I believe that would fit this and say, okay, it's otherwise directed by policy, global transfers are allowed in our RIR regions. If we adopted a policy that said certain space is going to return to IANA, I think this policy would allow it.
So because of that and because of the comments that have been made and because there is another Policy Proposal to be discussed next that is a global transfer policy, I'd like to possibly, when we do the polling, ask that two questions are asked: In favor of this proposal as written and in favor of this proposal assuming that the global transfer policy also passed. Meaning that I believe the two are very closely coupled and that there may be a large number of people who are in support of both policies passing but not one or the other without both.
Tim Denton: So what you're asking for, then, is two questions to be put. The first is this policy standing on its own. The second one is presuming the passage of the interregional global transfer of policy, which is coming up, who then would be in favor of this proposal.
Chris Grundemann: Yes, I believe that would be very good guidance to the AC.
Scott Leibrand: Point of information, I believe the transfer policy is not a global policy. Could someone confirm?
Tim Denton: Globally coordinated. So I think that's the reasonable way of getting around it was a difficulty. So the first question that will be put is: Are you in favor of this proposal as written. The second question will be: Are you in favor of this proposal assuming the passage of the next policy item, which is 2011-1. And then we'll ask the positive and negative on each of the proposals in order.
The first is: Are you in favor of this proposal without further -- and the second question that will be asked is are you in favor of this proposal assuming the passage of the next Policy Proposal.
Vint Cerf: Vint Cerf. I'm from Google and a member of the Board. The question I have for you, Mr. Chairman, is what you intend to do with the outcome of this vote. Is this a straw poll or is this an action?
Tim Denton: It's straw poll.
Vint Cerf: Okay. I want to make sure everybody understands this is a straw poll, because if we don't figure this out right, you'll do the wrong thing in the wrong order.
Tim Denton: Indeed. So it goes as advice to the Advisory Council for them to consider it according to the weight they give it.
So the first question that we're going to ask, the yes and no will now be asked, without further discussion, is: Are you in favor of this proposition as written assuming nothing further? Those in favor of this proposition as written and assuming nothing further, would they please raise their hands. Those against the proposition as written and assuming nothing further.
And do we have the remote participants?
Okay. So can we then have the vote? We'll just have this one as it is now.
So the proposition before us is 2011-6. The total number of people in the room and by remote is 118. Voting for it as is, with no further assumptions made, six are in favor and 28 are against.
Thank you. We're now going to do the vote on the same proposition, assuming the passage of the --
Cathy Aronson: Should we discuss the other proposal first?
Tim Denton: No, no, I don't think so. Sorry, but I think we've discussed it.
Cathy Aronson: The next one. We're now talking about this proposal and the next proposal.
Tim Denton: No, I think that will create hopeless confusion. I think that we will now move to vote on 2011-6 on the assumption that 2011-1 passes and that policy is put into place. Remember, this is just advice to the Advisory Council. You're not deciding the fate of the world.
So those in favor of 2011-6 on the assumption --
Bill Darte: I think it's important to state that 2011-1 is entitled at least a "Globally Coordinated Transfer Policy." So when you're considering 2011-1, it would assume that there was in place a transfer policy inter-RIR.
Tim Denton: Thank you, Bill, for that clarification.
So those in favor of 2011-6 on the assumption of an inter-RIR transfer policy being in place, which is the next proposal, who is now in favor of 2011-6, please raise your hands. And those against 2011-6 on the assumption that this other interregional transfer policy is in place.
So the answer to that is 2011-6, 118 people voting in the room and by remote. Assuming passage of 2011-1, four were in favor and 14 were against. So there we go.
Thank you very much. And we'll now move on to the next item, 2011-1.
John Curran: We have a break.
Tim Denton: We're liberated, you're free!
John Curran: So, the good news is we have a break. The bad news is while we're starting late we're going to end on time for that break. So you're all to be back in here promptly at 11:00 a.m., and I look forward to seeing everyone. Break is right out through these doors. Back here promptly in 17 minutes.
John Curran: I'd like to welcome everyone back. We'll get started now.
We're resuming with our discussion of policies in this morning's Draft Policy block. We've managed to knock off two of the three. We have one more policy to discuss. It's policy 2011-1, Globally Coordinated Transfer Policy.
John Curran: I will do the introduction of the policy, and then we'll have Bill Darte come up and do the AC presentation.
So Draft Policy 2011-1, Globally Coordinated Transfer Policy. History: Originated as ARIN Proposal 119 in October. AC shepherds, Bill Darte and Rob Seastrom. AC selected as Draft Policy in January. It was posted to the PPML on the 3rd of February. Current version text is dated from December, and you can find the text and assessment in your Discussion Guide.
Proposal would allow a registrant of IPv4 addresses from one RIR to transfer those resources to a registrant or future registrant of another RIR as long as both RIRs agree to the transfer and apply compatible needs-based policies in accordance with the stewardship principles expressed in RFC 2050.
Status at other RIRs. Very brief status. APNIC last call, 1st of March through 26th of April on a related inter-RIR transfer policy.
Staff assessment: Issues or concerns. Existing 8.3 would need to allow these transfers to happen. Noting that 8.3 as currently written prohibits inter-RIR transfers, so we'd have to be clear that by adopting this we would amend 8.3.
Staff outlined the implementation process in the staff assessment; in other words, how we would interpret that is contained.
Zone fragmentation and DNS synchronization problems are possible with inter-RIR transfers because things are delegated at a large boundary and as you move pieces back and forth you need to coordinate on DNS IN-ADDR and similar.
The text suggestion to make it clear that the recipient isn't required to already have address space. So it's possible the recipient is a new registrant of resources as a result of receiving them. And if the space gets transferred directly from the registrant to recipient without coming to the RIR, it's unclear which RIR is ultimately authoritative to the space. Noting that it probably should be written as registrant to RIR to RIR as a transfer.
Implementation: Resource impact minimal, but careful coordination is needed on reverse addressing issues.
Legal assessment: The language might properly be clarified to reinforce the requirement that resources be put under an LRSA or RSA before they are transferred to make sure that you know that they're valid.
The word "compatible" might be described as comparable. Don't we have to make a transfer to the specified recipient through the other RIR and not directly to that recipient from ARIN.
Provided suggested revised text for consideration.
And as drafted this policy has no out. For example, it does not on its face permit ARIN to refuse a transfer because the recipient is someone who violates U.S. or the recipient country's laws or violates other ARIN policies. Do we want flexibility built in to permit ARIN staff to refuse an inter-region transfer if it would refuse an intra-region transfer.
I'm not sure the right to refuse is implied or can be exercised. To the extent that we want that, it should be explicit rather than something we're deriving secondhand.
PPML discussion: Little discussion on the Draft Policy. Earlier discussion on the proposal, 39 posts by 18 people. Four in favor and one against.
"Support of the concept, but believes it needs better wording and a better understanding of how transfers would take place and how they could be managed given the hierarchical model."
Also, "Given that there's no requirement for IP address blocks to be used in any specific region and there's no requirement for organizations to do business with the nearest RIR, I don't see any useful purpose. Those are samples of two of the comments on PPML.
So that concludes the introduction of Draft Policy 2011-1. I'll have Bill Darte come up and give the AC presentation.
Bill Darte: Thank you. Good morning, still. I'm Bill Darte with the AC. I represent the primary shepherd duties along with R.S. for this Policy Proposal, now Draft Policy.
2011-1. This was originally proposed by Chris Grundemann, Marty Hannigan and Jason Schiller. And as you've seen, there's been some discussion on the PPML and also within the AC and I hope to represent all that to you.
As John just went through, there was staff and legal review of this Draft Policy and Policy Proposal. Some of the wording changes were made by the original authors, and then again by the Advisory Council to a certain extent through the historical process.
It was originally introduced fall of 2010, and it was ultimately accepted onto the AC docket October 27th. The current language as will be listed in the subsequent slide was formalized on December 23rd and then frozen before this public policy meeting.
As you can see, it's a very simplistically worded document or Draft Policy. It was intended to be so.
We had a lot of discussion about adding and changing verbiage to this; decided to make only minor tweaks to it.
I hope you've all read this. Certainly the rationale for this Policy Proposal is an important one, because it would allow not only -- well, it would allow transfers to take place inter-RIR.
And this would be an enhancement. And as we've seen, in the last two policy proposals, that in concert with them it has certain implications.
So the biggest issue that we struggled with was this exercise Internet stewardship and the values expressed in RFC 2050.
We worked on language to make, to get rid of this sort of overarching and vague statement. But it became complicated and nuanced to the point that we reverted back to this.
I personally was convinced that if ARIN simply maintained a list as I was assured they could, looking at whether other RIRs were in concert with this description, exercising Internet stewardship and the values expressed in RFC 2050, which would include a needs basis for allocations and assignments, then only that single reference would have to be looked up to get sort of ARIN's blessing for such an approval for transfer.
This type of cross-RIR analysis of policy is consistent with current practice. In fact, we publish all kind of contrasts across the RIRs as do the other RIRs.
Another issue was whether we needed something explicit stating that the RIRs were the intermediaries to this transfer as opposed to this being from one resource holder to an applicant.
And, again, we made a minor tweak to that saying that the RIRs would have to agree, and we made the assumption that that would make it obvious that RIRs would be the intermediaries to that transfer.
What happens if this Draft Policy were adopted as policy in the ARIN region but it could not attain a status of globally coordinated across the other RIRs was a question that was posed within the Advisory Council.
And, you know, again, we believed I think as a group that, you know, this was a goodness in its own right. If we said that we would enable global transfers, that would be a goodwill policy even if no other RIRs agreed and had similar compatible or comparable policies in place.
But to the extent that even one other region had such a policy, then we could enable transfers to take place, and that would be a goodness for the resource requirements of the people who were applying, whichever direction it worked.
So I apologize to the community here. In my stewardship of this Draft Policy, that I did not publish the changes that would be required and suggested to 8.3. 8.3 currently talks about transfers in the NRPM. And 8.1 simply states the principles that transfers would take place, the whole idea of nonownership, needs-based requirements for IP addressing, et cetera.
8.2 says that there's a specified transfer policy -- excuse me, there's merger and acquisition transfers available. This is something that has been in the NRPM for a long time. So 8.1 simply says these are the principles we believe in with IP address allocations and assignments.
8.2 says that merger and acquisition transfers are acceptable as long as they meet the required policy and stipulations of ARIN practice.
So 8.3, then, more recently dealt with specified transfers. And that's relatively new in the NRPM.
And as John, in his introduction of this, suggested, that section of the NRPM would have to be changed. I present the changes now as we considered them and is probably not in your packet.
But I think I can make it rather clear as to what the intention of the changes of the NRPM. So 8.3 as it currently exists is shown over here in red and blue. That's the current NRPM text for 8.3.
What would be suggested as the proposed change to the NRPM, if this Draft Policy 2011-1 were implemented, would be to separate 8.3 into three elements.
The first being transfers to specified recipients, which would be the red text, exactly as it exists today in 8.3, to break out 8.3.1 for transfers within the ARIN region specifically, which would be the exact same text as exists in 8.3 already.
If you will bear with me, I'll move back and show that those two red- and blue-highlighted portions of the existing NRPM text would then become 8.3 and 8.3.1. What we would be adding with this Draft Policy adoption would be an 8.3.2 transfers to and from the ARIN region and the existing proposed text for that policy, Draft Policy, would augment what already exists in 8.3 today.
So that's what we would be proposing to changes to the NRPM if you as the community direct the AC and the ARIN Board to adopt this Policy Proposal.
I think this is an important issue. Okay? It's my opinion that we need such a policy. We have the ability to transfer resources from one entity to another within the region today.
And I think there's overwhelming support that this is a good thing to allow addresses to go from where perhaps they're less needed to places where they are more needed. And there's certainly no reason to suspect that that goodness could not be extended to the global community as well.
So I think this is a good Draft Policy. I would like to invite you all to exercise your own involvement in consideration of this Draft Policy now and to come to the microphones if you will, if you have discussion about this.
Owen DeLong: Owen DeLong, Hurricane Electric. Bill, could you go back to the comparison of the before and after?
Bill Darte: Maybe.
Owen DeLong: On the after slide, actually. Do we have staff input on how an inbound transfer or an outbound transfer, for that matter, would get interpreted with this particular surgery to the NRPM? Because it seems to me that 8.3.2, if it's interpreted quasi independent from 8.3.1, could lead to some different kinds of blocks being available to people than what is allowed under 8.3.1, and I'm not sure if that is our intent.
Tim Denton: Mr. Curran.
John Curran: We haven't looked at this particular break of text and what it would result in. So if there's something you think needs to be changed otherwise, that's an important comment to give to the AC.
Tim Denton: Sir, you're next. Alain.
Alain Durand: Alain Durand from Juniper Networks. Two questions. Transfer to and transfer from, seems to me that they're somehow different. In the text it talks about comparable needs-based.
So essentially creates a distinction between registries with policies and those that don't. So if we are worried about sending addresses away to people who don't have restricted policy on transfer, why are we thinking that we need to transfer from first region to ARIN. Because if we believe that having this needs-based policy is a good thing, having those resources into ARIN should be considered a good thing.
So I don't understand why we treat transfer to and transfer from the same way. That's my number one question.
My number two question, you may want to address them at the same time, is I understand that all registries have passed policies to allow some sort of transfer but all those policies are fairly different.
So out of the five registries, four other registries, which one will you consider today have comparable policies on transfer, and ARIN has.
Tim Denton: Alain, I would just take it -- the point of your question here is I take it in its current form you're against this policy.
Alain Durand: Correct.
Tim Denton: I think Bill or John will respond.
John Curran: If this policy is adopted -- I think the second question you asked, if this policy is adopted, ARIN staff will maintain a list of registries that have comparable needs-based policy per RFC 2050. We'll post that so that people know Section 8.32 applies to the following RIRs and we'll have a list we'll maintain.
We won't build that list until this policy is passed. And so we don't have one because there's no policy for it. We would need to assess the state of each other's RIR transfer policies at that time. So that's the answer to your second part of the question.
Tim Denton: Who wants to take on the first part of his question?
Bill Darte: Could you restate the first part of your question?
Alain Durand: First part of the question is why do we treat transfer to and transfer from the same way? It seems to me that the transfer from should have a lower bar than transfer to.
Bill Darte: The intent here was to originally provide a globally coordinated policy that would allow RIRs to transfer between registries, available space, under the auspices of the RIR intermediaries.
So to and from suggests only that this would be an enablement if all RIRs adopted a similar practice than transfers would take place to or from uniformly as long as they had this consistent needs-based practice.
Alain Durand: It seems to me, this is really the crux of the issue, is my reading of the different policies and the different RIR is that they do not all have this needs-based policy.
I'm afraid essentially the answer to my second question is zero.
Tim Denton: The answer to your second question was what?
Alain Durand: Zero.
Tim Denton: Thank you.
Geoff Huston: Geoff Huston, APNIC. I'm neither for nor against this proposal by virtue of being a staff member of APNIC, if I get the wording right, John. Is that correct?
John Curran: That sounds good, Geoff.
Geoff Huston: I would like to note that at the recent APNIC meeting in Hong Kong the meeting reached consensus on a Policy Proposal No. 95 which we anticipate to actually become adopted by APNIC in the coming weeks given the lack of any objection on the mailing list.
So unilaterally APNIC is now in the final stages of adopting an inter-RIR transfer policy of its own. It's a much simpler proposal than the one before you here. It simple states in the case of a transfer between RIRs, the source of the transfer must meet the applicable policies and requirements of the RIR at source and the destination of the transfer must meet the applicable requirements and policies of the RIR at destination.
The policy was careful not to cross-impose requirements from one region on to another, thereby respecting the right of each of these regions to make their own policy and to allow transfers in a way that does not cross-imply requirements from one RIR to another.
So if that helps you at all, hopefully it does.
Also, I add as a point of information that APNIC has a transfer policy in place today, and given that APNIC has not yet allocated the last address -- that's true -- it is a requirement and the transfer policies stands today that need has to be demonstrated in the usual course of events.
I do note that when we give away the last address, it's still today, that once that happens, transfers will take place in the APNIC region without reference to a needs-based requirement on either party within the APNIC region.
The background for that and the reasons I think are hopefully very aware to you and I will happily answer any specific questions about that policy if you have them.
But as a point of information, as we get to the last /8 policy in APNIC -- again, meaningfully glances at watch -- our policy will change into a policy that does not have needs-based as part of its internal, within APNIC, transfer policy. Thank you.
Tim Denton: Thank you. I believe Scott is next. Is that correct? Or is it Lee?
Lee Howard: I'm willing to defer.
Tim Denton: You were next, then.
Scott Leibrand: He was next.
Lee Howard: Lee Howard, Time Warner Cable. I was going to comment on some of what Geoff was talking about anyway. I note that each of the other regional registries has its own policy development process which can change the policies local to each regional Internet registry.
I point this out because there's the possibility of policy flapping whereby whether they have a needs-based transfer policy may change from time to time.
Glances meaningfully at watch.
So I wonder if -- let me point out a potential worst-case scenario: There may be a changing consensus in a region. I believe APNIC has two meetings per year. They could have the spring meeting being the adopt needs-based policy meeting and the fall meeting be the rescind needs-based policy meeting.
Which would change the state of our policy from time to time. This potential confusion, this potential for, like I say, policy flapping scares me.
And because, as Bill pointed out, it is potentially discernible whether a given RIR, or staff will discern for us, whether a given RIR at the moment has a needs-based transfer policy. Because that changes and because I don't know how staff is going to determine that, I feel like I have to oppose this proposal as written.
Tim Denton: Geoff, not yet. John.
John Curran: So as written ARIN staff would maintain a list of those RIRs whose current policies meet the definition.
And we'd update it as those policies change. We actually track the others. I admit that's a situation that's interesting in that the current state of policy and the transfer policy in the ARIN region and where transfers could be done would be dependent on the state of flux of other RIR policies, and it could change dramatically.
I don't see an operational problem in maintaining the list, but I do think that it's something that the community would need to consider because it would be inevitable that that list would change dynamically.
Tim Denton: Scott then Geoff.
Scott Leibrand: Scott Leibrand, ARIN AC. I support this Policy Proposal. I think inter-RIR are essential to ensuring that the transfer markets that are developing do not get widely divergent prices in different regions and we don't end up with undesirable opportunities for arbitrage in contravention of transfer policy.
That said, the particular details of how this works out, it sounds like mostly what we're discussing I don't have a lot of opinion on that, but I would like to express strong support in favor of the Policy Proposal and the idea behind it.
Tim Denton: Mr. Huston.
Geoff Huston: Geoff Huston, APNIC. As a point of information to Lee and as a follow-up to his observation around policy flapping, there was a Policy Proposal presented at APNIC 30 that did intend to amend APNIC's transfer policy to continue a needs-based process beyond the allocation of getting into the last /8 in APNIC.
I should note that that Policy Proposal did not reach consensus at that meeting. So APNIC's incumbent policy about transfers that drops needs-based requirements when the last /8 is reached remains in place.
That's the issue around policy flapping; that the community in APNIC has considered a transfer policy more along the lines proposed here, and that did not reach consensus at APNIC. Thank you.
Tim Denton: Mr. Curran.
John Curran: Point of clarification, Geoff. Was that abandoned? Returned to the mailing list? What happened to that?
Geoff Huston: Abandon is such a hard word. We treat things with care and discretion in the Asia-Pacific region. And it's been carefully and discreetly returned to the mailing list.
John Curran: Okay.
Tim Denton: Lee Howard.
Lee Howard: I realize I was not entirely clear on my position earlier, that although I think there is clarification required, because I'm afraid of the appearance of hoarding within our region, and I do believe that need is not unique to the ARIN region, I think an inter-RIR transfer policy is probably required.
I think that this is the best and closest version I've seen, but because of the two points of not knowing whether my understanding of a needs-based policy would be the same as staff's and not knowing -- and the fear that addresses could be transferred someplace where they could later be transferred without the need for need, I have those two concerns.
If those were well addressed, then I would absolutely support this.
Tim Denton: Thank you. Gentleman over there.
Mike Joseph: Mike Joseph, Google. I don't have a particular concern for or against the proposal as written in the original draft text. However, the proposal projected would seem to indicate that if you attempt to transfer under Section 8.3.2 that the needs clause from 8.3.1 would not apply because it's not within the region.
John Curran: Correct.
Mike Joseph: So what we're suggesting, then, is that the transfers within the region would have a needs requirement, but transfers between regions would not have a needs requirement. However, will only allow transfers between regions where both regions have a needs requirement.
John Curran: As written, to understand the interpretation, as the policy is written, the needs-based requirement for intra-transfer within the region would not apply, as long as the RIR that was the recipient region, as long as that RIR had needs-based policy for the recipient, their policy would apply.
Mike Joseph: But I'm an ARIN region member also to the other five. But if I wanted to transfer space in, according to this policy, I don't have to have demonstrable need for it.
John Curran: I see. Yes, we would need to apply our needs-based recipient policy, and the language is not clear on that.
Tim Denton: Mr. Darte.
Bill Darte: The generalized language that we use for this Draft Policy suggests that the RIRs agree. If the ARIN region did not apply its current standard for needs-based, then I don't know what else they would do. That's our current practice and our current policy.
So the idea that the RIRs would agree suggests that ARIN would comply with its own policy in that case.
Mike Joseph: That says not to.
Scott Leibrand: Could you switch off of this slide? This is not actually the Policy Proposal under discussion. The Draft Policy text is this. And I think it's very important. And the reason we have a text freeze is to make sure that we're all discussing the Policy Proposal that's on the table, which is solely with regard to interregional transfers.
There's some work to be done, apparently, on the AC's behalf that we will do to make sure that this is merged appropriately with 8.3. You've seen one possible way that could be done, but please don't get hung up on the particular merging with 8.3. The intent is to preserve 8.3 as it is and, if this proposal passes, to do what's in bold there. And that's what is on the table.
Tim Denton: I believe Mr. Vixie is next. Is that correct?
Paul Vixie: Paul Vixie, ARIN Board of Trustees. I'm in favor of this proposal as written.
What I wanted to go to is this 2050 requirement that talks about needs-based, and what I want to sort of bring to the attention of the room is that there are a lot of different motivations, possible motivations for being a recipient of address space.
And, you know, so we know what they are. There's participating in a market, for example, buying and selling, hoarding, speculating, subdividing, whatever. There's the forward reserve question. There are any number of different reasons why you might want to receive address space. And needs-based means you want it in order to expand the network. You want it now. You want it soon. You need it soon, because your network is expanding.
The reason that I favor this logic as written is that stewardship for us at ARIN means that we're trying to help the network grow. We're not necessarily trying to help people make money from address space. Other than by building networks and selling services.
Certainly not in the business of helping people receive address space for any other reason.
I would be concerned about stripping that out. I don't think that having this in there means that we are dictating to other regions what their policies ought to be. I think what we're doing is stating our own principles with regard to the resources which we have stewardship. Thank you.
Tim Denton: Thank you very much. Just a moment. Bill Sandiford has an intervention.
Bill Sandiford: Two recipients. Joe Maimon from CHL: In favor as written because I believe that inter-RIR transfers will happen one way or another, and using inter-RIR transfers to help and reinforce the global community's goals and the values that got us this far is a good idea.
And Kevin Oberman from ESnet supports 2011-1: I like the basic concept and feel it will be needed in time.
Tim Denton: Thank you. Sir, you're next.
Jason Weil: Jason Weil, Time Warner Cable. I'm unclear on the text. Does the RIR responsibility transfer to the recipient's RIR? Or is that not clear? If you have an RIR with the original and you transfer it to your new, do you need an RSA with both? Are they going to be in conflict?
Tim Denton: It's a point of information.
John Curran: I guess I'm trying to understand your question, but I guess -- the recipient and another RIR has to qualify according to that RIR's policies to receive address space.
Jason Weil: So now that address space does move to the new RIR and the old RIR --
John Curran: So in terms of registration services, the two RIRs would need to work cooperatively to provide the registration services. There are some interesting behind-the-scenes nuances that occur in areas like inverse DNS and RPKI. But cooperatively that could be done.
Bill Darte: The larger context, the point is that both RIRs are engaged in this process. So if the receiving RIR applies its own current local policy, great. We assume that that would be a goodness in their side. However, ARIN might decide not to allow the transfer if there were not the stipulated needs-based requirements in its estimation.
So both sides would apply some consideration to whether they would agree to this transfer or not in both directions.
Jason Weil: All right. I do support --
Tim Denton: Thank you.
I'm sorry, I interrupted you. You said what?
Jason Weil: I said I do support the concept.
Tim Denton: Thank you very much.
Mr. Poppe is next, and then Heather.
Yves Poppe: Yves Poppe, Tata Communications. One thing I would like to see, again, being a member of most of these RIRs, I notice that you all develop these policies in kind of a splendid isolation.
Wouldn't it be better to have a proposal with at least one bilateral; again, two of the RIRs have to join Draft Policy and then we vote about it? Because at this point in time this is very abstract, and, again, not all RIRs have been created equal, so some are more on the recipient side than on the giving side.
Again, the point Alain was making: I would like to see more clarity. And, in fact, I wonder the rationale itself for proposing a Draft Policy to give away resources, when on the other side other draft policies tried to keep these resources within one region.
So I am utterly confused. Thank you.
Tim Denton: Apart from your confusion, are you in favor of the proposition as written?
Yves Poppe: Not as written. I would like to have at least two RIRs agreeing on one and the same proposition.
Tim Denton: Thank you very much.
Now the Schiller family is next.
Jason Schiller: Jason Schiller, UUNET, Verizon, and the NRO NC. I wanted to respond to the first part of your statement, which is bilateral arrangement.
The way this policy was written and the way this policy was crafted it could presumably be passed in all five regions and it could be a globally coordinated policy.
And some of those five regions could decide to simply opt out on all transfers, in or out of the region. So in that aspect it could end up being a bilateral arrangement. For example, all five RIRs could pass this but possibly only APNIC and ARIN would accept transfers in and out.
In that sense it would function as a bilateral agreement because maybe LACNIC, AFRINIC, RIPE aren't permitting transfers in or out for some particular reason. That's certainly possible for this arrangement.
Tim Denton: So, Jason, I take it you are in favor of this proposal.
Jason Schiller: So I'm one of the originators of the policy. And the policy was written in an effort to help propel along the global Policy Proposal for the post IANA allocation, which this community passed and other communities have abandoned or withdrawn.
And it doesn't seem that that Policy Proposal is moving forward. So most of my justification for supporting this has been removed at this time. But that may change with future global policy proposals that may or may not be on the table.
Tim Denton: Thank you. Heather, you're next.
Heather Schiller: Heather Schiller, Verizon Business. I'm trying to say this correctly. So in this process, the receiving RIR also has to agree to accept the transfer of space. Is that correct?
Bill Darte: Yes.
Heather Schiller: And they apply their local policies about who needs the space in their needs-based process, whatever that may be.
Bill Darte: That's the intention.
Heather Schiller: My concern -- which I'm not sure how real my concern is, but is about kind of fraud of some regions have loose policies about LIRs and obtaining address space and that type of thing.
So I'm a bit concerned about -- about abuse issues. But that happens in those regions regardless. So it doesn't really matter if it's address space that's transferred out of the ARIN region and into another region or whether they get it from the RIR, so that happens regardless, I guess.
Bill Darte: That's the point of the maintain compatible needs-based transfer policies that exercise stewardship, et cetera. That would be an evaluation that ARIN would make against the policies and practices of other RIRs and would be an acid test for support of transfers out of region, I presume.
Heather Schiller: Kind of to what Geoff Huston said, I have a conflict about should ARIN be kind of judging the other RIRs' policies outside of maintaining needs-based assignment, should they be looking at other things that the RIR does in how they allocate addresses and how they determine who they allocate addresses to, or should they stay away from that; in that it's just strictly two organizations want to transfer address space, there's needs-based -- you know, organization A doesn't need it anymore, B does, they've come to some agreement, and there shouldn't be any reason to prevent it.
And I haven't kind of resolved that conflict.
Tim Denton: So you're not in favor and not against, because you can't make up your mind whether we should be judgmental or not?
Heather Schiller: Yes.
Tim Denton: I don't have a problem with judgmentalism. The gentleman from Canberra.
Geoff Huston: Geoff Huston, APNIC. I'd like to respond very quickly to Jason. He made a comment that I think will be incorrect very soon. When he talked about ARIN and APNIC having compatible policies under this proposed policy, that will not be the case very shortly; that when APNIC does give away its last address, it will move to a transfer policy that effectively says if two folk come along to APNIC and say we want a transfer, APNIC will say yes and register the outcome.
That is not including any test or examination by APNIC as to the need of the recipient within APNIC.
So as written, Jason, APNIC and ARIN could not come to an agreement that it is compatible needs-based and that transfers between ARIN and APNIC under this Draft Policy would not be possible from the ARIN side.
From the APNIC side, the Policy Proposal 95, which reached consensus, as I said, will shortly finish its process, the APNIC side is, yeah, it meets our side, it's really up to ARIN's side to go figure.
Hopefully that helps. Thank you.
Chris Grundemann: Chris Grundemann, ARIN AC. A question probably for staff with regard to this bag of worms, I guess.
Once there's an inter-RIR transfer, so say that an ARIN customer or ARIN org transfers to an organization in RIPE, then I guess the question is: Who is responsible for that address? Meaning that if that organization within RIPE then wants to transfer it to an organization within APNIC, does ARIN have any say in whether or not that transfer happens?
John Curran: Let me respond to that and also pick up on Heather's question.
So presuming that a registry in another region has needs-based policies as required, and I'm going to be pedantic and note that it says "policies." It does not say "practices." It does not say anything more.
We work as a system, all the RIRs. We have faith in our sister RIRs.
If they have policies, we presume they implement them. It's not our job to assess that.
And I would probably -- I would strongly voice concerns of heading down a road where we were judging implementation, effectiveness of another RIR. But that's my personal opinion.
But the fact is even though other RIRs has these policies, so now that RIR is potentially recipient of inter-RIR transfers.
Once that's happened, we would ask the RIR, here's a transfer going to someone in your region. Do they meet your policies, yes or no? If they said yes, we would affect the transfer, working with them.
At which point, the address space is registered in the other RIR, and it's subject to that region's policies, because the registrant is in that region. So that would be -- from that point on, it could go through any number of interesting policies once there, yes. Does that answer your question?
Tim Denton: Mr. Springer.
John Springer: John Springer, Inland Telephone. I just wanted to clarify, Counsel's final observation about the no out, is it correct that that's met by the Agree and Maintain Compatible Clause that it would prevent ARIN staff to refuse an inter-region transfer if it would refuse an intra-region transfer?
John Curran: I'll look to see if Counsel's here. He may or may not because we have other things going on.
Tim Denton: Counsel is rising.
John Curran: The question is: With respect to the final observation that a transfer that meets the policies but might otherwise be disallowed by U.S. law, would we have a conflict in trying to follow our own policies if they didn't specifically provide an out for something in violation potentially of law practice?
Steve Ryan: I don't know that I can answer that from horseback, but let me see if I can break down the elements. Let's take the transfer policy which will come into existence or is in existence and is about -- let me take the transfer policy in the APNIC region, which is inconsistent with the transfer policy in this region.
I think we have to have a definitive understanding here what this language would mean if someone wanted to propose a transfer that would be inconsistent with ARIN's policy but consistent with APNIC's policy.
And I think the language here, in my understanding, would not permit us to do that. I think that's the only possible reading of it.
But perhaps the authors or the AC shepherds of the policy see it differently.
I think this is the only possible reading of it, but perhaps I'm wrong.
John Springer: Follow-up?
Tim Denton: Yes.
John Springer: I'm very much inclined to support the policy, but I'm concerned about an ambiguity which would permit an invasion of our policies by jumping into an inter-region policy.
Tim Denton: Thank you. Bill Sandiford heard from...
Bill Sandiford: So Joe Maimon has a question. Joe Maimon from CHL, which, John, you may have actually answered a moment ago, but he's looking for just a hard answer: If when a reclamation is performed after the transfer is completed, will the resources, A, stay at the receiving RIR, or, B, go back to the sending RIR?
He supports the Policy Proposal either way, but he would just like an A or B.
John Curran: Resources are registered to a registrant within the region. To the extent that the resources are inter-region, that RIR is responsible for administration of those resources.
So a reclamation would have to take place by the RIR of that region and the resources would go to wherever that RIR put them when they were reclaimed. There was no case where an RIR takes action to a registration in another region by policy, not that I'm aware of.
Bill Sandiford: Does that make the answer A?
John Curran: I believe -- is A --
Bill Sandiford: Stays where it is.
John Curran: It stays where it is. Yes. Once registered to a region, it's under the administration of that region, the RIR, for that region.
Bill Sandiford: Joe says thank you.
Tim Denton: Vint.
Vint Cerf: Vint Cerf, Google and ARIN Board. This is a question for information. As such an inter-RIR transfer process were -- if it were undertaken, the information about where a particular IP address space is managed and overseen would become more and more fragmented.
Is that an operational issue, or is it already the case that there's a substantial amount of let me call it fragmentation with regard to record keeping and the fact that historically a lot of the address space that would have been allocated was taken from large blocks and stayed within region would change under this policy, does that pose any kind of operational issue, quite apart from the policy questions?
John Curran: The historical practices of the founders of the Internet resulted in -- (laughter) -- resulted in an enormous amount of fragmentation, and this policy will not substantially change that.
Tim Denton: We shall not repeat the comments of Dr. Cerf.
I see no further people pleading to speak. I think it's time we can now take the vote. So our handy vote takers, queue the music. Those in favor of the proposal as written, 2011-1, would they please signify their assent by raising your hand.
John Curran: Nice and high.
Tim Denton: Don't be shy. Those are being counted. And those against the proposition, would they please signify.
Scott Bradner: Scott Bradner. It would be interesting to see how many people are voting against it because they don't want an interregional transfer policy at all or how many didn't want the restriction.
Tim Denton: I'm sorry, Bill Darte was speaking in my ear at the time. Could you just say that again.
Scott Bradner: It would be interesting to know how many people were voting against this proposal because they didn't want an interregional transfer policy at all and how many were voting against it because they don't like the restriction in the proposal.
Tim Denton: Well, I think that what we'll do is we'll take the vote on the proposal before us as written and do that and then we can have another vote on against the idea at all.
So in relation to the vote as taken on the proposition before us, the results, please.
Okay. 2011-1, total number of people voting was 119. In favor of the proposition, 18 people; against the proposition, 11. So there we have that.
Now, can we just do again, for the advice of the Advisory Council, those who do not favor -- put it this way, those who favor, in principle, the creation of an interregional transfer policy -- those who favor in principle the creation of an interregional transfer policy, would they please raise their hands. Just in principle. Okay. Lower your hands.
Those who do not favor, those who are against, in principle, an interregional transfer policy, would they be bold enough to raise their hand.
This is interesting, those who favor in principle, there was 119 people available to vote of whom 41 were in favor and one against.
Mr. Darte would like to make a comment.
Bill Darte: As a parting comment, just in general, the Advisory Council always looks for as much information and input as possible in doing its job in determining the disposition of these draft policies.
In this case, because of that wide divergence in voting, there seems to be some idea in the minds of those who voted the second time in favor in principle but against the current, that something could be changed to make it better.
We are vitally interested in having that information. Please post it to the PPML at your earliest convenience. Thank you.
Tim Denton: In the sage advice of Mr. Bradner, we're going to ask a third question. And it's quite simple.
The proposition then -- the third proposition is those in favor of a transfer policy based on needs, would they please -- so we're going to have yes or no to the proposition -- are you in favor in principle of a needs-based transfer policy? It's a little more precision in the question.
So those in favor of a needs-based transfer of policy, would they please raise their hands. Now lower your hands. And those who are against a policy of interregional transfers based on needs, would they please raise their hands. So as we make policy on the fly -- thank you very much.
So in relation to whether a policy should exist in principle that is based on needs, 119 people were voting and 36 were in favor and two were against. Thank you all very much.
John Curran: Okay. As it turns out, this wonderful discussion has put us exactly on time. It is now time for us to break for lunch. Folks, lunch is -- someone will tell me -- upstairs. And we have to be back here at 1:30 to resume our discussions. So everyone go forth and eat. Remember your discussion table topics, and I'll see you back here at 1:30.
The room is not locked. Take your valuables.
(Lunch break from 12:00 to 1:30.)
John Curran: I'd like to welcome everyone back. We're going to start off our afternoon program, and we have the first item up is the -- first item up we're going to pick up on the morning events. We didn't have a chance to have the Internet Number Resource Status Report. So I'll ask Leslie to come on up and give that. No?
Okay. We're going to skip the Internet Number Resource Status Report. We'll go to the LACNIC Update with Raúl.
Raúl Echeberría: Okay. You can take advantage of this time for taking a nap. I will not be angry.
Okay. This is the evolution -- this is the traditional slide in my presentations, the evolution of our membership. So far we have more than 1600 members today.
Next one. So some updates regarding resources. All the RIRs, we received one /8 in February as part of the implementation of the last allocation of the policy. This is the 179 /8. Those who have not yet updated filters, please do it. This is the number of /8s that we have in our stock. Today is almost 4.5 /8s. We are every day -- we're publishing every two weeks our projections about the exhaustion date in LACNIC region.
Today the projection of exhaustion is 15 of May 2014, but we're updating that very often and probably we'll move to a more frequent updates if needed in the near future.
This is just this talks about allocation. Two comments on that. The first comment is that the percentage of IPv6 allocation is growing significant. We have a significant number of IPv6 allocations compared with IPv4 allocations.
This is one comment. The second comment is that we have not experienced it in the LACNIC region any rush after the IPv4 depletion -- central pool depletion announcement.
But I think it's probably linked with the fact that we are also announcing what is our projection of exhaustion. So I think that is the reason because we have not had any big changes in the behavior of our members.
Next slide, please. Those are the important projects in which we are working at this moment. One is strategic planning. We are working in more customer orientation. We have spent a lot of efforts the last year in working in this aspect from different perspective. Changing the culture of the organization and also working together in exchanging information in a better way within the organization.
And also we are creating now a new position that is the customer manager. So we are in the last part of the hiring process. So we will have this position -- this new person in place in the next few weeks.
And what we are trying to do is to improve the interaction that we have with our customers. The organization has rolled up in the way of columns.
We have the registration services. We have billing and -- invoices and billing. We have membership services. And the interaction between those services is not as good as it should be.
So we expect that with this new orientation that the organization is taking our customers that are the same of our members, they will benefit very much in the future.
Of course, we are working on IPv6 deployment, as we are doing the same things as we have been doing in the last few years, but there's something new we're doing. We're spending more efforts on research and development and also in developing metrics.
But the most innovative thing that we are doing is we are organizing a meeting with the operators in different parts of the regions. We started last week in Argentina.
We have a meeting with 25 operators. Not an open meeting. Meetings just with our members and personalizing the work with the biggest ISPs.
So we do some training also in those meetings, but the most important is the coordination and know what are the obstacles that the ISPs are experiencing in adopting IPv6 and trying to remove those obstacles. Also acting as a bridge with manufacturers and with big carriers in order to implement the implementation of IPv6. The first experience with this meeting last week was very good.
And we will have some few more meetings around the region in this year.
Of course, RPKI is one of the most important projects at this moment. We are working together with the other RIRs. We have launched it in January. There were services. We are close to -- we are working to filter the red line in the third quarter to release the up-down protocol, what will permit to implement the delegated RPKI services.
DNSSEC and other RIRs is something we're working on, too.
Also we started this year working on the quality certification. We expect to have -- to finalize this project for the end of the year.
Beside that we are still running those, some projects that probably you already know. One is AMPARO. It's a project that we ran for promoting the creation of CSIRTs and also the coordination among CSIRTs. We have issued a set of materials this year for public use for -- materials for being used for creating and operating CSIRTs.
And also those materials can be used for trainings in order to multiplicate the impact of this project.
We had a meeting last week, Thursday and Friday, in Montevideo in LACNIC facilities with the most important -- the most relevant professionals in network security in the region for coordinating the second phase of this project. It's a very good project with very good results and very good promise in the second phase.
Those materials are only in Spanish at this moment because they were produced in Spanish, but we are working now in the translation, so we expect to make those materials available in English and Portuguese at some point this year.
FRIDA is a project for funding research activities in -- sorry, in information society issues. So this is a project that is almost finalized. But we are now working with APNIC and AFRINIC in order to have a coordinated program. And so we will still run FRIDA as it is now this year, and probably in 2012 we will have a cross-region project together with APNIC and AFRINIC. The characteristic of the project are not completely decided, but we are working on that.
We're still working in promoting more instances of root server in LACNIC region, as we were not doing anything last year on this point but we're starting again and we plan to set up at least two copies of some root servers in some places in the region this year.
Last year we came back to the fashion of two meetings per year. And the second meeting in 2010 was held in Sao Paulo in Brazil in October. And we co-organized the meeting with LACNOG. It was the first LACNOG meeting. We had almost 300 participants and had opportunity to discuss policy there as we had four policies to reach a consensus in the meeting.
I will not speak about policies because there's some other reports, and Leslie will talk about policies, so I will skip that.
Next meeting. The next meeting will be held in May 15 to 20th of May in Cancun, Mexico. It is something that is funny, because Cancun is northern than San Juan, so -- I don't know, so that's a curiosity.
So we will have the same kind of activities that we have always in our meetings. Not only the policy forum but also forums on IPv6, security, interconnection forum. This is a very interesting meeting, I think, because we expect to have probably the highest participation until now in this meeting.
And what is true is we will have the highest participation from ISPs, especially medium and big ISPs will be present in Cancun.
And everything permits us to think that we will have probably the ISPs that represent about 80 percent of the Internet trafficking in the region in this meeting.
We will have two meetings again this year. The second meeting it will be held in October. It's not confirmed, the venue, but I can tell you that it is not confirmed, but it will be held in Buenos Aries. So what I'm saying, it's not official but it is decided.
So it's a very good venue, too. It's not in the Caribbean, but Buenos Aries is a beautiful city that offers very broad -- provides a very broad offer of entertainment and interesting things, culture and historic sites for visiting, besides, of course, the possibility to attend the LACNIC meeting that is the most important.
And so thank you very much. That's all, folks.
John Curran: Thank you, Raúl. It is now right after 1:45, so it's time for us to go back into policy. The first policy for the afternoon block is the ARIN 2011-4 Reserved Pool for Critical Infrastructure.
I will give the introduction of this and then I will ask Scott Leibrand to come up and do the AC report.
John Curran: So the history of 2011-4 started out as ARIN Proposition 123 Policy Proposal in November of 2010. AC shepherds, Scott Leibrand and David Farmer. AC selected as Draft Policy in its January 28th meeting. It was posted to the PPML with a staff assessment on the 3rd of February. The current version is the version from the 23rd of November. It's contained in your Discussion Guide.
The policy would reidentify a /16 equivalent for issuing under the IPv4 micro-allocations for critical infrastructure policy. If any of the reserved addresses are unused, 36 months after implementation, ARIN may use the addresses for other purposes.
Status: Similar policies adopted in APNIC and RIPE.
Staff comments or concerns: Suggestion to specifically state critical infrastructure as defined as NRPM Section 4.4. This has been done. And to put the policy term in the policy text. Change "at the end of the policy term" to "36 months policy implementation." This has been done as well.
Resource impact: Minimal.
Legal assessment: No legal comments.
Discussion: Little discussion of the Draft Policy. Earlier discussion of the proposal had 53 posts by 19 people. Six in favor and one against.
"Critical infrastructure is definitely outside the intended scope of 4.10 and this proposal is needed."
"Perhaps the Policy Proposal could be revised to require all critical infrastructure applicants justifying and applying for reserved space to be required to show plans for parallel IPv6 deployment of new infrastructure."
That's just a sample of some of the comments received. Give you some idea of the discussion on the PPML. And then I'll invite Scott up. Scott.
Scott Leibrand: So 2011-4 was originally proposed by Martin Hannigan. Myself and David Farmer are the shepherds.
Why was this put forward and why are we discussing it? The IPv4 address pool is going to be exhausted very shortly. I think we've all been looking at our watches.
We have been reserving a /10 to facilitate IPv6 deployment, but as was noted in one of the PPML comments, that does not reserve space for critical infrastructure needs.
So some critical infrastructure providers may be unable to acquire IPv4 space on the transfer market.
So what this policy would do is place a /16 worth of space in reserve and allocate from that reserve /16 worth of space for NRPM 4.4 micro-allocation which is critical infrastructure needs. And if the /16 is not used up in 36 months, that would be released for other uses.
This is the Draft Policy text. The first three lines there were written before the exhaustion occurred, so they're no longer relevant.
But it's pretty simple text. Just as we're going to reserve a /16 worth of space. That's not a contiguous /16, it's just a /16 worth of space.
So advantages of the proposal would be that it continues existing policies of allocation for these critical infrastructure needs, like exchange points, top-level domain operators, et cetera, and the level of demand for such needs is fairly small, so only a /16 is needed, and it doesn't have to be contiguous because most of those allocations are small, 22 to 24 range probably.
Some cons to this proposal possibly would be that it's putting in place a regime that would favor these critical infrastructure needs over other needs. That could be a pro or con depending on your perspective; that that /16 is no longer available for other use, again, a pro or a con depending on your perspective; and that these needs may or may not be considered critical to the operation of Internet infrastructure as they were when NRPM 4.4 was first introduced.
So we've already heard about the staff assessment. That comment was addressed and the other one can be addressed very easily just by moving up a section.
So really the reason for this discussion is to figure out what people think. Do we need to have a policy to reserve space for critical infrastructure needs? Yes? No? Opinions?
Alain Durand: Alain Durand, Juniper Networks. I was one who initially suggested to reserve space for IPv6 deployment /10. I would like to say that I support this proposal, but I would also like to suggest to increase the size from a /16 to something bigger. And the reason is IPv4 is not going to go away anytime soon.
Regardless of what IPv6 is doing or not doing, we're going to have to support some v4 service for a very, very long time, so there's going to be a lot of critical infrastructure in the future, but we require some v4 space, and I will hate to exhaust a /16. Right now we still have some space, so I would suggest to put it at least a /12 or even a /10.
John Curran: Kevin, you're next.
Kevin Blumberg: Kevin Blumberg, The Wire. I support this proposal. Again, I also have an issue with the /16. The 256 Class Cs, that's not a lot, especially if one company comes along and says we have to deploy to 15 or 20 locations. You could see that disappear very fast.
In the past they would have just gone through not using the micro-allocation. So the prior use I don't think necessarily relates to what post exhaustion use of this will be.
So I would recommend increasing the size, but also possibly putting a limit on any one company's use of this allocation. Thank you.
Tim Denton: Thank you. Owen DeLong.
Owen DeLong: Owen DeLong, Hurricane Electric. I'm in support of the proposal as written. I don't think we need to expand it beyond the 16. We really are talking about Anycast DNS and exchange points. I don't think there's going to be a lot of important growth in those in v4 beyond about the next two or three years.
Anybody that hasn't got the message that v4 is running out of room yet, this is your wake-up call again.
V4 is going away, and we're not going to be able to keep expanding it no matter how hard we close our eyes and pretend. Get over it.
Tim Denton: Thank you.
Heather Schiller: Heather Schiller, Verizon. I think Leslie might actually be working on what I'm about to ask for if I'm guessing correctly.
I think that there's a lot of v4 space currently -- ARIN currently sets aside v4 space for critical infrastructure. They have ranges that are used specifically for that.
And I think it would be helpful if staff could say how much space is in there before we decide to chuck another 16. Thanks.
I don't know if that's part of your report that you make -- I don't know if you do that during the meeting, but you have the report that you give at every meeting that says how many allocations you've made and sometimes you break out allocations versus assignments versus critical infrastructure.
I think that kind of information would be helpful to folks before we...
Leslie Nobile: Okay. Leslie Nobile with ARIN. So currently for micro-allocations we are issuing we've held space from the old 199 block. That's where we've been issuing from. And also from 192 block, which we have put on hold. But we do issue from 199 discontiguous /24s, and I think we have -- I think my number said 227 /24s left in the 199 block and many, many more, probably, oh, maybe closer to 2,000 in the 192 block of discontiguous 24s.
So we have plenty of space in those blocks that we have held aside specifically for micro-allocations.
Tim Denton: Thank you.
Mike Joseph: Mike Joseph, Google. I support this proposal. And I'd also suggest striking the three-year holding period. I don't think it seems very likely that after three years we need this to revert. If we reach that point where we determine that we want to send this back to the free pool, that will give us plenty of time to handle that through the policy process.
I think to have -- if the space is really critical, it probably ought not time out.
Tim Denton: So just to understand, you were in favor of the proposal?
Mike Joseph: I'm in favor of the proposal, but I would urge my colleagues to support removal of the three-year requirement.
Tim Denton: Thank you.
Cathy Aronson: Cathy Aronson, ARIN AC. I had another question for Leslie. You have those blocks and they're reserved for critical infrastructure, but my understanding from a conversation -- I don't know when it was -- was that when those were needed for regular allocations that those would be released and that they weren't specifically held for all eternity for critical infrastructure.
Leslie Nobile: When we first had that conversation, Cathy, I actually gave you a list of all the discontiguous /24s. I kind of gave you everything we had. It was a lot. John sort of corrected it and said that's what we have.
But if it becomes necessary, we'll release them into the pool. These blocks are ones we held specifically for critical infrastructure, and there's some space left. There's not that much.
But John will probably say again, if need be, we'll have to release them at some point.
John Curran: Right. The question that will come up is: At the point in time when we have no other resources available, would the community want us to tap into these and make allocations? They're administratively held within the staff. They're not held by policy.
So if you want something that survives depletion, having it specified in the policy is a great thing.
Leslie Nobile: That was my point.
Tim Denton: Are you responding to Cathy Aronson?
Leslie Nobile: I'm adding. Sorry. Yes. And someone just asked me something.
I went back and looked at the critical infrastructure, the micro-allocations we've made for critical infrastructure in the ARIN region since this policy was implemented many moons ago -- I mean, it's been well over five years, probably closer to ten -- and we've made less than -- roughly 50 micro-allocations under this policy in all of those years.
So it's not used very frequently; probably 10 to 12 times per year. Just to let people know.
Tim Denton: Thank you.
Jason Schiller: Jason Schiller, UUNET, Verizon, NRO NC. Following up on John's comments, I just want to make sure that I and the room are clear on this: The policy we're discussing now seeks to reserve additional -- an additional /16, or possibly more, as some people have suggested, for critical infrastructure and not specifically reserve the 199 and 192 space which is currently critical infrastructure but not specifically reserved for that purpose once ARIN depletes.
John Curran: The policy you're currently discussing says an equivalent of /16. When adopted, we will make sure, upon adoption, there's an equivalent of /16 available for critical infrastructure from that point going forward.
Jason Schiller: That would be some portion of the 192 and 199 space?
John Curran: Could be.
Jason Schiller: Likely? Not likely?
John Curran: If you have a preference and you put it in policy, it's assured.
Tim Denton: Okay. Chris Grundemann has an intervention.
Chris Grundemann: I didn't know I needed an intervention. I have a remote participant. It's from Joe Maimon of CHL: In favor of this proposal as well as almost any proposal that would hold on to v4 space longer for when we potentially need it even more.
With regard to the size of the pool, allowing ARIN to replenish the pool if and when resources are available, if and when the pool falls below 50 percent, would work for me as well.
Tim Denton: Thank you.
Lee Howard: Lee Howard, Time Warner Cable. To the extent this limits the reservation from these several hundreds that are apparently sort of administratively held right now to only 256 /24s, that sounds like a good thing.
It sounds like it's going sort of the opposite direction of the way the authors intended, though.
I have to confess that I don't really understand the definition and the need of critical infrastructure. It sounds important. But I don't understand the network architecture of the kinds of things that we're talking about and why globally unique IPv4 addresses are more important for the defined things in Section -- sorry, whatever the section it is of the NRPM -- 4.4. As defined in Section 4.4. It says it right there on the screen, doesn't it?
So in order to make an educated -- in order to have an educated position, I need to understand that sort of network architecture better.
But having said that -- not just the network architecture, but why the need for this particular model or these needs is greater than for anybody else's need.
Tim Denton: That was a point of information you were asking. And two members at least here were jumping to answer you.
Scott Leibrand: I was going to answer the first half of that as I understand the intent of this policy is to move some subset of the space currently reserved administratively for critical infrastructure into being reserved in such a way it will not become unreserved when we hit exhaustion.
So we're not so much expanding the amount of space being reserved or reducing the amount being reserved, we are creating a reservation of size /16 that persists through exhaustion.
Cathy Aronson: Can I answer as well?
Tim Denton: Okay.
Cathy Aronson: This is Cathy Aronson again. When that policy was written, it was written specifically because critical infrastructure needed blocks that were longer than the minimum allocation. That's where that came from. Like an exchange point provider needed to be able to get a /24 and they couldn't. That's how that came up.
Tim Denton: Mr. Woodcock.
Bill Woodcock: To answer Lee's question, critical infrastructure is infrastructure upon which we are all dependent rather than the infrastructure upon which any one of us is dependent. Therefore, Internet exchange points and the core of the DNS are critical infrastructure because, if they do not function properly, all of our businesses are disadvantaged as opposed to an address not being available for one of us, and that one's business is disadvantaged but someone else's is advantaged.
Tim Denton: Mr. Vixie.
Paul Vixie: I'd like to ask a question of the authors. Critical infrastructure is a little ambiguous. Let me give you my experience as the operator of F-root. Clearly, F-root has a critical infrastructure prefix, actually predates ARIN, and we don't need more of those in order to install more F-root nodes. What we do consume for new F-root nodes is new prefixes for management, management networks, because we like those to be provider-independent, multi-homed, et cetera.
Up until now we have not succeeded in being able to do a v6-only management prefix for a new F-root node. It's expected that we will soon be able to begin doing that.
It's also expected that if we were forced to go with provider-assigned non-multi-homed space for the management prefix, we could.
So I wonder could the authors maybe talk about what you mean by core DNS service providers given that I've got three different ways that I could imagine using this, and I imagine that other operators will also see the ambiguity.
Scott Leibrand: I don't think I have an answer to that question beyond the observation that we referred to 4.4 but did not choose the wording in any way. So I would defer to staff's interpretation of 4.4, as they do now, as far as whether that would apply.
John Curran: So this policy doesn't change 4.4; in fact, it nicely references it. To the extent that you want the cakes you express, private management network for DNS infrastructure, to be included or excluded from 4.4, a short tactical Policy Proposal to do that would be very appreciated.
Tim Denton: Mr. Howard.
Lee Howard: Lee Howard, Time Warner Cable. And I will stop coming to the mic if I'm the only ignorant person in the room, which is entirely possible.
Bill tried to explain to me, and I know -- I think I know what an exchange point is and I think I know what a root server is; I think I even know what an Anycast root server instance is. What I don't know is why after ARIN is out of IPv4 addresses to allocate or assign those pieces of infrastructure continue growing.
Tim Denton: Mr. Curran.
John Curran: So hypothecate a decision by like ICANN which is listed in 4.4 to create, oh, some more top-level domains, all of which have a handful of servers. And by definition these new global TLDs, you really do want them to be able to be found and you don't want them to be on provider-based addresses that might have to be renumbered, because it's a nightmare to go through that process.
That could happen this year, next year, five years from now, and ten years from now.
We might not have numbers available to give to new core pieces of DNS infrastructure that happen in the future.
Tim Denton: I believe it's Mr. Pounsett and then Mr. Morrow.
Matt Pounsett: Matt Pounsett, Afilias. To answer Lee's question, there have been a bunch of attempts in the past to try to correlate DNS query activity to other things, such as the size of the zone that they're in. So, for example, TLDs where I operate attempts to correlate DNS query load to how many domains are registered in the zone. That doesn't work.
And it's been tried to correlate it against sort of the size of the Internet in general, and that only works a little bit.
The query activity is actually driven more by the applications people are using and how much they're using those applications, rather than -- as much or more than how many people there are.
So, for example, as people move more and more to using Twitter and using Facebook and as more and more of these sorts of applications work their way into people's lives, they generate more and more DNS activity.
And so as long as those applications are still using the v4 Internet, there still needs to be new v4-reachable DNS infrastructure.
So that will tail off eventually, but it doesn't start tailing off the day ARIN runs out of address space; it tails off some time later.
Tim Denton: Mr. Morrow, then Mr. Woodcock.
Chris Morrow: First of all, I'm generally in favor of the policy. But I think to answer Lee's question, which partly was answered by John, every time there's a new TLD that shows up, and, in fact, sometimes if there's a new second-level domain that shows up, you want to make sure that that lives on distinct IP space so that its reachability could be as short as much as possible, it can be segregated for things you care about as well.
Tim Denton: Mr. Woodcock.
Bill Woodcock: I think people have done a good job of explaining the value of DNS addresses being available for -- or, sorry, IP addresses being available for DNS operators.
I think a lot of people in this room probably don't really deal much with the economics of Internet commodity production. They more deal with sort of the day-to-day expenses of it.
But the value of the service that you are providing to your customers is coming from Internet exchange points. And there are a lot of ways of testing that assertion and they've all been tested, and I'll be happy to go through it in detail with anybody who wants it. But if exchange points don't grow, your businesses don't grow.
So having exchange points unable to grow after three years from now would mean that the entire v4 portion of your business would stop growing at that point. And you don't want that because the v4 portion of your business in three years will be still quite large, unfortunately.
It will probably be 10 or 15 or 20 years before that is negligible. Unfortunately.
Wesley George: Wes George with Sprint. In light of the recent conversation, I'm actually opposed to this proposal.
I think that ARIN has been pretty consistent in telling the vast majority of anyone who will listen, specifically our membership, that expecting to grow on IPv4 indefinitely is a no-op.
With the background that originally the reason we carved this out separately for infrastructure was due to the fact that we had a difference in minimal allocation unit and what actually made sense in those cases.
I think we're making a distinction where one no longer needs to exist. And again we're playing this game of which business is more important.
Personally, I kind of feel like we have to draw the line somewhere in terms of gTLD growth, just like everything else. You want more gTLDs, great, but at some point they're not going to do IPv4. That's the reality we live in.
You want more Internet exchange points, great. At some point your business is going to have to stop growing on IPv4. If this is one more thing that creates an incentive to move more things to IPv6. I don't think that's a bad thing.
I think that we would be better off leaving this out and leaving it to staff discretion as to how they manage how much of this is available based on things like the current burn rate of these resources and let it be a little more equitable and break what is basically a special dispensation that no longer needs to be there, if I'm understanding the policy correctly.
Tim Denton: Thank you. Mr. Farmer.
David Farmer: David Farmer, University of Minnesota, ARIN AC. I would disagree. Not only does this allow a smaller allocation that wasn't allowed at the time, but it also changes the justification criteria. You just need to be a TLD operator. You don't need to have 50 percent of a 24 justified in order to get a 24.
So the mere fact that you are operating critical infrastructure entitles you to an allocation or assignment or whatever it is.
Whereas, under normal rules you would have to justify your usage.
Wesley George: I don't think there's any problem with that. I'm simply saying get in line with everybody else.
Tim Denton: So noted.
Any further discussion?
Heather Schiller: Thanks to Leslie for providing information. I think that I'm opposed to this policy. I think that the author's intent was to set aside address space to preserve v4 for critical infrastructure. But I think in a way ARIN's done that.
I'm not entirely opposed to it at some point in the future, I just don't think -- I think that implementing reserving a /16 now is less space than they currently have reserved, and I think that a year from now or longer, if it becomes an issue, then an amount of space can be reserved, but reserving something longer than what ARIN's already put aside is -- it's less than what they currently have set aside for critical infrastructure. So let it be.
Scott Leibrand: I think the distinction is that ARIN staff has very clearly said that this reservation is nothing more than a we allocate these blocks out of this space, we allocate these other kind of blocks out of this space. It's not a we're not going to allocate anything but this out of this space. So as soon as we hit exhaustion, ARIN staff has told us that they will dip into this space unless there is policy like this to indicate otherwise.
Heather Schiller: Right. And I think that what I'm trying to say is that ARIN staff is -- I don't think they're going to go like crazy and decide to just start using the 199 space just because they can. They're sane, rational people that make --
No, no, no, no, no. What I'm saying is -- no. Hang on a second. Because what Leslie said is they made 50 allocations since the policy was implemented. I don't see -- I mean, unless you're saying that there is a line out the door for critical infrastructure space, which I don't see as the case -- so I think that they have 2200 /24s set aside -- I would prefer to see a policy that said if the amount of space -- set the amount of space you have currently set aside in reserve and formalize that, rather than making it a smaller amount than the 16 that's proposed in this policy.
Tim Denton: I'm unable to discern whether it was Matt or Alain who was first.
Alain Durand: Alain Durand. So from what I understand from staff is that it's not cast in policies that the usage of this space is for critical infrastructure.
So my understanding of this is when run-out happens and you ask for space, there is little bits of space that is labeled normal, except that we have been using for critical infrastructure, this space will be used to serve the request. Am I correct, Leslie?
John Curran: Yes.
Alain Durand: So it seems to me that those resources and those critical infrastructures are really special. We need to formalize that this space is reserved for critical infrastructure and not used for other purposes.
Either we say this is a /16 or we formalize what the space is there already. It doesn't matter to me as long as we reserve some space for critical infrastructure.
Tim Denton: So you're in favor of the proposition.
Alain Durand: I'm still in favor of the proposition.
Tim Denton: Thank you very much.
Louis Lee: Louis Lee, Equinix and NRO Number Council. I'm speaking on behalf of Equinix here as an exchange point operator. Even though if the v4 Internet does not continue to grow at some point, we can still benefit from increased connectiveness between the existing v4 operators.
So being able to turn up an exchange point where there is a need to do so would be advantageous, would be good.
Tim Denton: You're in favor of the proposition?
Louis Lee: Yes, I am.
Tim Denton: John, are you trying to speak?
John Curran: I'll wait till after Heather.
Tim Denton: Okay. It was Chris Grundemann, then Heather, then John.
You had something, Chris?
Chris Grundemann: I have a remote participant. Kevin Oberman of ESnet: Sometime in the future will be too late to have a /16 to reserve. And I currently support this as written.
Tim Denton: Thank you.
Heather Schiller: Everybody pull out your NRPM, because -- or, actually, it's right there. Hey, it's right there. It says that allocations must be allocated from specific blocks reserved only for this purpose. ARIN has already reserved. Leslie got up and said how much space they've reserved for this purpose.
Is that not sufficient? Or is your goal to reserve less space than they currently have set aside?
Tim Denton: Mr. Curran will answer that question.
John Curran: So we have blocks that right now are reserved for this purpose, and we're not using them for anything else.
At the point in time when we have no other space available and someone comes up and asks for an allocation so they can continue running their business, if you believe we should maintain that, we would probably like to have very clear policy as to why we're holding that much space away when someone's business is going to get impacted and they need additional space.
So while we have administratively set aside some blocks, we don't have a policy that the community has said: Leave this much space out of the reach of all us for the good of critical infrastructure.
Cathy Aronson: The default action is? If there's no default action, what's your policy?
John Curran: Ask the Board. Yes, I will make a good judgment. I'll tell the Board what we're doing. And of course we'll exercise reasonable judgment. Recognize some of you right now may say, well, that's good. You might be the one I'm turning down because we're holding those blocks unavailable. Okay? To the extent you wish to have critical infrastructure reserved, I would like to have a policy to make that clear. If you don't, you can live with that, but recognize the risk ARIN entails.
Tim Denton: Anyone wish to speak further? Matt, are you hovering? No? Mr. Schiller.
Jason Schiller: Jason Schiller, UUNET, Verizon. I would prefer that this policy state that those specifically -- if there is a reserve, those blocks specifically come from the blocks that are currently reserved for that function, or at least have the understanding that that is what staff plans to do.
I would not like to see yet another block reserved from some other space, whether it's the last /8 or something else that's in ARIN inventory.
And I think that was the intent of the originator of this policy as well.
Tim Denton: Chris Grundemann.
Chris Grundemann: I'm channeling Lea Roberts from Stanford: I support the policy as written, and I believe it is important to have clear reserve for this purpose well into the future.
Scott Leibrand: I'd like to respond to Jason. Jason, yes, that seems to have been the intent of the originator and it's certainly the intent of those of us who modified the language to make it clear that it's not a contiguous /16 that's required; that it's specifically done in order to allow ARIN to choose whichever blocks are administratively best for this purpose.
Seeing no further people wishing to discuss, I think it's now time to put the question.
So Mr. Alexander.
Dan Alexander: Dan Alexander, ARIN AC.
Tim Denton: Last call.
Dan Alexander: Would it be fair to pose the question under that interpretation that it would be from the existing space when asking for and against this proposal?
Scott Leibrand: I believe it's implied. If staff would execute this policy in any other method, in any other manner, I think it would be good to hear that now.
John Curran: We intend to cover the existing blocks with this, obviously. It may not totally cover it, but we'll make sure there's a /16 of total space available preserving the existing blocks to the extent that that covers it.
Tim Denton: Okay. So our tabulators are there. So those in favor of the proposition, please signify your ascent by raising your hands high.
Those against the proposition, would they please signify their dissent by raising their hands high.
Jason, what are you doing?
Jason Schiller: Could I ask the Chair to take the temperature of the room on in favor and opposed to simply reserving the existing blocks -- the remainder balance of the existing blocks?
Tim Denton: You can, but I'm going to process that question in a minute, so stay by the microphone.
In relation to 2011-4, total people meeting room, 112. In favor, 36; against, 10.
Jason Schiller: Yeah, I just wanted to see the temperature of the room for how many people would be in favor of taking the existing blocks that are currently administratively held for critical infrastructure and codifying to make it reserved so that post-depletion we would not dip into that space.
Tim Denton: I'm sorry, that's a proposition too long. I'm not sure I could repeat it.
Jason Schiller: Instead of setting aside a 16 like this policy suggests, take the 199 block and the 192 block and make them reserved, period.
Tim Denton: 192 block and 199 and reserve them.
Jason Schiller: Existing blocks.
Tim Denton: Raise your hand in terms of what --
Owen DeLong: Owen DeLong, Hurricane Electric and the ARIN Advisory Council. I think that's a question better asked by a new Policy Proposal. I think that the Policy Proposal on the floor is radically different than that and that this is -- without sending it to the mailing list and such first, just asking the room is kind of random.
Tim Denton: You think it's out of order?
Owen DeLong: Yeah.
Tim Denton: I'm incline to accept Owen DeLong's point of view, frankly. I think it would be unwise to make policy on the fly if it's a radically different order, and I think it should go through the process, Jason. I think it would be best if we did it that way.
Jason Schiller: Jason Schiller, Verizon, UUNET. I'm not suggesting we get policy on the fly; I'm suggesting we get a temperature of the room for advice to the AC; that they can know how to proceed in this matter.
Tim Denton: Mr. DeLong, do you have a view?
Owen DeLong: I don't think it's necessary to get a sense of the room right now on what policy is not yet proposed for the AC. I don't think we need it.
Alain Durand: Alain Durand, Juniper Networks. I don't think this is a radically different proposal. This is just a different way of implementing it. I would support taking the sense of the room.
I would also like to say that we are -- many people have pointed out we're all looking at our watch and the next policy cycle may be just too late.
Tim Denton: Yes, exactly.
John Curran: May I?
Tim Denton: Sir.
John Curran: Jason, as an alternative, staff could provide a breakdown of what's available in 199, 192, and there's actually a third small block, and the total size and what would be involved if those were reserved in total and we can provide that to the AC and they will have that information to decide whether they want to put in or not put in and whether they want to bring that issue to the mailing list or not.
Would that be -- that way they could phrase it in a way of an actual question with some hard facts behind it. Would that be sufficient? Or would you still want to poll the room now?
Jason Schiller: I mean, if other people don't want the room polled, that's fine. But I thought we had a sufficient idea of what the balance of that space was, 2,000 addresses in 192 and 227 and 199, a few other fragments running around somewhere else. So 2200 addresses plus some.
John Curran: It turns out 199 is only at about 1,095 right now. So you're looking at about a /14 or a 14.5. Somewhere in there. It's a larger allocation you'd be reserving if you wanted to reserve these particular blocks.
I guess what I'm saying is that we could talk about which blocks to include and how much space is in each, and then try to take a show of hands here, but it might be better for the AC to actually look at that and decide what makes good sense and put it to the mailing list.
Jason Schiller: If the AC doesn't want to know how the community feels about this, then so be it.
Tim Denton: Mr. Farmer has a view.
David Farmer: I would like to hear the temperature of the room on an issue similar to this, and maybe we can solve this problem and take something we do forward.
That is, could we ask who would be in favor of a larger allocation, leave it up to the AC to figure out the details, but knowing that the sense of the room is that a larger allocation would be acceptable would be very helpful for me on the AC to know.
Tim Denton: A larger allocation than what would be acceptable --
David Farmer: Than the current 16.
Tim Denton: A larger allocation than the current 16.
David Farmer: The larger reservation than the current 16.
Tim Denton: Current 16. I think that would be -- ah, Mr. Sweeting.
John Sweeting: Could I suggest you put the question to the room and we'll get done much quicker. It's not going to hurt.
Tim Denton: So the question to be put to the room is should the larger block be reserved for critical infrastructure. All right. Those in favor of that proposition --
Lee Howard: Mr. Chairman, the motion has not been debated.
Tim Denton: No, it hasn't been debated.
Lee Howard: This should be open mic.
Tim Denton: I think this is -- we can have it again at open mic if you want. I am against this kind of procedural wrangling about stuff. If they just want a temperature of the room. The Advisory Council wants to be advised. It has asked to be advised. I would like now to gather hands in favor of the proposition, whether a larger block should be reserved for critical infrastructure.
Hands up those who favor that idea. Okay. Those who are against that idea, would they please signify. Okay. Thank you.
So at the request of the chairman of the Advisory Council, we have taken the straw poll in relation to this proposition. 112 people in the meeting or in remote. A larger block to be reserved for critical infrastructure: In favor, 18; and against, 12. Thank you all very much.
John Curran: Okay. That concludes our afternoon policy block. We're now going to get the APNIC RIR update from Geoff Huston.
Geoff Huston: I'm Geoff Huston. I'm with APNIC. I am the only member of the research department whereas the communications department seems to employ about 300 people. And all of them contributed a slide to this report.
So I'm going to have to go through this really quickly. Next slide. Or do I have control here? Oh, good. This is the overview. I'll talk about lots of things quickly.
We gave away a whole bunch of addresses last year. And I like the way this is presented. Because it makes 2010 in v4 -- that's the blue line going up -- look only slightly larger than 2009.
And I've actually heard someone from APNIC say, oh, no, we didn't panic, didn't panic at all. Rubbish.
We panicked. Oh, we panicked really good. We're currently handing out addresses such that if we were allowed to do so for the next 364 days, we would get through 26 /8s. So we're getting through one every two weeks at the moment, which is the highest rate we've ever done ever, which means the poor registration services folk are working really, really, really hard, but they're going to have a holiday. Very soon. Very, very soon.
Again, I'll look at my watch. That's about the best hint I can give you. This cannot last and it will not last.
Oddly enough, if you actually count the number of addresses, we gave away more v6 addresses than v4 addresses, which is kind of fascinating, but I think also doesn't mean an awful lot. Because these days we give out v6 by the truckload. So last year we gave out an astonishing number of truckloads of these v6 addresses.
Back to v4. We're heading towards this stage three. Stage three says final /8, all bets are off. And the basic warning is really, really soon.
On the other hand, what we also have done is tried very hard in our region to actually get v6 out there.
You saw that in the delegation. We've now done one-click v6, so that for many folk who have existing v4 infrastructure, who actually already qualify under the existing infrastructure policy, they can get a v6 allocation online instantly, simply as a one-click.
We actually had quite a lot of response to that with 402 folk last year taking advantage. So we're very, very pleased about that program. It's one way to make sure we do what we can as a registry, because we don't buy the infrastructure, we don't build the networks, but we can supply you with v6 addresses really easily, and we're certainly doing that.
The other thing we've been doing is these addresses are actually -- the last ones, they're pretty crap. We looked last year at Network 1 and found that some people, naughty Cisco, have been using 18.104.22.168. Don't. I have it. Look in the registry. It's not yours. Stop it.
But they're not the only ones. There's lots of folk who actually are using addresses out there. And these old blocks, particularly the old Bs, have been used by lots of people in lots of weird and daft ways.
These days we've been testing every single block before we send it out. The last one we tested was the /8 Network 103. Some of those reports are actually very interesting. And when you look at this, you might think in this next brave world of transferring addresses, you might want to have a look at what you're thinking about transferring into you before you actually conclude the deal.
Because some of these addresses do have a history that the only way you can find out about them is by advertising it and looking at the resultant incoming traffic.
Reports are at the APNIC website. We actually make these detailed reports public and available. And they're fascinating reading.
What we find is individual addresses, single addresses are tainted in the weirdest and most wonderful ways.
Some of it is basically vendor error. Some of it is online gamers. And some of it is so bizarre, I never want to see it again. It's just weird.
So the report's there. Have fun. Lots of members, lots of folks seem to want to have addresses, particularly v4 addresses, and oddly enough the phone is not dead. These people keep ringing us thousands of times a year and they also use chat, so there you go.
Yes, lots of stuff down there in member services. What we've been playing with is actually in DNSSEC and actually putting DNSSEC support into our reverse DNS. So in terms of promulgating helping the deployment of DNSSEC, we've done our bit in adding DS records into the reverse DNS as part of our support in our three-stage plan of putting DNSSEC up for reverse DNS.
The policy folk, your counterparts in APNIC, have been busy, busy, busy, busy making lots of policies. We implemented all these. Go see the slides. We had a whole bunch that reached consensus.
I won't go through them in detail, other than to highlight Proposition 95 reached consensus, which is what I talked about this morning, an APNIC proposal about address transfer policies between RIRs that was effectively each party satisfies the requirements in its own RIR without imposing conditions on the other.
And the other one, Proposition 97, is a start of a proposal that's going the rounds of global policy.
I believe it will pop up at RIPE. But I didn't see it in this meeting. I don't know if it is coming or not. Is it the Philip Smith one? So you're going to have the same fun and probably someone will pop up at the time and say it's reached consensus at APNIC, which it did in February.
The things that didn't reach consensus are listed there, including optimizing IPv6 allocation strategies, which I think might be coming here, and a global policy on v4 allocations post exhaustion, which did not reach consensus.
One is still under discussion. And one that I referred this morning was discreetly and gently passed back to the mailing list for further discussion.
What else have we been doing? We've done -- IN-ADDR.ARPA has finally moved away from the root zone of the DNS and now has its own infrastructure. This is the RIRs working right up there at the speed of light. The initial instructions from the IETF to do this date back about ten years ago. I know because I wrote them. So we've been working very hard and very diligently, and ten years later we can tick that box. Aren't we good?
Over in the research and development department, me, with a lot of help from George Michaelson, have also been working very, very hard as well as measuring traffic blocks and looking at the DNS and also working on RPKI.
We spent a lot of time looking at how broken and busted IPv6 is. And in particular looking at transition technologies, 6to4 in Teredo, and looking at exactly what happens.
And in trying to do this what we sorely need is data. And what you guys have, particularly those who run content, is data. And we've noticed you make a lot of use of Google Analytics.
So we thought: A-ha. Here's a tool that you can use that you add to your existing Google Analytics code which will tell you about your client's capabilities in v6 without having to dual stack or v6 your site. We do all the work for you and tell you what could happen if you went dual stack: performance times, capabilities, and all of that.
So have a look at labs.apnic.net when you have time and see what you think. And if you like it, add it to your own code. You don't need to talk to us; you can just simply do it. And Google Analytics will then report back to you about what's happening with your customers and your clients and v6. They were hard at work. It was done only two weeks ago in a mad, frantic hurry at the IETF.
We've also been going to lots of meetings talking about the fact we're running out of v4 addresses. What a surprise. And v6 is a really cool thing and you should do it. You really, really should. And we're also serving as the secretariat for the Asia-Pacific IPv6 task force.
Every couple of years we do a member survey just to make sure that we're kind of on track with the expectations of our stakeholders and community.
This time around we got quite a few responses, up to 800. It makes interesting reading. Some of the stuff is kind of self-congratulatory in some ways, you know: APNIC communicates in a way that meets my needs, we should do a help desk and training and so on. That's kind of vanilla and expected.
But what's interesting is the bottom top ten. And I liked the one right at the top. There are suggestions in our community to form the equivalent of a government advisory committee similar to ICANN. And we asked membership do they agree. And, interestingly, it was one of the bottom ten. They kind of think that the public involvement in terms of public policy in government is fine in ICANN, but they didn't really want it pushed harder in APNIC as a formal body. Interesting.
On the other hand, when we said do you agree with the proposition that our current level of engagement with governments is fine, they also disagreed with that.
So there's this kind of sense from the membership that we should be involving public policy and public regulators; in other words, involving governments in our process. But not necessarily in the way of the ICANN government advisory committee.
So at this point we're mulling over trying to understand how we go from being a purely we're just the group who meets whoever is in the room, in terms of members and engagement with industry, into saying, well, we actually engage more broadly with all stakeholders including the public sector. And that's going to be our challenge over the next months and possibly years.
In terms of resourcing, there's a strong push to get behind v6 and a strong push to get behind routing and registry security. And I must admit we've done a huge amount of work there, particularly on the RPKI, and we proudly say that we have had an operational RPKI infrastructure in place in APNIC since September 2009. So we've been working at that for some time and are quite pleased with that.
We've also moved offices. And this is probably PowerPoint animation. We moved across Brisbane River. That's the sort of dirty green bit in the middle. We moved from one part to another. And that was the picture on the 12th of January. Brisbane -- I don't live there. I live down south where it doesn't rain as much. But there it rains a lot. It's a swanky new premises and all that and looks very bright and wonderful.
Unfortunately, the hills in behind Brisbane the last three days before we moved, it was pissing down with rain. The dam got full and they said, Oh, dear, time to open the gates. So they opened the gates really, really badly. If I had a laser pointer, that big square thing at the top -- do I? That -- it's a cricket pitch. It's now a swimming pool, a dirty brown swimming pool.
This was a floating restaurant when the plane went over. About an hour later the floating restaurant decided to float down to there.
Our old offices were swimming, and the new office was dry, just. We all felt very self-congratulatory about all that. It was a bit of drama as we moved. And as pictured, lots of water. We sent everybody home but interestingly managed to keep everything working, even though the power to the building went off because we have all our stuff in datacenters. So we actually managed to still do all of our continuous assignments. And, as you saw, we were getting rid of a lot of addresses out the door and continued all that through the entire week, which we felt very pleased about.
Where are we going next? We're going next to sunny Korea. Busan, the honeymoon capital of South Korea. I've never been there myself, but I've been told it's really cool. So if you want to come along, too, end of August, would love to see you there.
And then we go to Delhi in India again. We were last there in 2007. And after that I don't know. But in 2013 we're off to sunny Singapore.
And that's all. Thank you very much.
Alain Durand: Alain Durand, Juniper Networks. In all the statistics that you're making on v6 traffic, how much 6to4 traffic do you see compared to native?
Geoff Huston: Currently, there are about -- let me get this right. .2 percent of clients out there in the big unwashed Internet will use v6 in dual stack.
And those folk who will use v6 in dual stack generally are unicast and they're not 6to4 and they're not Teredo. But if I'm only a v6 URL, no v4, interestingly, 4 percent of the great Internet will be able to see me. And of that 4 percent, almost all use 6to4. So around 4 percent of the Internet will use 6to4 if cornered.
But still no Teredo, because Teredo in Microsoft doesn't get invoked via the DNS. But if you hand someone a literal where all you have is just the v6 address, no DNS, 30 percent of the Internet will get it.
So about 30 percent of the Internet actually manages to do Teredo. However, another 10 percent of the Internet will try to use Teredo, and I can see their naked SYNs coming at me like crazy, no ACKs. So those SYNs are evil.
There was a lot of Teredo out there, but Microsoft was wise to turn it right down because the failure rate is unacceptably shocking.
Lee Howard: Lee Howard, Time Warner Cable. Geoff, I want to thank you for the APNIC stats, the ones Alain was just referring to, but also the projections that you personally maintained have been remarkably useful for years. Thank you very much.
I noticed in one of your very early slides, the panic slide -- hey, look, people -- people did in fact panic and APNIC proved that they had a shovel large enough to shovel those addresses out the door.
I'm curious, though, I guess I don't understand, do people's network deployment rates actually increase that much or is justification for addresses different in APNIC than it is in ARIN?
I expect there will be an ARIN resource report much like that one where we see that the number of requests has increased significantly but the number of allocations hasn't increased all that much because the justifications haven't increased all that much. People aren't building networks faster; they're just requesting faster.
Geoff Huston: So there are a number of things going on here, and you can see it in this task. Firstly, we did not shut our window down to three months like ARIN. So we're still operating on 12 months.
Secondly, we have in the Asia-Pacific region a number of countries who have evidently legislated against using private addresses for deployments of these things, mobile phones.
So we get applications, without naming names, from folks saying, well, we used to run this infrastructure on private address with NATs, and now the government is saying locally we cannot. We need this truckful of addresses because truckfuls of these things are getting sold. And this sort of happened through 2010 slowly, but the end of the year it just all of a sudden snowballed. That's the second factor.
And the third factor is China. It just is a factor. The increasing power of the Chinese currency, the increasing affluence and the phenomenal population and the huge amount of sales of computing devices consistently meant that China's rollout is of a scale that is just eye-popping. They do entire provinces in a week. I think with address run-out, they accelerated the infrastructure deployment and just simply are spending money.
So the end result was we're sitting there going it's a justified case. So we found this pressure. And, yes, it is panic. Infrastructure investment was accelerated.
Will you see the same? I think panic's very human. And I think money panics. And ultimately what you're seeing here is money panicking. And my suspicion is that ARIN, which is currently looking at exhaustion with a 70 percent probability in July of 2012 -- in other words, just over a year's time -- it will come in closer, because as you get visibly near the end, I suspect that this area, like every other area in the world, will sort of go: Hey, last chance, panic.
John Curran: Thank you.
John Curran: Next up is the Number Resource Status Report from Leslie.
Leslie Nobile: Good afternoon, everyone. This is -- we call it the joint stats for short. It is the statistics of all five of the RIRs in a side-by-side format. It's updated every quarter. So the data is pretty fresh. It's as of 31 March 2011.
The first slide we start with shows the total IPv4 address space, and probably the most glaring thing is the big red letters in the middle that says IANA reserved is down to zero. There's no longer any space, we all know that, in IPv4 left for IANA to issue to the RIRs.
Above that in the pie it says 35 /8s are not available. Those are in use by the technical community and they're not available to IANA to issue to the RIRs.
Moving left into the big gray box, the central registry, that is a space that was issued prior to the establishment of the RIRs, and it's basically where all the legacy space resides. 91 /8s were issued those earlier days.
Much of those 91 /8s are actually issued in the U.S. -- someone mentioned that earlier -- when the Internet was -- in the early days when it was mostly being deployed here in the U.S.
And then 130 /8s have been issued to the RIRs by the IANA. We broke it down a bit further in the pie below. You can see APNIC has gotten 45 /8s from the IANA. RIPE NCC has gotten 35. LACNIC has gotten nine. AFRINIC has five, and ARIN has received 36 in total.
I think it was mentioned also that we each got a single /8 at the end of -- on February 3rd when -- at IANA run-out per global policy.
This shows the v4 space that we've issued to our customers in total. And we've gone back as far as '99, because that's pretty much all we can fit. I'm not sure how we're going to go any farther than 2011 actually. It's getting pretty crowded on that graph.
But really the most interesting thing there is for the first quarter of 2011 you can see that APNIC in yellow has issued 5.18 /8s to their customers in the first three months of the year. That's fairly significant.
So that's it. This shows the cumulative total from 1999 through March 2011. RIPE NCC has issued a little over 30 /8s; ARIN, a little over 27; LACNIC, 5.5; AFRINIC, 1.89; and APNIC has issued 43.16 /8s in that 10- or 11-year period, 12 maybe.
These are ASN assignments from the RIRs to customers. And really the takeaway is RIPE has been issuing more ASNs than any of the other registries. And they're still on track this year. They're issuing quite a few.
This is the total ASNs. It includes 2-byte and 4-byte. I have another slide that just breaks out the 4-byte after this.
Cumulative totals for the ASN. This is actually the first time on this slide that we've presented this; that RIPE NCC has issued more ASNs than ARIN has, because ARIN was traditionally the big issuer of ASNs. So RIPE has issued almost 22,000 at this point.
4-byte ASNs. So we broke it out just to see what's going on in the 4-byte area. And consistent with previous slides, RIPE is issuing more 4-byte ASNs in addition to 2-byte ASNs.
When you look at the rest of the RIRs, we're issuing minuscule amounts of 4-byte ASNs, and ARIN in particular; we are -- I have an actual slide later in the Policy Experience Report to talk about 4-byte ASNs. We are getting more return than we are actually issuing. But RIPE doesn't seem to be having the same problem. Although they have told me that they do get their 4-bytes exchanged fairly frequently, just not as frequently as we do here.
You can see the totals that we've all issued. RIPE has issued over a thousand and AFRINIC has issued over 300, ARIN for the APNIC, 174; and AFRINIC 24.
One of the differences is that the way that we're issuing 4-byte ASNs at this point it's operating from a single pool, and RIPE -- both RIPE and LACNIC are issuing their 4-bytes first, whereas the other RIRs, and I believe AFRINIC is doing the same, we've put it all in one pool and we're issuing our 2-bytes first, the smallest numbers first. So we're still issuing 2-bytes while some of the RIRs are issuing 4-bytes by default.
So looking at IPv6 space. We looked at the total space on the left. It says /0. Most of that is still being held by the IAB. There's a /3 that has been reserved for global unicast space. There's 512 /12s in that total space. Five of them have been issued, one to the each of the RIRs per global policy. One is kind of a mixed bit; it's got some junk issued out of it, so we just sort of categorize that as a miscellaneous /12. And IANA still has 506 /12s in reserves.
Basic allocation from us to our ISP customers. Let's see. So RIPE is issuing more v6 in their region than any of the other regions. This is interesting because ARIN actually in the first quarter has issued more than APNIC, and APNIC has a policy in which anybody who has v4 from -- a v4 allocation from them, they issue a v6 to them I think automatically. Geoff can clarify that. But they've really increased their v6 allocations. But still ARIN has issued more this quarter.
This slide on the left shows the total number of allocations that each of the RIRs have made. RIPE, again, issued more, 3,026; ARIN, 1343; APNIC, 1218; LACNIC, 513; and AFRINIC, 137. So that's the total allocations on the left.
On the right we're actually showing the total number of /32s that have been issued, and that's a significant increase because most of us are issuing larger than /32. /32 is the minimum allocation, but all of the RIRs are issuing some allocations that are much larger than that.
This shows IPv6 assignments from us, the RIRs, to our end-user customers. And we seem to be issuing more v6 assignments than any of the other regions at this point, in the ARIN region, where I was showing Mark.
We have links to the RIR stats. This publication is kept on the NRO site. And the raw data is kept on each of the RIRs' FTP sites. And the historical RIR allocations are kept on the IANA website.
That's all I have. Are there questions?
Owen DeLong: Could you go back to the slide where you showed the five /12s that were allocated?
So ARIN's got 260, but I received space out of 262. And Hurricane's got space out of 2001. That doesn't seem to be accounted for. Neither of those /12s seem to be accounted for in that slide.
Leslie Nobile: It's probably in the miscellaneous. As I said, there's a miscellaneous category. Before the global policy we were all issuing from /23s to our customers and some of those bits are stuck in that /12.
Owen DeLong: So that 23 doesn't aggregate to a single /12.
Leslie Nobile: That is correct.
Owen DeLong: So that one /12 is a /12 worth of space, but it's spread all over the --
Leslie Nobile: It has a couple of different ranges, yes.
John Curran: We were never planning on announcing it, so that's okay.
Owen DeLong: It's widely announced.
John Curran: We, ARIN, were never planning on announcing it.
Leslie Nobile: That's it. Thanks for your attention.
John Curran: Okay. So we're actually very close to being on time. It's 3:00 and it's time for our break. So we're going to take a refreshment break. We're going to come back at 3:30. You all have a half hour, and we'll pick up the afternoon reports including the Policy Experience Report, and then open microphone.
I'll see everyone back here at 3:30.
John Curran: Welcome back. I'm looking to see if I have a Ron da Silva or Louis Lee. That's great. In the afternoon we did not get to the NRO NC Report. So I think Louis is ready. Take it away.
Louis Lee: This is the report from the NRO Number Council, which will come up in just a moment.
Thank you. This hat's from Australia. Here we go.
Now, as you see, Ron was supposed to give this presentation, but he's unable to be here with us for this afternoon, so here I am. Now the NRO Number Council Report.
The council is made up of 15 members, three from each region, two are elected at large and one is appointed by the RIR Board. We also have the RIR and ICANN observers in our meetings.
Let's see, here we go. We have one here. And what do we do? We advise the ICANN Board. We select two ICANN Board members to the Board itself and also we select one NomCom member. We have our meetings telephonically and one annual physical meeting.
The 15 members are listed here. In ARIN we have Ron da Silva, myself, and Jason Schiller.
Now, we've had five teleconferences since our last ARIN meeting, and we have had a session at ICANN 39 on the Number Resource Policy Development Activities.
And at these workshops with ICANN, we give them an overview of what's going on in the number policy world. Not just the global policies, but also highlights of the regional policies.
The idea is that we would like them to understand what's going on in their own regions as well as what's going on globally.
We also held a session most recently at ICANN 40. As you can see, that was our agenda there.
And in regards to global policy, the most recent global policy ratified is the Internet Assigned Numbers Authority Policy for Allocation of ASN Blocks to the RIRs, ratified in September 2010.
There's an active global Policy Proposal, Global Policy for IPv4 Allocations By IANA Post Exhaustion. This one is still considered active and we're tracking at this point, being that it is active in at least one region.
But it was -- this is the one that was adopted in ARIN last time but abandoned in APNIC recently and also withdrawn from RIPE, under active discussion in AFRINIC and LACNIC, but we see this as unlikely to advance to global policy.
There's a newer global Policy Proposal, Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA. It's reaching last call at APNIC, and it's under discussion at ARIN, LACNIC, and RIPE. As was told to you earlier, this global Policy Proposal has not reached a point where we could discuss it in this meeting.
As also you can see the last two have a designation of GPP-IPv4-2010 and 2011.
We started numbering these global policies, because there are different numbering schemes across regions. And this is one way to yet add another one, but also be able to refer to the same global policy around the regions with one designation that can be a reference.
And the secretariat, ARIN, this year, thankfully created a Web page for the world to see and for also us to track these global policy proposals and be updated on the fly. The Web page, as you can see, is -- the link is posted.
Now, if you are running a Mac and you might be running into trouble reaching the site from the meeting network, it's because your Mac is defaulting to IPv6 first, which is the desired feature. But unfortunately you would need to lower your MTU size to be able to reach that site from here.
And lastly we have Wilfried Woeber on the ICANN NomCom 2011. This NomCom is a group that consists of members of the other ICANN community who would put up members to serve on the ICANN Board and other bodies within ICANN.
We've also got members in various review teams. Most recently we completed the review of the accountability and transparency activities within ICANN, and I served on that Board.
And with Hartmut Glaser serving on the SSR of the DNS, and Wilfried also serving on the Whois policy side.
One thing of note is there's an agreement, not so strongly, maybe an idea, that their work on the DNS Whois might have some relevant ideas that could go to the number side Whois, and we also offered some thoughts, some operational advice to their review team on our experience of what we found to work and not work.
We have our work plan. We have our regularly scheduled meetings. And also we're working on updating the ICANN Board appointment procedure.
At all the ICANN meetings we are providing these reports and we are tracking the global policy proposals. If you're interested in our other activities, please visit our website. Are there any questions?
Great. Thank you.
John Curran: Okay. Next up is going to be -- what are we going to do next? STLS until we have Raúl. Is Raúl back? Let's do the Specified Transfer Listing Service. I'll do the presentation.
John Curran: We've had a lot of folks ask about the STLS, Specified Transfer Listing Service.
Something that the communities have encouraged us to create because thought it would be desirable for a number of folks trying to make transfers happen.
So it's provided to facilitate Section 8.3 transfers to specified recipients. It's not required. Section 8.3 of NRPM is a policy. If you apply in accordance with policy, we'll recognize the transfer. You don't need to use STLS at all, not required. Okay?
But there are cases where you might find it useful for finding someone. Basically, if you already know you're going to do a transfer, you know where it's coming from and where it's going to, you don't need STLS. STLS is what you need to get the raw data necessary to do matchmaking. We don't do matchmaking. That's not ARIN's job.
Parties who have resources and parties who need resources can find each other. We're just making sure the data is available for those people who are seeking to have a match made.
Resource transfers that result from STLS, when there is a match, when someone takes that data and finds someone else, they then apply, per policy. STLS is not a transfer; it's just a way of people finding each other.
Again, IPV resources can be transferred under 8.3 as long as there's demonstrated need for the recipient and that they're received under a registration services agreement with ARIN.
ARIN does not match up the transferred interested parties but provides a service for them to find each other.
Three types of STLS participants. Those with documented need for space. If you come to ARIN and you qualify for address space and we don't have any, then you've got qualified need. We know which size block you need to meet your 12 months of growth, and that will be documented. You can actually find that online. Very convenient. Those people who need address space.
Those who have IPv4 address space, listing space, if you've got the resources, they have to be under an LRSA or a officer attestation. I'll talk about this in a little while.
We told everyone we want to make sure people listing resources are the valid address holder. And that's very important. And the way we usually do that is by bringing everyone in to an LRSA. We'll have to revisit that a little bit and create some flexibility.
You can also get access to the listing service if you just want to help people find each other. You want to be a facilitator, then you apply, not a problem, you can get access to the data.
The only thing you can use the data in the listing service for is to contact someone about trying to do a transfer. That's it. Okay? You can't use it to do any other contact. It's only for that purpose.
Everyone listed agrees to be contacted for that purpose. Okay. So what can it be used for? Offering space to those who have need.
Finding address space from people who have it. Matching up those directly. Verifying respondents. If you -- let's say you would turn around and say whatever rights you have with address space you're going to transfer, and you put an ad to that effect on eBay, be careful, I'll find it.
As long as it's phrased right, it's perfectly fine. So the fact of the matter is when someone responds and says I'm interested, they better have need. They're the only valid respondents.
You can check them by going into the STLS verifying that they're listed with need.
That's not saying you can't do a transfer if someone's not in STLS. Again, you can do it. Not a problem. But if they're listed here, you already know that they have need, they're qualified for a certain size block. It's a faster way to get the job done.
There will likely be thousands of organizations looking for address space. ARIN's job is to keep the directory up to date. It's one way to help people find each other.
Little details: We still have address space. Don't give up yet. We have address space near term, January of next year, long term, June of next year, I believe Geoff said.
All depends on how you do the math. So we're probably good for a little while, but we're only giving it out in those little three-month blocks.
So three-month blocks means you get address space. It's assigned to you. You get it routed. Get it used. And then you're busy filling out the application for your next three-month block. That's your policy. That's what you created, so that's how it works.
So the fact of the matter is that one reason you might want to be looking for 12-month -- looking for STLS or specified transfer is to get 12 months' worth of address space, because that's what you can transfer under our policy.
ARIN's still accepting returned address space. People are like, wait a second, this looks monetizable, why would someone return it?
Well, a lot of people got very large address blocks in the beginning of time. They may have gotten them just because they sent an email saying, hey, I need address space.
And, in fact, because of the three sizes we had, A, B, C, a lot of people got sizes that didn't quite fit. Even if they used their address block, they may have a lot left over.
And they know they got it for an email message, which is relatively inexpensive. And for the sake of the Internet community we have people returning address space, even now.
So if you want to return address space, not a problem. I will ask you a couple of times; you know this can be monetized. Are you sure you want to return it?
But if you do, we're happy to take it back and we'll put it to the free pool as quickly as possible. Maybe June 15th will become June 16th because of addresses returned. We don't know.
But we do encourage this even to this day. To date, 125 organizations have applied. We're in the process of going through them now. People listing address space. People who want to obtain a transfer of address space, and a facilitator. So you can apply online. If you go to ARIN's Web page, there are three buttons on the Web page: Got v4 space, need v4 space, want to match up v4 space. It's fairly simple. That's all I have.
Now, I wanted to revisit something. It came up in a mailing list discussion. Bill Woodcock -- is Bill Woodcock here. He pointed out, if someone's going to transfer their address space, when they're done they don't really need an agreement with ARIN.
The idea of having a legacy RSA agreement may not be necessary if the whole goal is for you to transfer your space to someone else, why would you go through all the work?
This has been considered by staff, and actually has had some Board consideration, and we're going to be very quickly revising things so that you can actually enter into a transfer without having the resources under LRSA or RSA. You can have it, just say I'm it, you certify that you're the holder.
Now, we're going to vet you, meaning we're going to verify that you're actually the successor organization or the organization that's supposed to hold those resources.
And this creates a bit of uncertainty. Time uncertainty and transfer uncertainty, because, quite frankly, we only have your word that you're the address holder. And the entry in the database, which may or may not adequately reflect things.
If you want certainty, bring your resources under an LRSA, if it's a legacy resource. If it's already under LRSA, you don't have to worry about it. But by doing that vetting process up front, someone who is transferring resources knows it will go smoothly because we've already done the vetting, you're already under agreement, there's not a problem.
If you don't do it up front, then it creates uncertainty. It's possible that we'll decide you're not the appropriate holder if you can't produce record keeping.
Now, all of you will have no problem producing the right records. You would not believe this, but there are parties out there that want to get address space to use things for like mail servers for spamming. I know this is news for some people. But they show up to us and they claim to be the rightful owner.
So we do have to vet the applications. We have to make sure when we transfer address space that the party that's transferring it is actually the ones that got the original assignment at the beginning of time.
And that will be updated. We'll update that in the forms for transfer, and we'll update it on the STLS page. So make sure that people can do transfers. Again, you won't have to bring it under resource agreement LRSA if it's a legacy block up front, but you would probably want to do so if you wanted some certainty.
Questions? Microphones are open. Bill Darte.
John Curran: Sure. So what happens is obviously if you're coming up to ARIN, and you're going to have us do a lot of work to verify that you know John Doe of ABC Corp. is the John Doe of ABC Corp. that's registered, particularly when John Doe is actually Jonathan Doe or it's not ABC Corp., it's ABC Corp. Networks, Inc. and it's registered in a different town.
These guys are very creative about how they show up claiming they're John Doe. Now, of course, again, that's not you folks. You folks are all who you are. When you claim you have the resources, we'll figure that out.
But the reality is a lot of people get very creative about how to hijack addresses. In order that we don't get lots of different statements that conflict each other, we ask for the officer to attest, say I'm attesting under penalty of fraud and perjury that I'm the rightful owner and here's who I am.
And that way the parties coming to us who don't have a legacy RSA but still want to make sure the resource registration's brought up to date, will make sure we know who we're dealing with legally, and we make sure we have recourse if they're actually just trying to perpetrate fraud on the system. Does that help answer?
Kevin Blumberg: Kevin Blumberg, The Wire. When a company gets added to the listing service and say they've got an extra /16 or /18. Under RSA is there an issue because they should be handing it back to ARIN, or are you amnestying these companies?
John Curran: The moment that you create a transfer policy that allows people to transfer unneeded resources, you've created effectively an amnesty. We can't simultaneously tell people you can apply for a transfer and go after them.
Now, if you have your resources under an agreement, that's fine. If you don't, yeah, you have no amnesty, obviously.
Kevin Blumberg: Thank you.
John Curran: Any other questions?
Scott Leibrand: Scott Leibrand, ARIN AC. I may have missed it. Do we have statistics on completed transfers, number of them, anything like that.
John Curran: Still -- I think we might have some statistics that we can report in about 90 days.
But right now you're trying to produce a graph with very, very few data points. I'm not sure I can get you a line or a surface, let alone a graph. So gotta wait a little while.
Stacy Hughes: So can Needers work on the list or are you --
John Curran: So you have to agree to follow the policies and you have to incur it in the STLS policy which says you have to have a purpose there. You cannot share the information with anyone else. So no one's lurking on the list, republishing, or it will get bounced off the list. But as long as you agree you can stay on the list.
For example, an organization might have a /16. They realize, wow, I actually don't need a /17, I mean, a /19 out of the middle of that. They list it. They transfer it.
Later on they realize, hey, I have another 19 I might be able to make free. Okay. No reason that they shouldn't be able.
Likewise, an organization that needs resources that's on the listing service, when their need is qualified, they can't be on the list with no qualified need. But as long as they are still outstanding with qualified need, they can stay on the list.
Okay. Any questions? No? All right. We'll catch right back up. I'm going to move on at this point to the Policy Experience Report with Leslie.
Leslie Nobile: Okay. This is kind of out of order. I'm supposed to be starting with Policy Implementation Report. Sorry. It's two separate reports. Okay. That's better.
All right. So the purpose of the Policy Implementation Report is basically to update you all, the community, on recently implemented policies. And that being policies implemented since the last ARIN meeting.
We also provide relevant operational details, if there are any to report.
So the recently implemented policies since the last ARIN meeting are: 2009-6, the IANA policy for allocation of ASNs to RIRs. Oh, to RIRs RIRs. Interesting. That's good.
So until December 31st, 2010 RIRs can get a 16-bit and one 32-bit block of ASNs from the IANA. And after this date IANA and the RIRs make no distinction between the two and basically operate from an undifferentiated pool. So we recently implemented that.
Rework of IPv6 assignment criteria, 2010-8. It says that need is determined by the total site count. Sites get /48 or larger per site.
And it provides a formula for the initial assignment that allows for aggregation and growth. That was something that was lacking from the previous policy, and ARIN is assigned on nibble boundaries.
And subsequent allocations are based on 75 percent site count, not individual site utilization.
We also implemented the waiting list for unmet IPv4 resources, and that basically provides rules for an expected queue of v4 requests when the v4 address space becomes limited.
And the requests would be filled with ARIN's available space or the requester has an option to be placed on the waiting list. If they ask for a /16 but we only have a 15, I'm sorry, a 15 -- we only have a 19, they have an option of going for a smaller block or of being placed on a waiting list.
The allocations and assignments are limited to one every three months. And the IPv6 subsequent allocation policy allows additional IPv6 allocation for transitional technologies. V4 to v6. And we actually have approved two of these to date.
So those are recent. We just approved them within the last month or so. So I went back to some older policies, not too much older, couple of months before the last ARIN meeting, and I have some operational feedback on a couple of things.
NRPM 22.214.171.124, multihomed connection for end users. That was recently implemented, I think in September. And it reduces the multihomed end-user IPv4 for minimum assignment size from a 22 to a /24.
And end users receiving less than a 22 from ARIN have to renumber if they come back for additional address space. And since we implemented this in September 2010, we've approved 163 separate organizations under this policy.
We've issued 103 /24s under the policy and 48 /23s. So it's been a heavily used policy.
Dedicated IPv4 block to facilitate IPv6 deployment, NRP 4.10, implemented in April of 2009, and it went into effect in February of 2011, at run-out. This was the policy that went into effect at IANA run-out.
So staff was to reserve a contiguous /10 v4 block to facilitate IPv6 deployment. We haven't made any announcement, but we've set aside the block 126.96.36.199/10 for this purpose. Just wanted to let people know.
The annual Whois POC validation. So this was -- all registered points of contact in ARIN's database have to be validated annually.
If they don't respond within 60 days, they get marked as invalid in the ARIN database. And as a result of community feedback, at the last ARIN meeting we asked the question and then we put it out on the ARIN Consultation and Suggestion Process and asked whether ARIN should be processing requests from invalid POCs, and the response was, no, you shouldn't be.
So we have put into effect this system where we are no longer processing any requests of any type from invalid points of contact, whether that be via template submission or by ARIN-online, we're automatically stopping anybody with an invalid point of contact.
And that was it for the implementation report.
Are there questions?
Scott Leibrand: Scott Leibrand, ARIN AC. You said anyone with an invalid POC. You actually mean someone with no valid POCs, correct? Or not correct? If you have a bunch of valid POCs and a single invalid POC, what happens.
Leslie Nobile: We're not processing the request.
Scott Leibrand: So you respond back to them and say this POC should be deleted first and then we'll process your request, that kind of thing.
Leslie Nobile: No, we respond back and say there's an invalid POC related to your organization and until they validate we won't process the request, and here's your options, you can do this or you can do this. We kind of lead them through it.
Andrew Dul: Andrew Dul, Cascadeo. Are you going to talk about statistics or anything related to POC verification? Do you have any of that information?
Leslie Nobile: I don't. I did it last time. We've already run through the cycle, the first annual cycle of both directly registered points of contact and indirectly registered points of contact.
And with the directly registered POCs, sorry, I'm not exactly sure, but we were somewhere around 25 percent response rate.
With the indirects, those that are reassignments, we had a very low response rate, probably less than 5 percent. And we continue to this day to get complaints from indirect POCs. They don't want to cooperate and they yell at us, actually. And they just won't cooperate.
So I don't have anything specific, but could probably find something, I could probably provide that later.
Andrew Dul: If I remember the last meeting correctly, there was discussion about should we continue doing invalid -- sorry, indirect POC validation. Was there an outcome of that? I'm just trying to refresh my memory, or if there's another time for this I can just talk to you directly, too.
John Curran: Let's try to get some stats out on POC validation between now and tomorrow. And that will allow discussion of tomorrow's open mic.
Leslie Nobile: You are correct, Andrew. We did ask the question, and the community response was you should continue to try to validate every registered point of contact in the database, and that's what we've been doing.
Andrew Dul: Great. Statistics would be great.
Leslie Nobile: I'll try to work something out. I hope somebody on my staff is listening. We'll get that.
David Farmer: I have a question here. Any sense on the number of POCs that have been validated since you turned off service for invalid POCs, and if that's something you could check for tomorrow as well.
John Curran: Can I ask a question? There's an implication in that, since doing that, that changes the number and that the POCs that validate are cause and effect, and they're not.
David Farmer: I would agree that they're not necessarily cause and effect. But it forced me to fix a POC. So I assume it forced a lot of other people to fix a POC.
John Curran: Okay. We'll see what we have for statistics that we can get.
Policy Experience Report, a little different than the Implementation Report. This is the opportunity in the policy development process where the staff gets to review existing policies since they've been in place for quite some time.
And we're basically trying to ensure that they are working the way they are supposed to be working. And sometimes we're looking for ambiguous text or inconsistencies in the policies, gaps in the policies, things that may be missing.
In fact, some of the policies that I'm going to discuss actually are gaps. Seems to be there's some missing text, and the effectiveness of a policy, how well it is working and it's doing what it's supposed to be doing.
We identify areas where new or modified policy may be needed. This is based on, of course, our operational experience and customer feedback. If more than three or four customers, or even two, have a problem with a policy, then we want to look at it again and make sure that it's correct, it's proper, it's doing what it's supposed to do.
And then we'll provide feedback to the community and make recommendations when appropriate.
So we reviewed -- there's actually one, two, three, four, five policies. This might take a while. So the first two, NRPM 2.6 and 2.4, are the definition of end-user and ISP, which is actually LIR. That's what is defined in ARIN Number Resource Policy Manual.
We looked at -- there's another one we're looking at, NRPM 2.2. And the question is, the question we've been asking ourselves, with v4 depletion coming up and things getting a little murky, can an RIR issue space to an organization outside its region? Well, the only place it's even mentioned in the NRPM is under the definition of RIR. There's a brief mention of that.
Transfers to specified recipients, NRPM 8.3. We think there's a little bit of a loophole. I'll talk to you about that. And 4-byte ASNs, NRPM 10.3. As I mentioned, customers in the ARIN region are still having big issues using 4-byte ASNs. Thought I'd bring it up again.
So bear with me. I'm going to read some definitions. Local Internet Registry. That's defined in the ARIN region, in our policy manual, but we don't even use the term "LIR" in our policies. We use the term "ISP."
But an IR, Internet Registry, that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet service providers.
End-user, NRPM 2.4. An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks.
Okay. So these are some issues. And, as I said, with v4 depletion, things -- we're starting to hone in on certain issues. There's no definition, no current definition of an ISP in the NRPM, but there's lots of references to ISPs in the policies themselves. And there's very distinct policies for ISPs, and very distinct policies for end-users; however, ISP isn't even defined. The definition of both LIR, if we're using LIR as the definition for ISP, is pretty nebulous as is the end-user definition.
There's some newer technologies that we're finding -- these definitions were done quite some time ago with some pretty basic technologies and services.
Well, things change really rapidly on the Internet and there's lots of new services going, coming forth. And trying to fit people into an ISP end-user category has become more challenging for us.
Some newer technologies that don't fit the categories. Cloud computing was one that came up. Content delivery networks come up often. Software as a service providers, et cetera, et cetera. A few different things that were kind of a little more challenging to define.
And, of course, it makes it challenging for us to apply the policy properly. And with the recent policy change to the three-month supply of IPv4 for ISPs but not or end users, and end users still got the 12-month supply, it may be advantageous to be in the end-user category.
So we have some questions: What is an end-user and what is an ISP? I'm not sure I've ever heard a really good definition of either. And NRPM certainly doesn't have one.
Should staff be determining whether an organization is an ISP or an end-user, or should the organization decide?
And in the early days, when I first came to ARIN 11 years ago, the staff was pretty much letting an organization decide which category they fell into.
And unless it couldn't meet a policy, unless they were applying as an end user, the policies are a little bit easier to qualify under, but they were really an ISP, and if they were not able to meet ISP qualifications, we would actually say, no, you can't qualify; you have to be able to qualify under either policy in order to choose your own category, if that makes sense.
But, anyway, we allowed that early on. In more recent years we've actually tiered people into when they come and apply as an ISP or end user and it's the wrong category, the wrong fit, we see it as the wrong fit, we say, no, you have to re-apply under this category.
Should an ISP be able to switch to become an end-user and vice versa? That's a different set of policy criteria.
We've had some organizations come in and apply as an ISP and be using ISP, being an ISP for years and all of a sudden have decided, well, I need to be an end-user, I'm not really an ISP or vice versa.
And so the staff practice has been, unless there's a real technological reason, you have a really strong reason or you actually are providing a new service that puts you into the other category, we try to steer people into staying and remaining in the same category. But should we be doing that? Should they be doing that?
So we're just going to keep moving on. You can ask questions later.
So NRPM 2.2, definition of a regional Internet Registry: Primary role of RIRs is to manage and distribute public Internet address space within their respective regions. Doesn't give us a lot to go on.
And with v4 depletion it's become really critical. So there's nothing specific in any policy that says you have to be located in the ARIN region or plan to use the resources in the ARIN region in order to request resources from us. There's not anything written anywhere.
So we have questions again. So with v4 depletion imminent in some regions, what will prevent RIR shopping? What do we have to stand on to prevent that? Should there be criteria written into the policy that states who is eligible to request resources from ARIN? For example, should there be something that says you have to have a legal presence in the region? Currently that's something that we do.
We actually have a couple of criteria when people come to us, but it's not documented anywhere. We say you have to have some type of a legal presence to do business in the region, have to do something, state incorporation, documentation, something. You don't have to be incorporated. But we're looking for something that says you are authorized to do business in this region.
Should there be clearly defined criteria requiring that the resources are going to be used within the ARIN region? Should there be something that says you have to use them here? Currently we say you have to be originating the route in the region.
So that's one of our two criteria. NRPM 8.3, transfers to specified recipients. This is where we think there may be a loophole.
IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient.
Such transferred number resources may only be received under RSA by organizations that are within the ARIN region and can demonstrate the need for such resources as a single aggregate in the exact amount which they can justify under current ARIN policies.
So we see some issues here. The current policies based on justified need, but there's nothing in 8.3 that would disallow an organization from coming into ARIN, qualifying for the resources, and then next week immediately flipping them and putting them -- you know, trying to make a profit for them by putting them up for transfer via NRPM 8.3.
Is it fair to allow someone to obtain a limited resource based on justified need and then never actually use it for its original intent and purpose?
And it seems to be a direct violation of the RSA, but it's not written in policy anywhere. We have some suggestions. So just throwing out a few ideas.
So we think the policy should be made consistent with the RSA's requirement that resources be used in the manner for which they were approved. And we throw out some options here.
Maybe 8.3 could be updated to add a requirement that resources must be registered for a minimum amount of time, perhaps a year, to be eligible to use 8.3 or update 8.3 to say that resources are not eligible for a subsequent transfer. Or apply A or B to some percentage of the received resources, or anything else. But just something that says if you come in and qualify for resources based on your justified need, you shouldn't be able to immediately, within a week, a month, three days, turn around and try to make a profit off of them, especially in this day and age where the resources are so limited.
Okay. So the IANA policy allocation of ASN blocks to RIRs. The significant part of that, the policy text is after December 31st, IANA and the RIRs will make no distinction between 2-byte and 4-byte ASNs and will operate from an undifferentiated 32-bit pool.
The issue -- most customers are specifically asking for 2-byte still, or they're exchanging their 4-byte ASNs once we issue them, or they're changing their minds midswing when they check with their upstream provider. We've had almost probably over 400 people change their request from 4-byte 2-byte.
To date, there's only 38 4-byte ASNs that are actively registered in ARIN's database. We issue them and then people come back and exchange all the time. 53 4-byte ASNs have been exchanged for 2-bytes, and the typical reason is they said their router wouldn't support 4-byte ASNs.
Current practice, we operate from one pool and we're issuing the lowest numbers first. We're issuing the 2-bytes up to the 4-bytes. The 4-bytes will be issued at the very end. I'm not sure when we'll start issuing 4-byte but default is 2-byte because it's the lower number.
We do allow a customer to still have an option. If they want a 4-byte, they can absolutely have one. We do ensure that the customer really wants the 4-byte before we issue it, because we've learned that so often they want to exchange it. And as I said we will exchange it anytime they ask.
Questions: The first one is sort of an obvious one: Network managers and router vendors have to ensure that their networks and products are compatible with 4-byte ASNs, but the question, I guess, is there something ARIN can do to help with the transition to 4-byte ASNs?
And that is all I have.
Are there questions?
John Curran: So the community and the AC, certainly a member of the community that sees this is welcome to, if they have a particular vision of how these should be resolved, is free to submit a policy proposal.
And also know that the members of the AC are very interested in these, that they may pick this up and discuss at their meetings. Because the process is open to anyone, anyone can submit a proposal to adjust these. But I imagine the AC will also spend some time looking at them.
Alain Durand: Alain Durand, Juniper Networks. I have a question, on your last slide before the 4-byte DNS number.
Yes. To make policy consistent with the requirement that resources be used in the manner for which they were approved.
It's a question that has been asked to me by all the people I talk to. And I would like to get your opinion on what will you do in that case.
Let's say that organization A got some space from ARIN and justified according to certain number of criteria and is perfectly fine. Later, could be a week, could be a month, could be a year, could be 10 years, they decide to use the same address space internally for a different purpose. Is that okay?
John Curran: Collectively, is that okay, guys? It's up to you to decide whether that's okay.
Alain Durand: My question is to the staff, do you consider this as resources used in the manner for which they were approved or not, because that will somehow change my answer to the question that is asked here.
John Curran: At present there's no proposal regarding what language to use or what to do to the extent that resources aren't used. It's up to you folks to come up with a policy that you think is desirable and propose it.
If you think that's a good policy, then you should propose. We're noting that there's an ambiguity in that someone can request resources for one purpose and either not use them or completely use them for a different purpose.
If the community likes that, that's not an issue. If the community doesn't like that, that's an issue and you should write a proposal. Do you like that?
Alain Durand: I don't really have an opinion.
John Curran: Neither do we. People with the opinions, find the microphones.
Mike Joseph: Mike Joseph, Google. A few more slides back on the previous issue of out-of-region assignments and allocations in 2.2.
You mentioned on the last slide that there was -- you checked for -- you do check, although not enforced by policy, that the entity is legally operate, to legally be allowed to operate within the region.
And you check that, although not enforced by policy, that you currently require the route origination in the region. You said it's one of two criteria. What's the other one.
Leslie Nobile: Those are the two. Those are the main two. Yes, that's what we're using.
Scott Leibrand: Scott Leibrand, ARIN AC. Back on the 8.3 ones, I note that both A and B are things we had in the original Transfer Policy, I think it was 2008-2.
If anyone is interested in taking pieces of 2008-2 and bringing them back as stand-alone policies -- the reason I think 2008-2 was not passed was because it was too complicated. So if there are certain aspects of that that we think would be useful, I would be happy to work with anybody to bring those back.
Leslie Nobile: I guess I'm done.
John Curran: Any other questions?
We've gotten to almost every presentation of the day. I believe we have not received Raúl's second opportunity to present, which would be the NRO report.
Raúl Echeberría: I'm Raúl Echeberría, chair of the Number Resource Organization. I'm current champion of the foosball tournament at ARIN.
As well as Bob. You deserve an opportunity to speak here.
Speaking seriously, I will provide the NRO report.
Okay. What is the Number Resource Organization, NRO. Number Resource Organization is a vehicle for RIR cooperation and representation.
It was formed in 2004 for the purposes of protecting the unallocated number resource pool, promoting and protecting the bottom-up policy development process, and acting as a focal point for Internet community input into the RIR system.
It was established -- the ASO, Address Support Organization, was established within the ICANN framework by agreement, MOU, signed in October of 2004. And it was an opportunity at a meeting in Reston, I guess.
So I had a mistake. The NRO was created in 2003, one year before this agreement was signed with ICANN.
So the officers rotate every year. So in 2011 I'm serving as the chairman on the executive council. The secretary is John Curran from ARIN, and the treasurer is Paul Wilson from APNIC. Next year John will take the position of the chairman.
We have some NRO coordination groups. The Engineering Coordination Group, ECG, chaired by Arturo Servin from LACNIC, and the Communications Coordination Group, that's chaired by Ernesto Majo from LACNIC.
Those positions rotate, also together with the chair of the executive council position.
We have another coordination group. This is the registration services managers that is chaired by Leslie Nobile from ARIN.
One of the things we do is to contribute with ICANN through an agreement that we have had for a few years.
And this year we have renewed this agreement and we keep contributing with ICANN with 800 to $23,000. In this, we would, among the RIRs, based on an equation that they consider also the incomes from each RIR and also the number of IP addresses that we allocate. This is the current distribution. I will not give you too much time to realize how much are you paying.
Some of the activities we conducted since last year, last year in 2010, we held retreat in Belgium, in Brussels, together with an ICANN meeting.
We had opportunity to meet for the first time formally Elise Gerich, the current IANA director. She's around.
And we also, as a result of that retreat and those talks with ICANN, we became involved in the accountability and transparency review committees through the Address Support Organization.
In December, we participated in the ICANN meeting in Cartagena, Colombia. We introduced an innovation in that meeting because we started to report to the ICANN community in a different way.
We organized now in ICANN meetings we organized a session with the chair of the Address Council, Louis Lee is here, with participation from the executive council and some of the other council members.
And so we report to the ICANN committee about the policy development process in each region and NRO activities in a more open way than we were doing before Cartagena.
We repeated that experience in San Francisco in March of this year, and also during that meeting we supported the Address Council face-to-face meeting, but Louis will report about that later, I am sure.
One of the forums -- we participated in many forums. In other words, one of the forums that takes some of our time and efforts is the Internet Governance Forum, as we have participated very actively in that environment.
There is an advisory group that takes care of everything related to the agenda, format of the event and assist the chair of the Internet Governance Forum and the organization of the meeting.
And we have NRO participation in that group through Cathy Handley from ARIN and myself that have been participating in the advisory group for a long time.
Now there's a lot of discussions about the future of the Internet Governance Forums, which is run by the UN system, the Commission on Science and Technology for Development, CSTD, has created a working group for discussing the future of IGF.
There's five people from the Internet technical community participating in that group and two of them are strongly related with the local community. Those people are Sam Dickinson from APNIC and Oscar Robles, member of LACNIC.
Last meeting of the Internet Governance Forum was last year in Vilnius, Lithuania. And NRO have very active participation there. We met there with UN Assistant Secretary General Jomo. We had a booth written by RIR staff. That was a very successful experience
We leaded and participated in some workshops, we led some and participated in others, in any workshop in which something related with our business was discussed we were present through speakers and also with attendance.
And we have been contributing with the IGF Secretariat financially for the last five years. Every year we've contributed $30,000 U.S. dollars per year, around.
Now this contribution is in stand-by until we know what will be the future of the IGF, because one of the things, among other things, one of the things that's being discussed is how this secretariat will be run, so we don't know to whom to send money, neither how the money will be managed.
So under those levels of uncertainty all the contributors to this IGF are in the same situation from the NRO waiting for some news in this regard.
In that opportunity of the IGF meeting, we also released press release about IPv6. We took advantage of that meeting for updating the brochure on continuing cooperation, that was also distributed in our booth.
International cooperation. We are involved in ITU. We continued spending efforts to promote the self-governance model everywhere, including the ITU environment.
We've participated in the three last meetings of the ITU IPv6 working group. That working group was created in the -- I'm not sure about the name -- but the ITU-T, the standardization assembly in 2008 -- and 2008. Yes.
It took some time for them to put the working group in place, but now there have been three meetings and we have participated in three of them with an NRO delegation.
In the first meeting we participated with people from the five RIRs, but after that meeting we considered that there were enough matters to participate within an NRO delegation for this biggest step for us. Now we're sending a group of us to each meeting.
We also have very strong participation during the plenipotentiary meeting of ITU in Guadalajara next year. We were very influential with the people that was on the ground and with all the work we had done in previous meetings, in preparatory meetings before the plenipotentiary assembly.
And I think that the result of our work can be seen in the resolutions of the plenipotentiary assembly. Because I think we dealt very well, to use a very polite expression, with some strange proposals that were on the table for ITU dealing with IPv6 registration, allocation business, and I think the result of the assembly was much more friendly to our community.
Now we have sent letters to the chair of the ITU-T and ITU-D, invited them to hold talks consist with the outcomes of the Plenipot, with regard to the ITU interaction with other stakeholders, because the resolution on the IP addresses from the plenipotentiary assembly recommend ITU security to hold fluent relationships with all stakeholders.
So we're inviting them to talk about that, how they want to implement that, those recommendations.
OECD is also an environment in which we are very active. We're founding members of the Internet Technical Advisory Committee. We're participating in all the meetings in which we are invited to participate, and consistent with the materials that are developed.
We have very intense coordination among our engineering department, focused at this moment in resource identification, RPKI development, as we have accomplished it on the deadlines.
We are doing well in that matter. This is a good experience a new experience to accomplish all the deadlines. But we're doing well. I think that it would be -- this is very good example of coordination among the RIRs.
As we had an annual workshop in February, Miami, Florida, that was hosted by ARIN. It was concurrent with ICANN IANA distribution of the last five /8s. I guess that some of you followed that ceremony over the Internet.
We had more than 4,000 remote participants. This is really a record for this kind of meeting. After that, we held our retreat with representatives of ICANN, ISOC, Internet Architecture Board and IETF.
And it was also a very good experience and collaboration among Internet organizations. It was the first time that we have a meeting like this; it was very productive.
Some of the outcomes of the workshop that we held in Miami, we'll continue working toward a single resource certification licensure, as we reviewed the work plan of the communication group of the NRO. We worked on preparation of items to review with ISOC and ICANN executives and also Internet governance matters.
Some of the recent NRO -- I think this is the last slide -- the recent NRO statements and communications, in 2010 we issued a message regarding IPv4 and IPv6. We developed secure Internet through resource identification, RPKI messaging, also.
One of those communications was in regard -- when the Internet Architecture Board was discussing the architecture of the RPKI, we made public comments on that.
We also issued some public statements as preparation for the ITU IPv6 meetings.
Now, recently, in 2011, we sent a letter to ICANN about IANA contract saying to ICANN what we expect from the negotiations between ICANN and the U.S. government.
We sent also a letter to ICANN inviting them to hold talks about implementation of RPKI licensure. We are making progress on that. We held already one meeting between ICANN and the NRO at the technical level with participation of IAB and IETF, for starting to discuss how to implement that, what are the technical requirements for doing that.
We submitted comments to the U.S. Department of Commerce in NOI on IANA contract, summarizing we didn't support an expansion of IANA functions.
We support ICANN as IANA functions performer. We support to keep the IANA functions together. We introduced a new concept, the concept of cooperative agreement as a possible institution of the current contract between ICANN and the U.S. Government.
Finally, we have sent this letter to ITU about NRO ITU relationship that I have already mentioned. And we sent inputs to the last IPv6 ITU working group.
All those statements and correspondence with other organizations are available on the NRO website, and are usually announced in the email list of each RIR and also published it on the website. But I invite all of you to check the NRO website to see what the NRO have been saying.
And we have been very active this year, and responding timely to everything that is happening, that is a matter of concern of the RIR community. So I think it's good that you are aware of what we are saying through those statements and communications
I think this is the last one. Thank you very much.
John Curran: Any questions for Raúl?
Vint Cerf: Vint Cerf again.
Raúl, one of the things which I've noticed is a very persistent effort by the ITU to move in any dimension possible to absorb more and more Internet-related activity.
Certainly that was visible during the Plenipot meeting. More recently, an issue came up in one of the standards activities in ITU-T where an effort was made to deliberately divert away from a previous agreement to establish a common standard for MPLS operation and management by adopting through pretty seriously flawed tactics, a vote to go to something which is inconsistent.
I don't know whether you're sensing the same thing. Your remarks suggested you were actively observing the ITU.
The question I have is, first, do you agree with that? And, second, OECD seems like a place which has been a lot more friendly to the NRO and ARIN and ICANN and some of the other Internet-related policy organizations.
And so I'm pursuing a path now to be much more focused on OECD as a cooperative international party. Could you respond to those?
Raúl Echeberría: Yes, you're right. This is a matter of concern for the whole community, the recent development from ITU in the legislation field.
IETF has issued a declaration about this point. And also it has been supported by the Internet Society. The NRO has not done anything yet. We're observing that.
We don't know exactly -- in fact, I participated last week in the IETF meeting in Prague.
It is not clear what will be the next, the future development of this discussion. I think that we have to continue serving on what's happening and be ready to react if necessary.
Of course, all of us are aligned in support of the current mechanism on the Internet going into the development of standards.
What's your question about OECD, what was it?
Vint Cerf: Only to observe they seem a lot more compatible with the way we view things and that I'm personally pursuing that path, and I'm hoping that that's compatible with where you are going with NRO.
Raúl Echeberría: I think there are other friendly environments in which we participate. OECD is one of them, because the participation of every party there is very constructive. We have the opportunity to influence in discussions, be present at meetings, it's a good thing to do.
I think that there are other environments, particularly I had the experience of participating in Inter-American Communication Commission, as I think we do that, LACNIC participated in that forum. We coordinate very much as we have been very successful in promoting positions.
In fact, one of the positive remarks of the plenipotentiary process of ITU was that the inter-American region, including all the countries from the inter-American regions came to Guadalajara with a common position, which was a position of separate to the RIR system. And this was -- it was the result of the work that we did in CIDL.
So within there is many -- unfortunately, there a lot of other and organizations which we have to participate. Of course, OECD is another one.
John Curran: Yes, Lee.
Lee Howard: Lee Howard, Time Warner Cable. I know, because I suppose Vint does, that the ITU is an interesting place.
When you were talking about the IPv6 working group, I realized I hadn't looked at them in a little while and was unfamiliar with the concept of a working group. I thought they only had study groups.
So I was out of touch. So I looked at the charter of their working group, which said that the working group should study certain items. I looked at the terms of reference of the working group that it came up with itself that it should come up with a global policy proposal to allocate some IPv6 to itself, to become another RIR.
How is that work going?
Raúl Echeberría: Let me say that I am surprised you read all those things.
Lee Howard: I have a very high tolerance for boredom.
Raúl Echeberría: ITU is a very complex structure. They have a big -- I don't know how to say -- sectors that create the study groups, that creates working groups, which create correspondence groups; that if we give them the opportunity, I'm sure we will create something else. So it is an endless discussion.
What you mentioned about the global policy, it was the result of some talks that we had with ITU, when they came up with that idea of becoming an IPv6 registry.
So what we told them at that time was that everything that we do is to implement the policies, and any change in the system should be approved through our global policy.
So what they understood from that, and in fact is correct, is that they should prepare a global policy proposal in order to change something. And it is a right understanding.
So it's part of the charter of the working group, but the working group has never talked about that, because there have not been any support in the working group for moving to that level.
In fact, the discussion has been more basic than that. Most of them has been about what are the obstacles for developing countries to implement IPv6, and what are the problems that the developing countries face to participate in the current system. But just titles, just because there have not been any real concern as present in the working groups.
The last meeting was held one week ago in Geneva, and Axel Pawlik chaired the interdelegation in that meeting.
I think that his reading about this meeting is very positive. But I don't know if you want to add something for --
Axel Pawlik: I'm a pathological optimist.
Lee Howard: For the record, Axel Pawlik says he's a pathological optimist.
Raúl Echeberría: Maybe you want to talk with Axel.
Sorry. I'm managing your meeting.
Axel Pawlik: Axel Pawlik, RIPE NCC. Yes, indeed, it was a fairly, I felt, positive meeting last week.
I felt there was a very strong feeling across the room. All the participants, member states and the I* community, ourselves, that we wanted to help with education and helping developing countries where we can.
I made the point we're actually doing quite a lot of education ourselves already and we're willing to work together with the ITU, BTU, development pattern, if they want that.
And I think there was a positive end to it, but, yes, then, I'm a pathological optimist. We'll see where it leads.
John Curran: Any other questions for Raúl?
Thank you, Raúl.
John Curran: Okay. We're almost done. At this point we open the microphones up under our open microphone session. This is for discussion of any matters that have come up, any additional topics people want to raise.
I ask, if you want to talk about policy proposals that are on the agenda for tomorrow, you wait until tomorrow, but otherwise the microphones are yours. Please.
If you have any questions, now would be the time to raise them. We have an open mic each day.
It is true we put this at the end of the day so people need to really want to speak as opposed to going outside. It's my intent actually to keep you here right up until the sun sets so there's no chance of making it to the beach. And here's a helper. Yes, go ahead.
Kevin Blumberg: Kevin Blumberg, The Wire. Over the last couple days I've been chatting with some people about a policy proposal that would more than likely be for the Philadelphia time frame.
And I thought this was actually a good time to get, instead of three or four people's input, 40, 50 or 100 people's input.
This came out of a recent newspaper article in reference to the purchase of large blocks of IPs, and what it actually did was, you know, putting that aside for a moment, it made me realize that the transfer market was upon us, and I hadn't really thought of how it was going to affect us economically or my business economically, and that I would need to start to do that.
So I started looking at it. And what I realized was that for many, many years we've looked at the 12-month of need, because there was no problem in getting the IP space.
You gave a good submission to ARIN; you had your IPs that day, the next day, a couple days later. And so based on an 80 percent requirement, again, you could do it because 80 percent, I have it a couple of days later, I'm all good.
Well, in the transfer market we now run into a problem where 12 months allocation or an 80 percent isn't necessarily going to work, because, A, it might take time and, B, there's now an economic issue, which is the biggest issue, to having to go back to a transfer market every 12 months, or shorter, based on your justified need.
So I thought what is the easiest way to make this change without writing a really big policy, and what I came up with was changing the 12 months to 24 months. Make it simple. Allow people to get what they need for the near term, but what is not 12 months to me is short term, very short term, especially when you don't know what the costs are going to be, et cetera.
So I just wanted to get sort of the feedback on what people thought of that concept as a policy proposal.
John Curran: Microphones are open. People who want to discuss the topic of changing the 12-month documented need requirement to 24, please approach the mics.
Obviously people can find you during the meeting and talk about it. But to the extent that the mics are available now, please come forth and speak.
Lee Howard: Lee Howard, Time Warner Cable, just because I like to get the conversation going I'll go first. We talked about this at little bit at lunch, at how to reduce barriers to participate in the transfer market.
And it's an idea worth considering. I'm not sure I support it yet, but then, again, I've only had 45 minutes to think about it. So, yeah, from that perspective, I wouldn't really have been in favor of it before we were talking about it in that context.
The idea of -- sorry, speaking slower -- the idea of making more addresses available so that they would go through the ARIN transfer process rather than outside is an interesting approach, yeah.
John Curran: Microphones remain open for this.
Geoff Huston: Geoff Huston, APNIC. I recollect only a few minutes ago Vint made reference to the OECD.
The realm that we're getting into, moving from a abundance into a scarcity problem and an allocation problem, is essentially a realm that predominantly as technologists I would say we're inappropriately qualified and experienced to truly understand.
The issues around distribution in a market or an environment in which scarcity is the driving factor have very different dynamics.
And, oddly enough, it is in that area where the OECD has done numerous studies in the past. And actually has a body of competence that, that, quite frankly, is a very useful resource for this conversation.
John Curran: You think there are resources available that would help the 12, eight?
Geoff Huston: Issues of liquidity of markets, behavior of markets, understanding how to ensure that to the best of our ability we're able to go through a transition to v6 instead of going through a transition into chaos and darkness.
Because, quite frankly, if anyone thinks that v6 is an inevitable and natural outcome of this process is certainly more optimistic than Axel.
The downsides of this is we just stuff up everything. Trying to get through this requires a lot more knowledge than we have in our community in Italy.
And we actually need to reach out to bodies that have studied similar issues in markets and environments and actually enlist and enroll their assistance and help. I, for one, have looked around and found that the most natural of these bodies has been the OECD. And the previous experience in the area of radio and spectrum allocation, in the area of domain name market studies, the OECD, one about eight years ago, are actually truly enlightening, in terms of the parallels of the situations that occurred many years ago in those markets, in emerging markets, to where we find ourselves at v4.
And I would certainly say this is not a problem we're going to solve on our own. We actually need help.
John Curran: Actually, the question, Geoff, on this particular topic of going from 12 months to 24, I guess you mentioned the OECD and its studies. Are you saying that's something that people should look at before considering 12 to 24, or that -- do you know the studies such that you would advise against or for it based on those?
Geoff Huston: I would advise going forward. I would actually advise: The more liquidity you introduce into a market, the more efficient the allocation mechanism.
If you constrain actors into limited horizons in their actions, I think you actually distort the situation and make life harder.
And making life harder makes the transition harder, makes everything go twisted and corrupted. And you might emerge three years later with an ITU-branded NGN with weird NPLS and wonder what happened to the Internet.
John Curran: On the subject matter of going from 12 to 24 months, would other people like to approach the mic and comment on that?
Obviously, there's a chance to find and talk to them later. But if you want to say anything at the mics, now would be the time.
Vint Cerf: Can I respond to Geoff?
John Curran: Sure.
Vint Cerf: As opposed to the 12 to 24 months. So, Geoff, you mentioned several words in your comments. And they were -- you didn't say -- now he's going to come back and shoot back. This is great.
Okay. So some economists think that frictionless markets with perfect information and rational decision making fit their equations.
But I think that we've learned that markets don't behave that way and that people will find either irrational ways to respond, or they'll find ways to go around almost anything that you've tried to create in the form of a reasonable market apparatus.
I'm actually worried about the chaos that could occur on the technical side in the consequence of trying to adopt a fully laissez-faire environment. So I'm sticking a lot of words in your mouth here, partly to provoke a reaction, which I'm sure is not difficult to do.
But I am worried that the economists may not necessarily have all of their acts together. All equations aside, people don't always behave according to the way that the theoretical models suggest. So I am a little worried about an overdependence on purely economic analysis.
Geoff Huston: Geoff Huston, again, in response. One of the things that impressed me about the OECD is that they're not the university, and they're not a bunch of theoreticians; they're actually a pragmatic group of folk who work with a set of governments.
And the outcomes and studies they do are, I think, actually really well researched. And they look at the problem pragmatically. And I go back to some of the work done in spectrum where the world moved slowly and inevitably from spectrum allocation into the mechanism of auctioning, because there was too many folk who wanted radio spectrum and too little to go around.
The allocation mechanism was fouling. And the OECD did wonderful studies about exactly what mechanisms are available to address this issue and studied the pitfalls of true laissez-faire markets.
And the RIRs that used to control the situation through allocation policies still have allocation policies but nothing to allocate.
One could argue that the mechanisms for control the consequent transfers, are extremely weak. As a community beyond just addressing policy, as folk who are interested in the outcome of the Internet, I think we have to understand the dynamics of where we're heading.
And I still claim that the OECD are one of the few bodies that has pragmatism associated with deep economic knowledge that make them pretty unique in this world.
Vint Cerf: Am I allowed a rebuttal? Actually, I don't disagree with what Geoff suggested, especially if pragmatism is part of the story, because plainly it's the outcome what we care about.
I would have to say personally that auctions for spectrum have always disturbed me because they tend to distort the market towards anybody who has enough money to go capture whatever spectrum is available. In our world, address space has not been allocated that way. It's been allocated a way to increase everyone's access to the Internet.
Auction-type solutions tend to restrict the way allocations get done. So even though you and I might step outside at some point and have a deeper discussion about this, but the point about getting pragmatic results, I think, is a very well appointed idea.
John Curran: Seems like a great discussion for a corner of the social tonight.
Now, closing that topic and moving on. Open mic is available. And that includes remote. I'm going to go only take a few more topics and then we're going to close it so we get out of here. If you have a topic, approach the microphones. Go ahead.
Wesley George: Wes George, Sprint. In the past, since the last meeting, there's been a fair amount of discussion on list both in reference to specific policies and just sort of -- I know I had started some more general conversation about what constitutes an emergency policy.
I had said that I, for one, would appreciate some clarity either from the Board or from the AC or probably both around either some sort of a set of rules of thumb, around an emergency. Something beyond I'll know it when I see it.
Not necessarily as a hard-and-fast rule, because you can't legislate everything. I wasn't necessarily recommending we should be doing policy around it. More just that either each individual member needs to be thinking about what do they actually define as an emergency and do they have some criteria they can use to identify it a little more objectively.
And I kind of want to start that discussion back up here where we can have a little more real time discussion.
I think that what's happened is that a number of the policies that everyone thought were huge emergency ended up not being for a number of different reasons.
So from that perspective, you can look at it and say, yea, the system works. We didn't go off half cocked and do a bunch of things that were not actually emergencies, in emergency policy, but I don't think that this is the last time we'll see one that people think they're an emergency and so I think it's still worth having the discussion.
John Curran: So on the topic of an emergency, the microphones are open. I'll say that the Board has discussed this matter several times. The last Board guidance on this says that an emergency would be a policy that needs to happen or be changed such that we don't end up endangering the mission of the organization.
So that's sort of the last -- that's the last email I sent in one sentence regarding this.
And there was some concern that to say more makes specific cases out of what must be a generalization, sort of by its nature. But to the extent people want to speak about it, now would be the time.
To the extent that people would like to speak about something else, now would be the time.
I am shortly closing the microphones. If you have any matter for open mics, please come now. I am closing the remotes. The remotes are closed.
Last chance. Microphones are closed. Thank you everyone for coming today.
John Curran: I will now -- first, a big thank you for our sponsor, AT&T. I have a couple of brief announcements to get us out. Tomorrow's question: How would you describe an ARIN meeting to someone who has never attended?
The staff is looking for people who are willing to be put on the record for a minute or two on tape to be included in the video we use to explain and promote the meeting when we have trade show booths, when we go out to talk to people. If you have a good answer to that, find us tomorrow at during of the breaks and someone will sit down with you and record you talking about how you describe an ARIN meeting to someone who's never attended. Begin thinking about that.
Next is the salsa dance, Take a Chance Salsa dance. Tonight it's at the Latin Roots Club in old San Juan, 6:30 to 10:30. Buses will leave the lobby at 6:15 and take you over there and then return buses will be returning between eight and 11:00 p.m.
They'll be leaving out front. Should be easy to find. Look for a member of the staff there to guide you. Reminders: Breakfast opens at 8:00 a.m. tomorrow. The meeting starts at 9:00 a.m.
The agenda is in your meeting folder or you can go online. We have policy proposals to discuss tomorrow. We have more presentations regarding updates that we've done. And I look forward to seeing everyone. See everyone at the social. Thank you.
(Proceedings adjourned at 5:03 p.m.)