Table of Contents
- Meeting Called to Order
- 2008-2: IPv4 Transfer Policy Proposal (continued)
- 2008-6: Emergency Transfer Policy for IPv4 Addresses
- RIR Update - LACNIC
- RIR Update - APNIC
- NRO Activities Report
- IPv6 IAB/IETF Activities Report
- 2008-5: Dedicated IPv4 block to Facilitate IPv6 Deployment
- 2008-7: Whois Integrity Policy Proposal
- 2007-14: Resource Review Process
- RIR Update - RIPE NCC
- NRO NC Report
- Open Microphone
- Closing Announcements and Adjournment
MR. PLZAK: Good morning. Good morning, good morning, good morning. I hope everyone had a good time last night at the social.
Okay. Just a few early-morning reminders. If someone could kill the music and kill -- and maybe cue the balloons or whatever. Thank you. First of all, reminders. Cyber Café is upstairs in the Heinsbergen Room, and that's the place where you can do all kinds of neat things. Remember, we will continue to do the Cyber Café survey cards. Bill neglected to bring his prize from yesterday, so we did not see that demo of the do-it-yourself straw last night, but Bill says later, so I guess there's always the bar tonight, right, Bill? Okay.
Remember, enter every A.M. and P.M. break. We draw names at each break. You've got to be present to win or if you're doing this remotely, you have to be online to win.
Help desk continues to be open. Remember, we have a billing help desk, an advisory council help desk, and the registration services help desk.
Information about all of them are on the slides. And remember, if you consistently lose in these drawings, you could still be -- a chance of winning the large 8-gigabyte iPod Touch, which is the grand prize, which will be announced on the 27th of October.
So, first of all, this is a year that the board appoints a member to the Numbers Council. By provisions of the MOU, the RIR elects two -- the community elects two members at-large and the board appoints a third person. This year was the year that the board does the appointment. And the person that was selected was Marty Hannigan again. So Marty returns to his seat for another three years. He's done us a good service in the past.
So, just a reminder, these are the rules that the chair will enforce. And I want to thank you all yesterday for observing these rules. We've had some very nice detailed discussions and these rules help them to go along in a nice, neat, civilized, orderly way.
So, at the head table you have, John, Bill, Stacy, Dan, Scott. Manning the virtual microphone, Cathy, and then I'm way on the end.
MR. PLZAK: Now let's have a word from our sponsor and that will be Celeste Anderson from USC, Los Nettos. And Celeste, the show is yours.
MS. ANDERSON: Hi, I'm Celeste Anderson. I'd like to welcome you to Los Angeles on behalf of CenterGate Research and Los Nettos Regional Network, which are hosting these meetings. The Los Nettos Regional Network is comprised of member organizations: California Institute of Technology, Claremont College, Jet Propulsion Laboratory, Loyola, Marymount University, and the home of our administrative offices, the University of Southern California. A special thanks to Cogent for providing the fiber from the hotel to 1 Wilshire and to InterWorld Communications for doing the on-site visit and on-site support.
Today, as many of you know, is the anniversary of Jon's passing. So he did found Los Nettos along with Danny Cohen, and we'd like to pay a little tribute to him for all of the things that he has done. Not only did he help create Los Nettos, he directed the early deployment and the development of the network until his death. And we are now in our 20th year, which I don't think anyone thought we would survive that long. So it's a tribute to his legacy that we could continue on for another 10 years and we hope to be seeing you in another 5 or 10. So, we just want to say we miss him, but we're sure everyone here is carrying on the legacies of the things that he's done. And I think he would be very proud to see all the work that everyone's doing here at ARIN. Thank you.
MR. PLZAK: Thank you, Celeste.
MR. PLZAK: So now we are going to resume our discussion of 2008-2. And as a reminder, we were in the discussion phase. Also, at some point, the chair will terminate this discussion and we'll pick up 2008-6. So, John, I will turn it back over to you.
MR. CURRAN: Thank you, Ray. Okay, as a reminder to everyone, the microphones are open. We ask people limit their presentation at the mic to three minutes or so to give other people an opportunity to speak. Once everyone has had a chance to speak, if you want to come back for more comments, please do so. When you approach the mic, if at all possible, start with a statement of whether you're for or against the proposal. And microphones and remote participation is open. Come forth.
Randy, center rear mic.
MR. BUSH: Randy Bush, IIJ. ARIN DC, that stands for "disgruntled customer." I actually have a real paying job, though, that that's IIJ.
My disgruntlement comes from the enormous swirling stuff and discussion and irrelevance and this is a very tough industry. Times are going to be tough. They're going to be tougher. We need to really focus on the reality and what really needs to get done.
With all due respect, Marla, if you're worried about in the next reorg they're going to start selling your address space and routers and desk chairs, you have a problem you're not going to solve here. You need to solve it at your board of directors, right?
And Dan, if we're worried that in implementing this -- hi, Dan. I'm in no rush, by the way. I agree there's no clear rush for this because I think nobody's going to be seriously deploying IPv6 until they can't get a v4 space. And I don't think they're really going to be trading this stuff, so I'm not in any rush. But I think your statement was very telling. You're worried about people paying to buy IP space via transfer instead of getting it for free from ARIN. Well, when somebody's willing to pay somebody over there to get something they could get supposedly for free over here, there are some hidden costs you're not talking about. And somebody's willing to pay money not to do business with you, maybe you've got to figure out how to make it easier to do business with you. Okay. And excuse the use of the word "you." I'm here, too, and I'm part of to this mess and helped make it.
I really think that the reality is we're leasing integers. And, unfortunately, it is not an infinite integer set. It is very finite and we're running out of them. And the fact that we're leasing them tells you it's an asset. Right? Let's not fool ourselves. And we're not even charging per how many blocks, i.e., how much work you have to do. We're charging by the amount of space. Let's get honest with ourselves, okay.
So we're going to be in a transition. We don't like this transition. It is ugly. But the seeds of it were planted long enough ago and it's too late to change. We cannot fix IPv6. We cannot make more IPv4. So I think we really need to focus narrowly on what we can do as on organization and as part of the Internet culture to make this work as best we can with as little pain as we can. And it's going to be pain no matter what, okay.
So I just think transfer is inevitable, but some constraints on it so, you know, we get kind of what we want in terms of limiting the disaster that's going to happen to us. Worrying about routing table inflation and correcting that and policy, you know, making it so they can only fragment it, that's fantasy. They're going to announce /24s as soon as they have it, you know. They're going to make garbage in the routing table we've got. The routing table's over half garbage now.
The way this group can solve the problem is by pushing the RPKI and then routing security so people don't announce those /24s in an attempt to get some sort of fake security. That's a real path to that, right? Making funny policy to try to get there. I have sympathy with the desire, but I'm an engineer, let's get real. Sorry to rant so long.
MR. CURRAN: Randy, you know I'm going to ask it. Given -- focused, as you said, focused on the narrow things we can get done --
MR. BUSH: I said yesterday, this is close enough, I'm willing to support it.
MR. CURRAN: Thank you.
MR. BUSH: I said that yesterday, John.
MR. CURRAN: Just my memory is short. Thank you. Over here, left mic.
MR. TEMPLIN: Pete Templin with Texlink Communications. I wish to defer my support or not until I ask a few questions just because I'm new at this.
MR. CURRAN: Sure.
MR. TEMPLIN: When did justified need become standard practice for address assignments, ballpark? Pre-ARIN? Post-ARIN?
MR. CURRAN: I'll answer to the best of my knowledge, and anyone who wants to comment should come up. I believe that it was formally codized in RFC-2050 where it was -- Randy's waving.
MR. BUSH: SRI, Jon, et cetera, all the way back.
MR. CURRAN: But I'm told by Randy it goes all the way back to the very beginning when it was based on need, though we didn't have well-fitting address blocks back then. You've got an A, a B, or a C because that's what was available. When we actually had 2050 in CIDR, we made sure what you got was well-suited to your application and your growth over your application.
MR. TEMPLIN: All for now.
MR. CURRAN: Okay, wonderful. The microphones remain open. Far right?
MR. SPRINGER: John Springer, Inland Telephone. I support 2008-2 as written. I find the legal arguments compelling.
MR. CURRAN: Okay.
MR. SPRINGER: Technical arguments just don't really have any effect on me at this point. I'll support this policy. If this one fails, I'll support 2008-6. In that one fails, I'll support another policy based on a liberalized transfer of policy.
MR. CURRAN: Okay. Good to know. Microphones and remote participation remains open on Policy Proposal 2008-2. Far left microphone.
MR. CASSIMIRE: Thank you. Nigel Cassimire, CTU. I am opposed to the idea of a market in addresses because I think it flies in the face of the concept of addresses not being property. Thank you.
MR. CURRAN: Okay, thank you. Microphones remain open on this topic. I'm told this topic is of some importance. Microphones remain open. Yes, center rear.
MR. DUL: Andrew Dul. I think we, in some cases, are looking at this in very different ways. And I realize that this is a very hard issue for us to grasp. This is a paradigm shift from where we've been going for a long time. And I think myself and others have certainly struggled to try to figure out, based upon the arguments we hear from different sides, how to come down on this specific policy version or even transfers in general.
And I think one thing that we need to make sure that we keep into account is what's going on in other registries. Specifically, RIPE and APNIC both have transfer policies that are pending. And it would be probably to our own detriment if our policy did not in some way map somewhat to what other regions are doing, given the way that addresses move between organizations and even between continents.
So, I would certainly like to hear -- we haven't had any formal comments about what is going on in the other registries. And I realize the RIPE meeting is next week, so -- or the week after, whatever. So, you know, there hasn't been a lot of comments made, you know, since the last meeting, but I certainly would appreciate if either of those registries, people who have been to those meetings or others would like to make comments about that, that would be appreciated.
MR. CURRAN: Folks who want to address that topic, please approach the mics.
MR. BUSH: Randy Bush, chair of the APNIC Address Policy Committee. This has been under discussion two or three cycles in the APNIC policy process. It's still under discussion. At the last meeting there were about two-thirds for the currently proposed policy, one-third against. And I don't consider that consensus and we're a consensus process.
One thing that has come up there that's of interest to what you asked, Andrew, wherever you disappeared to, is that the current policy proposal in APNIC says it has to be between consenting APNIC adults. And one of the strong comments that was raised but ignored by the proposer there was that it would work a little better if what it said is if the selling -- excuse the term, I know this affronts some people -- if the selling party was following the rules of their registry and the purchasing party is following the rules of their registry.
So for instance, if somebody in APNIC wants to sell to ARIN and ARIN says it must be needs-based, then the buyer has to be needs-based, et cetera. And that kind of starts to approach the inter-registry issue, but that's life in the big city. The RPKI structure is specifically designed to allow transfer and allow inter-registry transfer.
So that's not a technical problem. And having just moved some address from one region to another, that's not too ugly a problem either. Thank you.
MR. CURRAN: Far right mic.
MR. HUSTON: Thank you, John. My name is Geoff Huston. I'm with APNIC. I happen to be the author of the transfer policy proposal in APNIC. And in response to Andrew, you might find some comments from me helpful to your particular discussion.
The APNIC transfer policy proposal is quite different to the one here that you are considering. And basically the fundamental point of difference is that in APNIC, we are not proposing any constraints on the parties in terms of meeting any criteria in terms of demonstrated demand or need. If two parties wish to transfer addresses, they can.
So, why do we believe that the absence of such constraint is valuable and necessary? Why do we believe that it is not in the interests of the community to actually impose such regulatory constraint on a transfer?
And I think, John, part of the issue comes that for the last few years the RIRs have actually been undertaking three roles in a horrendously intertwined mess. They actually perform the functions of address allocation. They perform the operation of registration services and they perform a regulatory function by imposing policies upon the allocation function. So you only get addresses if you meet certain criteria, basically regulatory criteria.
So, this worked fine while abundance was happening. While there were so many address around that you could get what you need, quite frankly, the regulatory function was relatively minor and abundance is forgiving. So this is fine. But what we have now is an imposing -- is a condition coming through that, quite frankly, inside two years we've either completed the transition to IPv6 and we haven't got a problem or we haven't. And if we haven't, we're in dual stack land. And dual stack land says you need v4 addresses as much as you need v6. And the real question is, where are you going to get them? Because there is no longer an allocation function.
Now, what I'm hearing in this community is that despite the fact that the allocation function would have disappeared, what they regard as a conservative view of transfers is to attempt to impose the same regulatory limitations upon the registration function. That is not conservatism. Oddly enough, it's a radical shift to the registration function. Because if you think about it, the conditions and policy manual you have are actually all about allocations, not registration.
Now, the real question is, in a deregulated industry that actually doesn't have control, where to be brutally frank, the registry that we use is a case of convention and utility, not command, the existence of the registries and which registries are used are those that are useful. And if the registries are out of date, inaccurate, or otherwise unused -- and there are some today that are called route registries that suffer that fate -- they're no longer useful and no longer used. It is not a mandatory.
If you impose too many constraints on the access to the registry function, your registry becomes irrelevant to this industry. And the body that runs it suffers a similar fate.
So if you really want to understand what v4 is happening in the next few years, and what policies allow the one residual function that you will be able to contribute to this industry to be useful, the most conservative view, the least radical, the one that preserves the status quo is actually the one that you call the most liberal, the one that imposes no constraints whatsoever on continued access to the registry function. Because if you start imposing constraints and apply an allocation regulatory framework into registration, it is not in the short outcome that the registry will continue to be even relevant, let alone used.
So this is why the APNIC policy proposal is indeed remarkably slim. And it honestly says if we know you, both of you, and you both agree you're going to move the address block, move it and we'll register it. If there is a regulatory function in this industry around market behaviors, there are folk whose roles and responsibilities and authorities are there to regulate markets. APNIC is not a market regulator. We don't employ them. We're lousy at the job. We have no authority. We believe that being imposed or have that role imposed upon us would force us into unnatural acts, unnatural positions, and a marginal relevance. And if we seriously believe that we are of use to this industry and will continue to be of use and utility to this industry, we have to do what people need us to do, not what we would prefer to do.
And in scarcity, which is what we have in v4 in a couple of years, there's no such luxury of preference anymore. Need becomes absolute.
So thank you, Andrew. I hope these comments are at least helpful to you.
MR. CURRAN: Thank you, Geoff. The microphones remain open. Far right mic.
MR. VEST: Hi, there. Tom Vest. I'd like to present a slightly different view.
The RIRs have always been involved in a quasi-regulatory function since they existed, since before they existed. The mandates, they are created and the needs for which they are created, which are spelled out in RFC-2050, deal with address conservation and with conservation of also scarce routing table capacity, routing subsystem capacity.
And they have, just like, say, banking regulators, have managed this through very indirect means by establishing a -- by creating establishment criteria for top-level participants in the system, those who will enjoy discretion to -- one way or another to affect those two systemic risks thereafter and then establishing basically reserve requirements. Unlike banks, banks have minimum reserve requirements, we have maximum reserves. You can't go back for more address resources until you've actually distributed them, so that limits the hoarding question. They're very much like a banking system. We have -- it's an indirect regulatory thing. And sometimes it doesn't work and sometimes things go awry. And some central banking system have more tools available that the RIR system.
But the key thing to remember, too, is that in different points in time, the central bank was not a sovereign sponsored thing, but rather an industry consortium of that financial institutions that came together for the limited purposes of mitigating these systemic risks of inflation and deflation, and they worked together. They didn't see their sovereignty or commercial ability to do anything except for these narrow functions which permitted -- which reduced the risk of the entire industry collapsing. All right.
Unfortunately, you look around and you find that today there are no countries in the world where bankers' clubs continue to exist and operate in this function. And it's because at various times of crisis, like we're facing right now, the members of the consortia that ran -- that had self- governance over the financial sector took to a sort of every man for himself approach. And the result was the level of volatility which became intolerable to the surrounding communities.
And I would say that just as the banking sector is now, that the Internet has become a critical infrastructure of the kind that is -- the volatility in which is not going to be tolerable by the larger surrounding community. So it think self- governance is something which is -- it's not a right, it's basically -- it's not a right that can be asserted. It's something that we get to do as long as we do it successfully.
And I have grave concerns that a move to privatize this will basically make it extremely difficult for us to satisfy that condition which grants us the opportunity to continue pursuing technical as well as institutional means to try to make this industry to work as well as possible. And I'm also sorry that I spent so much time at the mic.
MR. CURRAN: Not a problem. Tom, just given that your view regarding self-governance, where do you come down regarding Policy Proposal 2008-2? Do you have a particular view in favor or against?
MR. VEST: Yes, I'll reiterate that as I said yesterday I am against the resource transfer.
MR. CURRAN: Okay, thank you. And Geoff, I hate to single you out, but, of course, I forgot to ask the question of you.
MR. HUSTON: I think the imposition of policy and constraints on this is actually unnatural, so I would actually say no, I don't think this is the right policy for ARIN to adopt.
MR. CURRAN: Okay. But you're for a policy, but just not this one with its constraints?
MR. HUSTON: I come from another region. I'm not a stakeholder in ARIN and I suppose I'm really trying to offer you a perspective from someone who (off mike) differently. So I'm giving you a personal perspective and I don't vote in your region.
MR. CURRAN: That's fine. That's fine. Understood. Thank you.
The microphones remain open. This is a matter of some import to the organization. Anyone who would like to express a view one way or the other? The far left microphone.
MR. RICH: Yurie Rich, Command Information. This is more clarification.
So, in the APNIC transfer policy model, where it's kind of no restrictions, if I remember from yesterday, there's a fair amount of legacy space here in the ARIN region versus the other ones.
And so in a model where you have address space being transferred from one entity to another, how does the RIR know that the entity transferring the address space actually has "title to it?" How do you prevent an agency or an organization from just saying, hey, yeah, I own the 15 space, so here you go, have it.
MR. CURRAN: So, just I want to ask for clarity to make sure that we get the right people answering it. Are you discussing how that happens in APNIC under the APNIC proposal or are you asking how that happens in the ARIN region with respect to a transfer policy?
MR. RICH: Well, I think it would be relevant to both.
MR. CURRAN: Okay.
MR. HUSTON: Geoff Huston. Firstly, let me just point out it's Proposal 50. I authored it.
APNIC Secretariat didn't and APNIC didn't. We're considering it. So when we say APNIC proposal, it's shorthand.
The proposal basically says that the disposer of the address space is a current member known to APNIC, and the address space they're disposing is part of their registered holdings, so that we understand that we will do transfers when we knew and understood who was disposing as well as who was acquiring. It is online. They're in the policy development are of the web page of APNIC under Proposition 50, I believe it's called. So the idea is you both have to be current members and the resource being transferred is currently known to the disposer.
Does that answer your question? Thank you.
MR. CURRAN: I can actually, with respect to the ARIN region, I'll answer at a high level and if you need more, we can grab staff. This actually occupies quite a bit of the board discussion.
Presently, in order to perform a transfer under organizational merger and acquisition in ARIN's transfer policy, you need to show that you're the bona fide holder of the resource. And that means ARIN's gotten pretty good about looking at the pedigree of requests coming in and determining the history. Not perfect, but as good as one can get.
Right now, in order to do such a transfer, you need to be under a Legacy RSA and be the bona fide holder. If this transfer policy went through, the removal of that means not that you wouldn't have to be under an agreement, but you would still need to be the bona fide holder. It would still be reviewed to make sure we were doing a transfer that we thought was legitimate. So there's still going to be a level of assessment and analysis to make sure we're not creating a transfer of something that might not be legitimately held.
MR. RICH: So if I understand you correctly, that would mean a legacy holder, which is probably largely who this was going to be, what this market would be, would have to be under RSA.
MR. CURRAN: No, the legacy holder would have to have demonstrated record keeping that they were the legitimate holder of that address.
MR. RICH: Okay. All right, thanks.
MR. CURRAN: Yes, center rear.
MR. BUSH: Randy Bush, IIJ. I suggest you Google RPKI, Resource Public Key Infrastructure. Ray has said publicly on the PPML list that ARIN hopes to be deploying a prototype of this by the end of the year, and this policy certainly wouldn't take place before the end of the year. So you would have a validatable X.509 certificate chain formally testable and validatable to show the certification of ownership or whatever you want.
I'd also like to note that no proposal has passed in any region. There were objections to -- since Geoff is 'fessing up to the source of the APNIC proposal in the APNIC region and some of them were that it didn't have enough complicated policy around and some of the objections here is that it has too much complicated policy around it. And in two weeks, I'll get to hear whatever the story is at RIPE. And I think we're just in a process that's trying to boil it down and find the right balance.
MR. CURRAN: Far left microphone. I am going to be closing the microphones shortly. If you wish to speak on 2008-2, please approach the mics quickly. Yes.
MR. TEMPLIN: Pete Templin with Texlink Communications. I want to voice my support for the proposal such that we strike the deaggregation language and change the timetable along the lines that it becomes effective upon ARIN receiving its last unconstrained v4 address allocation. I know there's talk of one that's reserved for v6 transition. This would be essentially effective upon you receiving your last unconstrained address block. And there's always the caveat that these meetings and the PPML, et cetera, the policy process exists to refine the language you're about to install as needed between now the end of an epic.
MR. CURRAN: You consider those to be improvements to the policy proposal and you'd lend your support if they are made?
MR. TEMPLIN: Yes.
MR. CURRAN: If they weren't made, would you lend your support to the policy proposal as written?
MR. TEMPLIN: I'm undecided at this point.
MR. CURRAN: Okay, thank you. Closing the microphones very shortly, so step up if you're going to be speaking. Front and center.
MR. FARMER: David Farmer, University of Minnesota. I'm opposed to the current proposal. I think we need to work on it more, so I wouldn't move it forward at this time. But I'm fundamentally in favor of some kind of transfer policy.
There's some interesting ideas that the discussion has raised in my head. It's been said several times that ARIN is a registry service and that's its primary service. Sometimes people completely ignore the assignment process, but that's the world we're going to be in. There ain't going to be nothing to assign anymore. So I do take Geoff's comments seriously and they're interesting and we should think about them.
The other thing that might be interesting since we say that even ARIN-assigned addresses aren't guaranteed to be routable, we're not supplying any guarantee about these transfers being routable either. Should we be supplying information to the people that make those decisions about whether things are routable as to what kind of registration this is? Was this an ARIN-assigned registration or was this a transfer? This then lets those people who have to make those decisions have the information to make that decision.
MR. CURRAN: Okay.
MR. FARMER: I'll end my comments now.
MR. CURRAN: Okay, thank you. Closing the microphones? Enter the queue if you're going to enter the queue.
Microphone are closed. Do not enter the microphone queue. We are going to get final comments. Far left.
SPEAKER: Igor was actually here before I was.
MR. CURRAN: Of course, center rear.
MR. GASHINSKY: Igor with Yahoo. I very much agree with what Geoff was saying. I think it's critical for us to be able to continue to hand out addressing. And I would support the policy with Pete's modifications at the point that there are no more unconstrained IP blocks. ARIN's function is a registry. And if other people have IP addresses that they could lend to that function, for whatever value of lend that happens to be, we should accept them. Because if people meet our allocation guidelines and other people have space that could be allocated, we should use it.
MR. CURRAN: Okay. Thank you. Far left.
MR. SEASTROM: Rob Seastrom, ARIN Advisory Council and ClueTrust. My thoughts on this stuff has changed over the months that we've been discussing it and I'm not sure whether it's fatigue, pragmatism, or maybe a little bit of both.
We already have a transfer policy and it involves money changing hands. And everybody who's filled out a slip template has been involved in it.
Now, there's other stuff involved in it, like, you know, irrevocability and maybe other services being sold and stuff. But the concept that this is something new and shocking is, frankly, something I don't subscribe to.
This is my second favorite policy after 2008-6 that involves this. And the reason is that I believe that the overriding concern here should be to make sure that the information in WHOIS and in the registry has some sort of semblance of reality.
And right now the situation is bad enough. Let's not make it worse by encumbering it with more difficulties and making it harder for people to keep the information correct. So I support this policy proposal, but not as much as I support other policy proposals that makes it easier.
MR. CURRAN: Okay, thank you. And final comments? Lea.
MS. ROBERTS: Hi. Lea Roberts from Stanford University. And I've been participating in this all along, too, and find myself torn in multiple directions. I can see the need to have IPv4 addresses during the transition phase and can't, you know, miss the upcoming depletion. It's certainly happening, there's no question there.
I guess one of the issues which I feel we haven't really struggled with enough was presented by the LACNIC and APNIC folks a meeting or two ago about the great unfairness that's happening with the amount of legacy space in the ARIN region and the lack of resources that they have available. So I have a kind of off-the-wall thought. It's not at all gestated, but I figure I might as well throw it out so other people can think about it.
And that is, you know, there are a lot of people with vast resources that if they were "good net citizens," would be returning them to ARIN already. So it leads me to believe that they're at least somewhat already looking at the future monetary value of those resources. So transitioning from an Internet where, you know, it was all a cooperative adventure and we all kind of tried to make it as good as possible to this commercial Internet has been a struggle for me.
And I'd like to think, I don't have any evidence of this, but I'd like to think there's still some goodness out there in legacy address holders since they were part of that time when the Internet was that way. And just like, you know, businesses, once the business people, the MBAs get involved, things change in a start-up or whatever. The Internet's reached that phase.
So I'd like to somehow appeal to whatever residual goodness there is in people who control address space. And, like I say, this is an off-the- wall, ungestated idea, but I was thinking of something like the Presidential Campaign Fund on your IRS taxes here, where if you're a legacy holder and you're going to be trying to transfer some legacy space, perhaps we should actually encourage people -- we can't make them, as Jeff pointed out -- but we should maybe encourage people to take a portion of the space that they're about to release into the transfers, if it happens.
And I guess I didn't say I'm not at all sure that I support this policy or the other one. But if it happens, maybe we can try and provide a window of goodness for people to say, you know, check here if you'll provide some amount of space to AFRINIC, check here if you're provide some amount of space to LACNIC or whatever like that.
MR. CURRAN: Interesting insight. And you did comment that you're not sure on your position on this or the other one, correct?
MS. ROBERTS: I said I'm not clear.
MR. CURRAN: Not clear at this time, okay. Thank you. Comments have concluded.
In order that the AC can do their most interesting job there's time to time when we have to ask for a show of hands. I will remind people we do have another policy proposal we'll be talking about as well, but we talk about these and we do shows of hands independently and all that goes to the AC and they try to figure out what they're doing.
So on this particular policy proposal, 2008-2, I'm going to ask for a show of hands of everyone in favor and everyone opposed. This includes both people here and people participating remotely.
So I am seeing that my polling mechanism is operational. Good, very good. Okay. So we have the technology.
On Policy Proposal 2008-2, IPv4 Transfer Policy, everyone in favor, please raise your hands now. Nice and high. Okay, thank you.
On Policy Proposal 2008-2, everyone opposed, please raise your hand now. Nice and high.
Okay, thank you. The tabulation is underway. I can hear the chads flying.
SPEAKER: That's only in Florida.
MR. CURRAN: That's true, it's only in Florida. That's the other Disney.
On the matter of Policy Proposal 2008-2, the number of participants, 129; in favor, 11; opposed, 45. This information will be provided to the Advisory Council for their consideration. Thank you.
MR. CURRAN: Now we will move on to Policy Proposal 2008-6. It's entitled "The Emergency Transfer of Policy for IPv4 Addresses." It was introduced and designated as a formal proposal in August of this year. It's been discussed at one policy meeting, that in Nassau. The current version is the original version. The same two related policy discussions that are occurring in the APNIC and RIPE NCC regions. Slightly different take on this, transfers are allowed for three years. Recipient must document need. Original prefix may not be aggregated into more than four pieces, each greater than or equal to the current minimum prefix size. Shepherds are Owen and Stacy.
The council's general assessment is it's less risk for the same reasons as for -2. The staff comments without the involvement of ARIN, the text should be removed and also in practice the minimum -- just as a note, the minimum prefix size would be a /22. Minimum resource impact, about 90 days to implement this. Some discussion, 3 in favor, 4 against, 82 posts, 22 people. I won't read the comments, but you can see where they are. If you want details, go to the archives.
And so I'd like to call on Bill Darte to come up and present his proposal.
MR. DARTE: Good morning. I'm Bill Darte. I'm on the ARIN AC. It was with great consternation that I undertook authoring this policy proposal. It's been experience through my 10 years on the Advisory Council and involvement with ARIN that it's a problem to have multiple policy proposals that address the same subject. We've tried to relieve ourselves of that confusion over the years, and then I find myself doing it on purpose here again. So I apologize for that.
But it was also because of my 10 years of experience on the Advisory Council that I looked at what we had created with 2008-2. And irrespective of what the merits of that policy proposal were, I looked at the detail that was involved in it and said there's no chance in -- (Laughter) that that's going to actually achieve consensus. And so it appeared to me that if, not -- this isn't my personal opinion, if the community were going to want a transfer policy to move along, then perhaps a less cumbersome, a less detailed, a less hard to understand and rationalize version might gain a consensus if, in fact, the community wanted such a policy. So that's why I authored it.
Like I say, I debated it for myself. It was only through the encouragement of some of my colleagues on the AC that I actually ended up doing this. So for those of you who think having to think about this twice in two different ways is a problem, I apologize.
So the rationale, it potentially, okay, the way this is written, it potentially allows ARIN to fulfill its mission and to facilitate a continuing supply of IPv4 addresses when ARIN resources are no longer adequate. I say "potentially" because this would be at the discretion of the board of trustees.
In my proposal, I delay the instantiation of this policy or the recommendation of immediacy and say this would take place when -- this is an authorization in advance to tell the board of trustees that if, in fact, they feel that this is, in fact, necessary to invoke the transfer policy, then they would. And that could be the day after it was ratified or it could be the day after there were no longer resources available to meet the needs of potential recipients.
It's intent is to preserve the current tradition of needs-based allocation and assignment because that's what we've heard clearly out of discussion up to this point in time in this community. The policy is not intended to create a market or to condone the monetization or the sense of ownership of resource assets. So there's no intent to do that. The consequence may well be that, but it's not the community saying this is -- we're actively wanting to go in a different direction.
The policy is intended to be transient and lightweight. Lightweight in the sense that it's not encumbered by a lot of detail. On the policy proposal -- or excuse, me the public policy mailing list, that was one of the criticisms of it. Well, there's nothing in here. That's what makes it so lightweight and easy to assess, I guess.
It's transient on purpose, also, because I've heard a great deal of discussion and we in the community in general have heard this on the public policy mailing list that one of the concerns that people have is that what this community does may have an impact upon the incumbency of IPv4. I've heard a lot of people say whatever we do should not get in the way and restrict the emergence of IPv6. So the transient nature says this isn't a forever thing. This is an emergency transitional policy. That's what it's for. It's invoked, if needed, by the assessment of the board of trustees. And it would last for no more than three years unless they thought it should -- "they," the community at large here thinks it should last longer than that. So if the transitional period were longer and this was brought back to the floor and said we need to extend this, this should be something that we should do for a longer period of time, maybe forever, who knows, that would be a decision that you all would make.
So the staff comments, it said without the active involvement of ARIN, it ought to be removed.
I have no objection to that. "Without the active involvement of ARIN" meant, and it's stated, as an intermediary, meaning an active intermediary. The idea was not to say that the transfer of the resources would go to ARIN and then go to the recipient from the resource holder. That the transfer would go between the two making the transaction. ARIN would only account for it. Okay.
And then be involved to the extend that the policy states that the recipient would meet a needs-based test and would sign an RSA with ARIN in advance.
All right. In practice the minimum size would be a /22. Yeah. The policy says need in accordance with current and applicable ARIN policy.
So currently that is /22 and so that's what it is. The impetus, we don't know, okay, that it will be a problem, you know. The probabilities are it's going to be a problem, but we don't know. If it is, the board of trustees may act based upon your authorization. Between now and then, this policy could be amended to add features.
So, if the reason that the lack of consensus, and, you know, I'll betray my own judgment of what those numbers were just a little bit ago, my own judgment was there wasn't a lot of consensus for 2008-2. If fact, if there had been, it was my pledge to abandon this policy proposal, okay, in favor of the other. Since that's not the case, we're doing this now.
Between now and then, however -- remember "then" could be the day after, you know, consensus is adjudged and the AC sends it forward to the board of trustees for their consideration. They might say well, we need this right now and put it in play or they might delay until they're convinced that such a thing is a good idea. That would be the authorization that you would be providing them.
But assuming that it would take some time down the road before the board considered this need and would implement it, then, you know, we can augment this with any number of other components, other considerations, things that we could get our heads around one at a time and address one at a time and vote up and down to augment this. So it's modular in that sense because of this delayed implementation stance. That's the intent.
For those who believe something -- excuse me, it sends the right signals, I think, to the external community, that in passing such a transfer policy with -- it's, you know, it's sort of passing it without passing it, pass without implement, we send the right signals that ARIN is not abandoning its stewardship responsibilities; that it's prepared in light of circumstances to be uncovered and discovered as we go forward; to act, okay, based on community consent and encouragement. And again, it may be this policy as is or it may be an augmented policy through future considerations, depending upon the timeline and the circumstance that come and emerge.
Okay. So for those who believe that something is needed, we've heard, you know, from both internal and external community members that somebody thinks something ought to be done in the way of transfer policies to maintain the relevancy of ARIN to the community and to the control of this industry, then this policy is in play. If you feel like something has to come out of this meeting, then this is an opportunity for your consideration.
That's all I really have to say. Thank you.
MR. CURRAN: Okay, thank you. Microphones remain open for consideration of this policy.
MR. DARTE: You don't mind if I just duck a little, though, do you?
MR. CURRAN: Plenty of room between him and me. Okay. Far right microphone.
MR. VEST: Thanks. Tom Vest. Just a quick question. You described the proposal as temporary. Do you envision that the agreements that -- the transfer agreements that result, that this will all explicitly assert that any transaction results will also be temporary and subject to revocation or revision by the subsequent decisions of the community or, you know, by subsequent decision making?
MR. DARTE: No. My thinking along those lines when I authored this was that any transaction that would be authorized under this policy proposal, or policy if enacted and implemented, would be, you know, considered, you know, a transaction like any other, if that was the question. Yeah.
MR. CURRAN: Okay. Leo.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. My concern here isn't so much with the policy itself, although I have some concerns there, it's with the implementation timetable. I fear that by passing this and giving the opportunity for the board to decide later actually alters the checks and balances of power inside of ARIN. The board, in fact, already has the power to do this on an emergency basis if they want. There is an emergency clause and we need not write them essentially a blank check ahead of time to be able to do that should they deem it absolutely necessary.
And I feel on several sides it is a tacit (off mike) approval to the board to tamper in policy in ways they do not today. But I also feel that it's an abdication of responsibility on the community, on the AC, on everyone in the input process in the normal policy process to essentially pass on making the decision and hand it to the board. So I don't like it from either direction. I feel like if we feel this needs to be implemented in the future, then we the community should say in the future that it needs to be implemented.
And if the concern is we that only have meetings every six months or something like that, the board has the emergency ability. And I would hope that in using that, they would seek the input of the AC and perhaps the mailing list ahead of time such that if we feel it has to be done without a meeting or something like that, there still is some piece of the bottom-up policy process advising that decision.
So that's really where my concern comes with this proposal most severely. Although I think in general I'm not in favor of an unrestricted transfer proposal even if it had a different timeline.
MR. DARTE: So, my sense of this when I wrote it this way, I mean, I did consider that. This had two elements to me. One was the telegraphing of the community itself to all external agencies, whatever those people and those agencies might be, that there was consideration, there is a plan, et cetera. It also, along the lines of this, understanding that the ARIN board can enact policy any time they want to if they consider it an emergency, could do this, but there's no -- I thought they would be relieved to know that the community was behind them when they took this action and that it wouldn't be a surprise to people even in the time frames of beginning to put this out on PPML and, you know, advising the advisory board, et cetera. So it was just a way for them know that the community supported them in the action in advance and that's why I did it this way.
MR. CURRAN: Okay. Owen.
MR. DeLONG: Owen DeLong, ARIN AC. I have to disagree with Leo, which is kind of unusual, but in this case I'm going to. I think that this provides clear guidance to the board of what the community would like them to do should this emergency arise. We all kind of know that this emergency is going to arise and we should plan for it, but I think allowing the board to decide when it's actually an emergency and whether this should be implemented or not, if we're going to implement something like this, is not a bad idea.
On the other hand, I think implementing something like this is still a bad idea.
You know, no matter how much lipstick we put on this pig, it's still a pig.
MR. CURRAN: And so in summary, you are against the proposal? Tom.
MR. VEST: Another question. Tom Vest. I understand that there's been some recusals amongst the trustees in matters of transfers because of possible conflicting incentives and things like that. And I'm wondering if in your proposal it takes account of those in any way, whether or not the decision-making of the board on executing on this proposal would be constrained by those recusals and/or whether, you know, the choice of what actions to take would be effected.
MR. CURRAN: Actually, that one's for me as it turns out. So the board actually has a formal conflict of interest policy. It requires written disclosures, so we actually all are aware of board members and their motivations and incentives. And that means that on some subject matters the board members either self-recuse themselves or are asked by the chair to recuse themselves, either from the discussion, but almost always from the votes if not the discussion of the topic because of the possibility of direct beneficial interests in the matter.
Now, if you're asking the question does the board see a difficulty with this policy and being able to execute on it if it felt the need, no.
We have sufficient members who are unconflicted that would allow us to perform this measure if necessary.
MR. VEST: Is it possible -- I'm sorry, I guess, is it possible to know the number that would be not -- would not be affected by the recusals?
MR. CURRAN: At present we have two board members. Remember, we have an election coming up, but at present we have two board members who could be considered directly beneficial to a transfer policy that allows monetization of resources.
MR. VEST: Okay. Thank you.
MR. CURRAN: Far right side.
MR. SINATRA: Michael Sinatra, UC Berkeley. I have a question for the ARIN staff. We talked about in practice the smallest block would be a /22, and I assume that refers to deaggregation portion because I can see a market actually forming for old, swampy, Class C /24s. How would the ARIN staff deal with a situation where someone wants to transfer those because somebody else wants to run a (off mike) service and there are no micro-allocations to allow that?
MR. CURRAN: Do you want to take it, Leslie, or -- if this policy proposal were to pass.
MS. NOBILE: Yeah. Actually we pointed out that this policy would not allow the transfer of /23s and /24s, and we see that as being a potential issue for the same reason. So I'm not exactly sure what we would do except we would have to deny those types of transfers because the policy said -- would say it, you know.
MR. DARTE: Yeah. The intent of what I put in there was, again, to reflect what I think we've heard, that deaggregation is a concern of the community and so, you know, quite frankly, it was pretty arbitrary on my part to say that the deaggregation into four pieces would be the limit and that each deaggregated element would not be allocated beyond what is current minimum allocation policy. That was the statement. That was the intent of that statement.
MS. NOBILE: I have one other thing, John, I'm sorry. Just so that you know, currently in transfers we see frequently /24s and /23s transferred under the current policy. That's very typical.
SPEAKER: Understood. So, go ahead.
MR. DARTE: Yeah, just to clarify. I was talking about blocks that are already old, swampy, Class C /24s. They're already there. /24s getting (off mike) /24s. They've already been assigned to /24s or allocated to /24s. Those would now not be allowed under this policy to be transferred. That's the interpretation.
MR. DARTE: Okay. If that's staff's interpretation, it certainly wasn't my intent to limit that. So, you know, as a first order of business, if the community thought that this past policy proposal needed to be amended in some way, that would seem like a really good idea.
MR. DeLONG: Owen DeLong, ARIN AC. I'm pretty sure the intent of the policy, as originally written, was not to limit the transfer of blocks that are already that small, but to limit the aggregation. And I would have no problem in the AC with adopting the minor change before last call. That would be necessary without changing the intent of the proposal to accommodate that issue.
MR. DARTE: It certainly was not my intent.
MR. CURRAN: Understood. Center rear mic. I am going to be closing the mics shortly. If you're speaking on this policy proposal, 2008-6, approach the microphones promptly. Center rear.
MR. FARMER: David Farmer, University of Minnesota. John, your comment about the board and that concerned me. And it's -- and this is my interpretation and I would love to be corrected, but the way I interpreted what you said was that there are two board holders that have legacy blocks and then, therefore, they could monetize that. If any board -- my view of any of the transfer proposals, any board members that have control of any address space in theory can monetize. There's nothing that restricts any of these proposals to legacy space. So if you would comment.
MR. CURRAN: Actually, conveniently, counsel's near a mic. Go, Steve.
MR. RYAN: So let me suggest that people use a link to read paragraph 12 of the conflict of interest provision in the bylaws. I believe it's Roman 7, but I didn't -- I apologize, I don't remember the articles. It's article 6 or 7 and paragraph 12. Paragraph 12 tries to describe the difference between an effect that everybody in the community has, which is I think what you're addressing, versus one that's particularized to them. Because otherwise, we'd get to the point that any routine action, if they have any involvement in IP numbers, they would have a problem.
So I think in the case of the board members who had legacy resources, several of them have also put their legacy resources under an LRSA.
So having put them under an LRSA voluntarily in the first wave, they've also changed fundamentally that nature in a way that I think has to be thought about.
These are very precise issues that I think, you know, maybe the board can come forward with a statement later on after they consider this so that people can do it, but I don't really think I want to delve much further in this room into the issue, except that we are all over this issue. It has been the subject of careful consideration. That bylaw provision was very carefully considered at the time it was adopted and we spent significant legal resources looking at models from other organizations and trying to describe it for here.
So I think the interest in the room has been received and reflected, but I think I'd like to deflect this discussion back into what the rules are and that as a way of going forward. And I think the board can maybe say something in the future about this.
MR. FARMER: I'm perfectly fine with that. I just wanted to -- I got a certain impression and I just couldn't let that certain impression stand.
MR. CURRAN: As the chairman I'm responsible for obviously when I see the potential calling it out if a individual board doesn't. The reason I mentioned the word "legacy" is that when we talk about a transfer policy, it is true the ability to readily benefit directly is more likely to occur with someone holding a legacy resource because the possibility that they have address space not in use. Whereas most of the assignments post- legacy are more best-fit to the application that they had.
Having said that, as Steve notes, almost everyone is an address holder. So we need to be a little careful lest we exclude the board and find the only person left in the room is Counsel.
SPEAKER: (off mike)
MR. CURRAN: I am closing the microphones. Approach the microphones very quickly if you're going to be speaking. Center rear.
SPEAKER: I have a question for Bill. How did you pick the number 4 as far as no more than 4 resultant number of blocks being greater than or equal to the allocation policy?
MR. DARTE: I wanted to address the issue of deaggregation in the policy and show that it was a consideration. It was pretty much arbitrary in my mind and it seemed like a good enough number to get started with.
SPEAKER: Then I have a follow-up question. If we're that worried about deaggregation, hell, why don't we say ARIN can't hand out more than four addresses from a /8? I mean, if ARIN can hand out up to 22 from a /8, what is the fundamental difference here with transfers?
MR. CURRAN: Okay, it's a good question. And I guess my -- given the policy proposal as it's stated with a limit of four, would you be for or against it?
SPEAKER: I would be against it.
MR. CURRAN: You would be against it, okay.
SPEAKER: But if the limit was stripped and just said strictly that it would be that the number of blocks have to be greater than or equal to a current minimum, I would be for it.
MR. CURRAN: Okay, understood. I'm closing the mics. Microphones are closed. Far right.
MR. SPRINGER: John Springer, Inland Telephone. I'm for the policy as stated or as amended and as amended to include /23s and /24s. I believe it's imperative that ARIN gets in front of the liberalized transfer policy.
MR. CURRAN: Thank you. Far left microphone.
MR. CASSIMIRE: Nigel Cassimire, CTU. I here Bill when he says the intent is not to create a market, although I see that it still possibly can. The three-year limit on it, which is a kind of review period, however, makes me, you know, somewhat neutral with respect to the policy as it is right now. I have a specific question, though.
In the wording of the policy it says, and you had it on your slide, but I'm not sure if you clarified it well enough for me to understand, it says without the active involvement of ARIN as an intermediary. However, later on it talks about signing an RSA with ARIN to cover the addresses to be acquired and documentation satisfactory to ARIN and so on. So that seems kind of conflicting to me that it seems that ARIN is involved. So, you know, if you could clarify that for me.
MR. CURRAN: I believe the intent is that the language "without ARIN as an intermediary" refers to if there were a consideration between the parties for result of the transfer, that that consideration goes directly between the parties and does not go through ARIN.
MR. DARTE: That's correct. The intent was just to say that ARIN would not be an active party in the transaction itself. It would -- it's only involvement would be to require an RSA up front demonstrating need on the recipient part and that it would account for that transfer and its records and make that public. That's the intent. And so we can strip that language entirely. That's a cosmetic issue I think.
MR. CASSIMIRE: Without compensation to ARIN or something (off mike).
MR. DARTE: Absolutely.
MR. CURRAN: Okay, thank you. Bill, thank you for the presentation.
MR. DARTE: Thanks. As a parting shot, though, I'd like to announce that Washington University, where I come from in St. Louis, has assigned a Legacy RSA for their /16.
SPEAKER: Hey, Bill.
SPEAKER: Here you go.
MR. DARTE: Thanks.
MR. CURRAN: Okay. In order that the Advisory Council can do their most interesting job, it comes time for us to have a show of hands of support for this policy proposal. So on Policy Proposal 2008-6, I'm going to ask for a show of hands for support. I'm first going to ask for everyone in favor and then everyone opposed. I'll first make sure my polling mechanism is in place and it is.
This show of hands is for everyone in the room and our electronic participants as well. On Policy Proposal 2008-6, Emergency Transfer Policy for IPv4/6 addresses, all those in favor raise your hands now. Nice and high. Okay, thank you.
Now I'm going to ask about those opposed. All those opposed to Policy Proposal 2008-6, please raise your hand now. Nice and high. It should go without saying, if you raised your hand earlier, you shouldn't be raising it now. (Laughter) Okay, thank you.
Okay. On the matter of Policy Proposal 2008-6, number participating, 129; all those in favor, 30; all those against, 18. This information will be provided to the Advisory Council for their consideration. Thank you.
MR. PLZAK: Okay. The next item on the agenda is the update report from LACNIC. Roque?
MR. GAGLIANO: Hello, everybody. My name is Roque Gagliano from LACNIC, and this is going to be the LACNIC report. I have 10 minutes.
So, I'm going to start with a nice graph, the low left, high right. This is our number of members and it has been increasing in the last year.
And you can see that most of the increase is in the small members. And also we -- in LACNIC have a special (off mike), which is a small micro. That means members then get a /21 allocation for the first allocation. So yeah, we increased.
The difference you see between '06 and '07 was because we started counting also the members from the NIRs, Brazil and Mexico. So it's nice to compare this year against last year because most of them in the same hypothesis.
This is our staff. And if you wonder, I'm on the right side in the middle, but maybe you can find me. So we have 19 people. We just hired actually two new staff members down here in the picture: Alexandra that is helping us in the communication department and particularly in a program that is called FRIDA. (off mike) going to be talking about that in a few minutes; and Paulo, who's helping us with the desktop support and other engineering activities.
So this is our -- the evolution of our income and expenses. We are keeping the organization in good health. We also have -- I guess everybody is aware of the issue with the value of the dollar and our regions. But in the last couple of weeks, we got actually good news because the dollar is appreciating itself, so that's good for us.
The last meeting we talked about the vision that was stated in our plan in 2007. So just reminding you of that, and I'm go through different things we are doing to enforce that vision.
So the first thing is the FRIDA program. I talk about the FRIDA program. It's basically a program that is run by LACNIC with also a contribution from IDRC from Canada and ISOC. These are small grants for the ICT sector. Basically we're talking about $13,000, $25,000 a year grant. And we are now in the second phase. And we're going -- the fund is going to have $650,000. And in total in the 4 years, we -- the fund has had more than $1 million. So 41 projects already funded and we just finished last August the calls for new projects. We received 110 proposals from 18 countries in the region. And that's very important for us.
When we talk about the government forums and LACNIC's been very active in the different government forums, particularly in the ones that has to do with the region. And especially we've been active in the forum that's called ELAC that is formed by all the governments in the OAS region. And they cannot state some goals for the following three years and we've been participating in those. And this one that has been particularly important for us actually was written by LACNIC and mentioned that the government will support the implementation of IPv6 and work on that path. And that was taken by the OAS, which is the Organization of American States, and particularly CITEL, which is a regulators' forum, and they also have a statement about that. So we're happy about that.
So what else are we doing for IPv6? Well, first of all, training and promotion. In training, we are part of the (off mike) project, so we are doing a lot of activities. Particularly we had already activities in Argentina, Brazil, Uruguay, Curacao, Colombia, Haiti, Costa Rica, and there's more activity going on this year and we're also planning activity for next year. What we are campaigning is we are trying to get one date in the head of everybody that the 1st of January, 2011, as a date they have to be ready for IPv6.
We also have an IPv6 portal and we came out with this statistics of the region and how they're moving to IPv6, trying to show how many (off mike) are originating IPv6, how many are just doing before, et cetera. And the interesting thing is that we are showing that per country. So every time we go to do the training in a country we can check what is happening with the allocations and the routing table for that country, how many -- we can show like in a simple way to a different stakeholder how the countries look in the adoption of the IPv6.
So this is particularly in Haiti where we had an activity. And it looks like during the time of the activity actually one of the locations they had was announced. Unfortunately, after we left, they had a problem with a couple of routers, so I believe some people were asking what happened with the people that stopped announcing. So we called and asked what happened to them and basically it was a memory problem in a router. But -- and the first thing they did is shutdown IPv6. But they told us for sure they're going to turn it on again once they solve that problem.
So, this is -- I don't know if all of you are aware of, but LACNIC only has one annual meeting. So we do only one general meeting a year, so it's a big event for us.The last one was in Salvador, in Brazil, and it was really, really good.
So as a report of that activity, we had 289 participants from 30 different countries. And we also do a lot of events during that, during our annual meeting, not just policy discussion, but we also have some Internet exchange point meetings. We do security forum. We do IPv6 training, also we do some IPv6 presentation. And all of that all together, so it's kind of like a get-together regional meeting. And this particular year we had an IPv4 deflation panel discussing also this kind of thing that you have been discussing here. So, for -- of the 289 attendees, 159 were the first time, so that's very interesting. That's very good for us, particularly going to Brazil then. You know, it's our second time there. And if you see the countries, nice stuff.
Let's talk about the policy (off mike) consensus there. What we had four policies and got consensus. Perhaps -- the government policy, it also got consensus in ARIN last year -- this year, early this year. And we had two (off mike) policies for IPv6. So how does this work?
Basically if you already have IPv4 PI space, you automatically qualify for IPv6 PI space. If you don't have IPv4 PI space, there's certain more requirements you need to fill in order to be able to get only IPv6 space without IPv4. So also, our interpretation on it: If you are a newcomer and want both, IPv4 and IPv6 PI space, we're going to evaluate first the v4. So if you qualify for v4, you automatically qualify for v6. And then finally, we also got consensus and actually was also -- all these policies were also ratified by the LACNIC board, so they've already been implemented.
The reservation policy is the reservation policy for new members. And this is basically LACNIC's going to reserve a /12 for every newcomer. And it only applies for ISPs on critical infrastructure and they'd only be able to get one allocation. And that allocation going to -- it has a size of I think it's /20 or /22. I am not sure about that. I'll have to read that.
So the other thing we approved is a new PDP, so we have -- first of all, we have a new public forum chair, which is Francisco Arias, but also we have a new policy development process. And here's the thing, we have only once a year meeting.
So every time we have a discussion of policy, we have a cycle of 12 months because we have to come back. In the old policy -- development process, we would have to come back to the meeting every 12 months. We have now a new policy development process where there's a new expedite process, where in certain particular and exceptional policies the policy can be approved without being presented in the public forum.
And also we have the figure of a co-chair, so now we have two chairs, not only one as we usually have. So more information in that link if you're interested.
For the first time this year we had a Caribbean subregional meeting in Curacao, and we had 70 participants. And we had other activities. It was a very nice opportunity for us to reach our Caribbean members. And we had policy discussion, but also we did a little bit of Internet exchange and (off mike) tutorial. That's something -- an IPVC tutorial.
We had another activity in Montevideo, and this activity was actually a preparation for the Internet governance forum. And this was a very different activity because we didn't invite members, but we invited the whole other stakeholders, like governments, social -- civil society organizations.
And we started a discussion in a casual way all the issues of the Internet governance and what's going to happen in India. And it was interesting to see all of this, you know, people who are not actually representing anybody, but just discussing openly all the issues. So it was very successful. We almost run out of space in the rooms and we got people from all of the region. And it was very, very interesting.
From the engineer department, we have updated our database. We have now an (off mike) contact for IP blocks. We used to have only (off mike) for ASN's. So now can see in our data, we also have (off mike) contact for the IP blocks. We are working on a new provisioning interface. We don't do SWIPs. In LACNIC we just have a web interface, but we are working in an automatic interface using EPB. We're also working in our business EA, (off mike) going to come alive before the end of the year. And we have a whole new infrastructure in Sao Paulo and the RPKI project.
So the last thing I have is an invitation for our next meeting, again, we only do once a year.
It's going to be in Panama City, which has direct flights from all major cities in the U.S., and big cities in and Europe.
And that's it. Thank you.
MR. PLZAK: Any questions? Okay. Thank you.
MS. HUGHES: I have a question.
MR. PLZAK: Yes.
MS. HUGHES: Is FRIDA an acronym and what does it stand for?
MR. GAGLIANO: Yeah, it's a Spanish acronym. You can see on the -- (Spanish) I don't know it by heart, but I know it's (Spanish), like regional found.
MR. PLZAK: Okay. FRIDA's FRIDA. Randy.
MR. BUSH: In fact, funding seemed to be the only content of it. What are any of the technical work in FRIDA? Somebody in the back of the room said it sounds like just a money-laundering operation.
MR. GAGLIANO: Well, I don't work in that area particularly. But there has been projects with civil society and also projects with particularly community networks and wireless projects. They're small grants, so they're not huge projects. But some of them have very interesting -- like bringing wireless projects in the rainforest in Colombia, et cetera. So some of that is very, very interesting.
And all the information is online, all the (off mike), all the reports. Because one of the things of the project is on the information has to be available. (off mike) has to be open. And I encourage everybody to go to the web page and check that it there.
MR. BUSH: Thank you. I thought the information (off mike) to be free (off mike).
SPEAKER: Thank you.
MR. PLZAK: Thanks, Roque. Okay. It's time for a break. Remember, the Cyber Café is upstairs, you can get connected. You can watch presentations. You can get information. I guess if you wanted to, you could even shake, shake, shake, shake your booty.
So, completely our survey card. Enter each -- enter a break -- a name will be drawn each break and you've got to be present either online or in person to win.
These are the hours and times remaining with the help desk. And so we will see you back here at 11:00 a.m. Thank you.
MR. PLZAK: Okay, welcome back. And I hope everybody had a good break. We did have a drawing. Some or other this may be considered to be TMI, but Ken West won an LED shower light. So --
SPEAKER: Yay, Ken.
MR. PLZAK: So, yay, Ken. Go, Ken. The first order of business is the update report from APNIC, and Paul Wilson will be doing that. Paul?
Oh, and he will stay up here then and very quickly do the NRO activities report.
MR. WILSON: Good morning. I am Paul Wilson from APNIC. I'm here in L.A. with several others from APNIC staff, with Sam, and Sanjaya, Geoff Huston, and Louise. So if any of you would like to meet some other APNIC staff, well, there's five of us here. Also, Akinori, who is the chair of the APNIC AC, and Ujisakisan, who is the recently appointed Number Council member for the APNIC region. So we are here in some force, taking a lot of interest in this meeting.
And I've got a short report of miscellaneous news from APNIC, for your interest. So coming up I've got some numbers, some updates on APNIC services, and some policy news because we've had a fairly active, like all the RIRs, a fairly active time recently in the policy space.
So here we are with the numbers. This is what our allocation figures look like up to just yesterday. Showing for -- in the top left, IPv4 allocations in /8 units. And you can see there that we're nearly, for 2008, nearly to the same level of allocations, just over four /8s, as we allocated in 2007. So we could expect that to rise a bit more by the end of the year.
The top right is IPv6 allocations in /32s. And that's interesting because it looks like those allocations have plummeted, and they have in terms of the total amount of space allocated. And that's because of our change to the policy which -- well, two changes. One is that allocations that -- customer assignments can be made in anything from a /56 to a /48. And also that the HD ratio has changed to.94 from.8. So you can see that's had a huge impact on the amount of v6 space allocated.
Below that in pink is the total number of allocations. And the total number of allocations is climbing quite rapidly. But I think those charts do reveal that the rumor or the myth that you hear often about v6 space in the Asia-Pacific region really isn't true. We really haven't been doing anything outstandingly amazing in the Asia-Pacific in terms of the total amount of v6 space allocated.
Not so far, anyway. The bottom left is the AS numbers. And we really allocate ASNs really quite slowly in our region, for reasons I think we haven't really investigated. But compared with the other RIRs, we don't allocate too many of them, at all. So, those are the numbers.
There are a few items here about APNIC services. And related to that issue of v4 requests is that we are seeing increasing, large requests coming in. Our allocation rates have been going up rapidly for 3G networks, for DSL networks, for quite a few projects in replacing private and public IP addresses. And so we adopted an internal escalation procedure in 2008 which just adds a bit of extra review to allocation requests involving -- well, either formally reviewed by peer hostmasters at a /19 level, up to the regional services manager at a /17 level, and larger than /15s go to a senior review team. And that's really some internal auditing and quality control, to make sure that as APNIC's allocations have been increasing, that we're exercising real consistency and so on in how those requests are being dealt with.
Okay. MyAPNIC is the APNIC member services portal. We've released a beta of v2 of MyAPNIC and the main changes there are that we've streamlined the authentication to allow user name and password access for low-privilege functions. So, we do require certificate authentication and authorization for voting and for resource certification through MyAPNIC, but there's password access, as well. In addition, major changes or major improvements and extensions in MyAPNIC involve the resource certification functions. So those functions are now live in this beta version, which will go into full production in the fairly near future. But through that service which is active now in spite of being beta, you can use the resource certification functions which may not have been under development at APNIC for some years now.
So collection management, in accordance with RFC-3779, certificate formats, and also generating your ROAs, your route origin authorizations. And that's just a screen grab, for what it's worth, showing that it is a real feature now in MyAPNIC v2.
So anyone who's interested in having a demo or seeing more of that would be most welcome to approach myself, or probably betterGeoff Huston, sometime during the day today.
Okay. Also in Geoff's area of R&D, as I said, the resource certification work, the designing, the testing, the standards work around that has been a really active area of R&D for some time now. There have been eight drafts produced by APNIC staff and the IETF CIDR working group, and we are going on not only launching the MyAPNIC functionality for resource certification, but going on to deliver more functionality in future. So, in the next few, we'll have hosted services there that allow the ISPs to manage downstream certificates corresponding to customer assignments and so on.
Other R&D tasks included participation in the Day of the Life of the Internet 2008 with CAIDA.
We fed them 50 terabytes of data from our DNS servers in Hong Kong, Japan, and Australia. We're also getting involved with RIPE NCC on their TTM network in deploying -- planning to start deploying TTM boxes around our region so that that can help to build that network of traffic measurement devices. We've just deployed one node, but it's the first of several that are currently in planning now.
Okay. In other news, from the secretariat we're -- these are just a number of miscellaneous items that I think might be of interest. We're involved in a business continuity planning project that's coming to an end this year. So that will produce a formalized BCP document for, you know, obviously for how we will handle any disasters, interruptions to service of various kinds.
We're involved now in launching a member survey, the next member survey in our regular series every two years. And that's under preparation now for launch before the end of this year.
The other thing that KPMG is involved with, with us, is the study into the APNIC fee structure. And this is something that's been going on for some time. We're now using KPMG to do a formal study into a bunch of the different aspects of the APNIC fee structure, including the business sustainability of the current structure and what other models are out there and what -- how they might be -- they might perform in various contingencies that are coming along in future, not least the exhaustion of IPv4 address space and the changes in our business functioning from that perspective.
We received and are in the process of going through a local EcoBIZ accreditation that's part of the EcoAPNIC Project that has been going on for some time.
We have an active, now defined IPv6 program of activities which is being developed and which will be rolled out more in the coming year.
We've got a CMS, Content Management Service, in development and due for deployment by the early part of next year.
And rather like the FRIDA Program that the (off mike) reported on, APNIC is involved in something similar called ISIF, which is the Information Society Innovation Fund. And that's, also, is something that's supported by the Canadian Development Agency, IDIC. And APNIC has been a contributor to similar programs for some time, but in this case, we are also receiving some funds to actually run and host the program on behalf of the partners, IDRC and others. And we're involved with that with both IDRC, ISOC, and the.Asia Group.
Okay. I want to give you a bit of detail about what's been happening in the policy space at APNIC. Since our last meeting, APNIC 25, we have implemented three policies that were approved at that meeting. And probably the most interesting being that our IPv4 minimum allocation is now a /22.
There were a couple of other policies. One relating to NIR operations of reverse DNS, and the other relating to the clarification of initial allocations for IPv6 that I'd say is sort of a more minor interest, I'd say.
We had two proposals which were presented at APNIC 25 which came back to APNIC 26. And so APNIC 26, which was held just recently in Christchurch, was a very active meeting, with not only the two previous proposals, but seven new proposals. And six of them in total were approved.
And under the APNIC policy development process, those approved policies are under discussion for an eight-week period which ends on the 24th of October.
So quite soon now we will have the final consensus of agreement on those policies, hopefully, and they would go on to implementation after that.
So I'll go into the details of those policies, but there is a URL on the screen there, I will say for anyone who wants to look at the full log and details of the policies, which are available on the site there.
Okay. So, the one that there has been a lot of discussion on, because this has come to our meeting for discussion for several meetings running, is Proposal Number 50, which is IPv4 address transfers. And I think we've heard a fair bit this morning about that, including Geoff's explanation. It's a fairly liberal, let's say, IPv4 transfer policy proposal, allowing any transfers to happen down to a size of /24, with the requirements only that they be in APNIC-administered ranges, and also that they be considered to be subject to APNIC policies. The source of the transfer being ineligible to receive more addresses from APNIC for 24 months. And that policy did actually go to a vote for the first time at this meeting. And it was -- consensus wasn't reached. But there was, as I recall, about equal support and opposition for the proposal in our community. So, it's gone back to the SIG for further discussion. When a policy proposal is not -- where a consensus is not reached, under our procedures the policy can either be abandoned or sent back for further discussion. And it was, in this case, sent back for further discussion.
Okay. Two more policies here related to the exhaustion of IPv4 address space. The first is Proposal 55, which is the global policy for allocation of remaining IPv4 space. That's the proposal that's now been around all of the RIRs and it's been approved now at all five. So, pending the final steps in the APNIC process, that would be going on for ratification through the ASO procedures. But that is the policy that whereby the IANA will be asked to reserve one /8 for each of the RIRs and to distribute those to the RIRs when the IANA pool is finally exhausted.
Now, we also had a related policy proposal, number 62, which was to document -- or which was to detail how that final /8 would actually be used when it was received. And the idea of that policy proposal, which has again been approved, is that that final /8 will be reserved and allocated only in minimum allocation-sized blocks. Where each new LIR or member that comes to APNIC will receive one of those minimum allocation-sized blocks, and any existing LIR can also apply to receive one of those blocks. So, it will be the /22, assuming /22 actually is still the minimum allocation at that time, or that /22 would be both the minimum and the maximum allocation to be made out of that final /8 block. There is a small reservation of a /16 also included in that policy which is reserved for possible future technologies that may need small numbers of IPv4 addresses. And so that, again, was approved by consensus at the meeting.
Okay. A couple of proposals, again, approved by consensus at the meeting relating to IPv4 allocation practices. There's -- I'm sorry, this first was not approved by consensus. It was again returned to SIG for further discussion. But it's a proposal to reduce the timeframe of v4 allocations from a 12-month to a 6-month window.
The second one here, which was approved, was simply that historical resources, legacy resources, so-called, be included in the evaluation of an LIR's demonstrated requirements and usage rate. So, we had not previously actually taken historical resources into account in the request process, but we will now be doing that some from the time of the final acceptance of this policy.
We had three policies at the last meeting relating to AS numbers. The first of these was a proposal to reserve a number of 32-bit AS number blocks for documentation purposes. That was approved by consensus at the meeting. The next one here is the format for delegation or recording of 32-bit AS numbers. And that was a proposal to adopt the so-called ASPLAIN format which is that 32-bit AS numbers should simply be expressed as integers and not in the 16-bit.16-bit notation.
Now, both of these have been under some discussions since the meeting because there are some opinions that these topics should be addressed by the IETF and not through any RIR policy process. And it does appear that there are drafts which may be passed through the IETF process in due course or quite quickly. And therefore, I think, I gather that there is some question and possibility of these actually being withdrawn by the authors before the end of the comment period.
The final AS number related proposal here was just simply an extra addition to the current schedule that we have for deployment of 32-bit AS numbers, which is that from the middle of 2009, APNIC will be assigning 32-bit numbers by default and 16-bit numbers only where a specific need for those numbers is demonstrated.
Okay. So that's a summary now of the particular policy issues that came up at the last meeting. As I said, six of those policies have been approved by the consensus at that meeting. If anyone would like to participate in the discussion, the final discussion period is still open until the 24th of October. So, you're welcome to go onto the APNIC site and have a look for those discussions, and have a look through that -- those policies.
Okay, finally, APNIC meetings coming up. We've got three meetings which are scheduled. The first one being APNIC 27 which will be in Manila in the Philippines next year. As usual, the first meeting of the year is held with APRICOT, which is the Regional Operators Conference. And that's in February 2009. The next one will be in Beijing, APNIC 28, in September 2009. And the one after that will be in K.L. in Malaysia, March 2010, again with APRICOT 2010. So, I would be very happy to see all of you or any of you join us at any of those meetings. And please, feel free to come along. Thanks.
And that's all I have to say on APNIC.
SPEAKER: Any questions for Paul?
SPEAKER: Question down here.
MS. ARONSON: Hi. Cathy Aronson. I just wondered, we talked at the open policy, or Leslie talked about 32-bit ASNs and how a lot of people come and get them, and then find out they can't use them. And I wondered what your experience -- you know, whether you're looking to change the policy so that it's delayed or --
MR. WILSON: I don't have the figures, but we did report at the last, at our last meeting that yes, in fact, people do ask for 32-bit numbers. Maybe they sound better, I don't know. But they sort of ask for them and agree to take them and then find that they can't use them. And have sent -- have returned them in numerous cases. So, we have the same issue. There was some discussion about extending the deadline, but there's also the fact that the exhaustion of 16-bit numbers is approaching and there's not a consensus or particular proposal to extend the deadline.
SPEAKER: So, Paul, you want some used 16- bit numbers?
MR. WILSON: I think we've got enough, thanks.
SPEAKER: Because the 32-bit ASs work just fine for me.
SPEAKER: Any other questions for Paul? Go ahead.
MS. HUGHES: Hi. Stacy Hughes. What kind of documentation? Like, why would you need to save a block for documentation purposes? What are we documenting?
MR. WILSON: I think the point there is that in any sort of documentation about, for instance, how you might use 32-bit AS numbers that anyone might want to write, it is useful to have examples. And it is often found that if the examples contain real numbers that are in operation, then often the people reading the documentation tend to use those numbers, and it's better to reserve numbers that won't be allocated to anyone else.
And we did in fact make an allocation or a reservation for that purpose from IPv6 address space. And so we had something of a precedent for making that kind of reservation out of APNIC resources. But there is also this debate about whether or not that's appropriate and should be left to those such as IETF to make those decisions.
SPEAKER: I always used AS1, but not everyone felt comfortable with that.
SPEAKER: Thank you, Paul.
MR. WILSON: I'll change hats now.
SPEAKER: Oh, yeah.
MR. WILSON: And --
SPEAKER: You have the NRO hat.
MR. WILSON: Yep, put on the NRO hat. So, the next report is a report about activities of the Number Resource Organization over the last period. And I am presenting that as the chair of the NRO for the year of 2008, or the chair of the NRO Executive Council, that is.
Okay. So, for those who need a reminder, and there may be some newcomers here who don't know the story, what is the NRO? The Number Resource Organization is a vehicle that was established for cooperation among the RIRs and for representation of RIR interests, formed formally for the purposes of protecting the unallocated number resource pool, for promoting and protecting the bottom-up policy development process, and for acting as a focal point for Internet community input into the RIR system.
So, one of the first tasks of the NRO in its role of representing the RIRs collectively was to establish an agreement with ICANN for the formation of the address supporting organization, which is a unit or a component within the ICANN structure that deals with global policies in the area of Internet addressing. So that's been around since October 2004.
Okay. The NRO has got an Executive Council which is comprised of the CEOs of all of the RIRs, and the current officeholders, and myself, as chair, Adiel as secretary -- that making AFRINIC, Adiel's organization, the secretariat of the NRO this year -- and Axel has been the treasurer this year. We rotate these positions every year. So, next year the chair will be Adiel, the secretary Axel, and the treasurer will be Raul. (off mike) myself being relieved of officeholder positions for that year.
Okay. Within the ICANN framework the NRO is responsible for making what we call voluntary contributions to ICANN. Those contributions are treated as a shared expense that are split among the RIRs by a weighted formula which depends on revenue and resources of each of the RIRs and the respective splits of responsibility given here on the slide. The contribution that the NRO is making to ICANN in this year was a total of $823,000 USD and that's, in fact, just been paid to ICANN in the last week or so. So the respective shares of that contribution are according to those percentages, but those percentages also apply to our respective shares of various other expenses that we incur in things like promotional activities, which I will mention.
We play quite an important role or prominent role in ICANN meetings. Particularly in Paris in the last ICANN meeting in February, we were involved with a consultation with the Government Advisory Committee, which is a fairly regular thing these days. There were workshops by the at-large Advisory Group on IPv6 transition. There was also a workshop on IPv6 for DNS registries and ccTLDs. So we go along to the ICANN meetings to provide input on IP addressing and related issues on behalf of the RIRs. Excuse me.
The next ICANN meeting we actually don't have anything formal planned. That's coming up quite soon in Cairo. But in Mexico in March of next year, we have been asked to come along for a fairly substantial consultation with the Government Advisory Committee again about -- particularly about, we expect, IPv6 issues.
We played a role in the OECD meeting, the meeting that happened in Seoul in June this year, which was a quite major meeting. It's the sort of meeting that happens only every 10 years. And this one was about the future of the Internet economy. So we joined together with various other members of the Internet technical community. So I called people like ISOC and W3C and ETSI, and put together some communiqués and participated in that meeting. The NRO itself also made a release appealing for further investment in IPv6 in connection with that OECD meeting.
The Internet Governance Forum is the latest incarnation of the whole extended WSIS process, the World Summit on Information Society. And we've been involved right through that process in representing the interests of the RIRs and the members of the RIRs. And we've been -- our involvement has been recognized quite strongly, for instance with the appointment of a couple of the NRO EC members, RIR CEOs, to the Multi-Stakeholder Advisory Group of the IGF. And so Raul and Adiel have again been reappointed to that Multi- Stakeholder Advisory Group. And that's good evidence of the hard work and the good work that they're doing in that function.
The next meeting of the IGF is in Hyderabad in India in December. And we'll be mounting another NRO display with promotional materials and media rooms and press activities, which has became quite an important component of our participation in these events. There are also numerous workshops going on at the IGF about issues which are in some cases directly related to our responsibilities. So we will be contributing to workshops about -- again, of course, about IP addressing and IPv6 related matters.
Okay, ongoing activities in this year, and I expect into the next year. ICANN meetings, IGF, OECD, the ITU Telecom events of these large, quite commercial telecom conference events that the NRO has also participated in.
We've got, on the internal side, an engineering coordination amongst the RIRs through the NRO. And those -- the Engineering Coordination Group is looking at a timeline for v6 support by the RIRs, including the ip6.arpa delegation planning, DNSSEC planning, and also the coordination of resource certification activities around RIRs.
There have also been, at the board level of the RIRs through the NRO, a number of meetings of informal gatherings of RIR board members. And they've been really informal gatherings, although there has been a proposal for -- to turn these into more formal teleconference meetings. But so far, the gatherings have been informal, talking about topics such as the exhaustion of IPv4 and the respective RIR approaches to that; the issues of management of the IPv4 legacy address space; transition to IPv6, of course; and the ongoing question of whether the NRO, which is currently not incorporated, should incorporate to become a more legally substantial body to take on the activities, the responsibilities that it has.
And that's all I have got to report from the NRO.
MR. CURRAN: Okay. Thank you again, Paul. Questions for Paul on the NRO report? Okay, thanks very much.
MR. PLZAK: Now we have a report -- excuse me -- from IAB/IETF, their activities, and it will be presented by Marla.
MS. AZINGER: You have to excuse my voice; it's a little rough this week here.
I'm Marla Azinger. And Thomas Narten is not here, but he is who also -- he put these slides together and then I add commentary, so it is a joint effort. So thank you, Thomas, if you're watching. But he's not here.
So you know the presentation is not an official IETF report. There is no official IETF liaison to ARIN or any RIR. However, it's believed to be accurate. And errors are the sole responsibility of Thomas and myself.
Routing and addressing. Overall, little change since ARIN's 21 meeting, but work on individual efforts continue. The problem statement that the routing addressing directorate was working on has come to a standstill, basically because we were able to get past the fact that people really wanted a problem statement and they are all working on solutions now. And it was really hard to get people to agree on what really the problem was because everybody was on different -- there were different sides of the coin. They were all kind of valid. But, therefore we couldn't agree. So it went to a standstill.
Charters and pointers can be found at that -- this URL on this page. And nine proposals at present. And that's what I'm talking about. There's a lot in routing and addressing that is actually being worked on now, solution-wise. And there are multiple sessions at the IETF meetings now for this one group because there are so many things being worked on. They did publish a report from the IAB workshop on routing and addressing.
IPv6 maintenance working group. The new working group document is "Handling of Overlapping IPv6 Fragments." And there are four active documents. And attention is being given to only use recommendations if there is not a technical reason why they said a specific thing. And this is regarding to subnet sizes and things like addressing where it is involved in how you break down things in your network.
IPv6/IPv4 translation/NAT approaches. An interim meeting was held in Montreal because we had a lot of activity in Dublin and we found out that there were also many groups that wanted to be involved, not just one, such as SOFTWIRE, V6OPS, BEHAVE, and INTAREA. So they got together and worked a lot on the IPv6 and IPv4 translation scenarios and that related translation approaches. There's a lot of debate going on about this and the fundamentals and the truth of the technical barriers. But they are working through it.
Meetings on specific topics are expected in Minneapolis. And charters to take on work in specific working groups are expected soon. This is a little difficult for them to decide because so many people, different groups are involved. And they all feel like they have a piece in it. So there is a little bit of discussion going on as to exactly who will be taking what documents. But that should be decided at least in Minneapolis, if not before.
IPv6 operations working group. There are four new documents. The fourth one on the page, there's a debate on keeping this technical and not running into RIR policy. There tends to be that occurring at IETF now and again, where they try to get into the RIR end of it and not just stick to the technicalities. There are also two active documents. There is one document in the editor queue, "IPv6 Unicast Address Assignment Considerations." And then there are three recent RFCs published.
Shim6. There is little change since the last ARIN conference. There are three active documents, and IESG is processing through documents, and there is one in the RFC editing queue.
Softwire. "Dual-stack lite broadband deployments post IPv6 exhaustion" is now in our charter and it's become a large part of IETF discussions. There are seven active documents right now.
DNS operations. There is one new -- or two new working group documents, excuse me, and five active documents. One in the RFC editing queue, which is an interesting and good document to have, that you might want to take a look at if you are in DNS.
DNS extension. One new document. Five active documents. DNS is a little busy right now.
Continued. Two active documents. And if you want to be involved and you have real world experience with this, right now is a good time to actually get into the DNS extensions. Because they have a few active documents and it's involving real world experience and it's getting documented. So if that's you, please get involved.
Operational security capabilities for IP networks. There is one new working group document and then there is one active document. And again, it's real world experience that's needed in this document. So if that's you, please go read it and get involved.
Excuse me. Secure inter-domain routing. There are two new working group documents and there are nine active documents. If you want to see them get accepted, you need to get involved. When you have this many, they fall off the table. So if there is anything in this list -- there is a second page because there are so many, there's nine. So go in and look at those. If you actually like one of those that you see, get on the list and start talking about it so it doesn't get dropped.
Grow. There is one active document. And there are new working groups created.
There's NETCONF Data Modeling Language, and it's modeling language for use with NETCONF protocol. And then there's Internationalized Domain Names in Applications, the working of your group is to finish revising IDNA work. Source Address Validation Improvements. They verify source addresses of packets on the originating link.
Next one is in Minneapolis, November 16th though the 21st. And there's a WIKI that summarizes recent and upcoming BOF activities, which is on this slide, and then it'll include early topics that might or might not eventually result in a BOF. If you do want it to result in a BOF, again, get involved on the mailing list. And officially approved BoFs, once known, are posted at this link.
I went through these fast; I was asked to make up time. So, hopefully that's okay.
Are there any questions?
MR. CURRAN: Questions on the IETF report? Thank you, Marla.
MS. AZINGER: You're welcome.
MR. PLZAK: Thanks, Marla.
MR. PLZAK: Now we'll move on to Policy Proposal 2008-5. This is a policy entitled "Dedicated IPv4 Block to Facilitate IPv6 Deployment," introduced in June this year, discussed at one policy meeting so far, and that was the one in Nassau. A similar proposal in the APNIC region is in last call. And in the LACNIC region it has been adopted.
What this does is it designates a /10 from ARIN's last /8 to be used to facilitate immediate IPv6 deployment, things such as dual stack servers, NAT-PT, NAT646, and so forth. Prefix size would be a 28 through a 24 allocations and assignments. And you can get one prefix every six months.
Shepherds are Owen and Matt. No liability risk from the Council. Staff's got some comments and issues.
Unclear about the supply timeframe. Is it 30 days? Six months? They must be members in good standing of ARIN. That's not needed. ARIN will continue to issue resources only to organizations that have paid their bills. And will affect DNS operations for independent allocations made that are longer than a /24.
And from a resource impact, it's going to require some software template changes. So, we're saying a moderate implementation time, 120 to 180 days.
Some discussion on the list. I'll let you read the comments. Again, you can go to the archives and read them all.
And I would like to ask Alain to come up and present the proposal.
MR. DURAND: Good morning. My name is Alain Durand. I would like to talk about this Policy Proposal 2008-5.
So the overview is, when ARIN will receive the last /8 allocation from IANA, there were questions about what are we going to do with it? So, this is one attempt at answering this question.
So, the policy says that at that time, a contiguous /10 will be put aside and will be reserved to help facilitate IPv6 deployment. So (off mike) essentially, if you want some addresses from that block, you will have to justify how it's going to help you to deploy IPv6.
So we have provided some examples, like if you need to have a DNS (off mike) that is reachable for IPv4, as recommended by (off mike) RFC, you need a v4 address. So that's a clear example of what could be acceptable. If you have some kind of NAT, (off mike) NAT servers, being a NAT-PT, NAT64, dual stack lite, or -- 464 was the old name of dual stack lite, by the way -- all of this is going to require a small amount of IPv4 addresses to enable you to deploy an IPv6 server.
The least of those things is on purpose left loosely defined. And this is because we may come up six months from now, a year from now, with some new things that require a little bit of IPv4 addresses to deploy IPv6. On your own, when you deploy this network, you may come up with some usage that nobody had been thinking about, but may be perfectly appropriate. So we would like to leave the ARIN staff in a position to evaluate for justifications that people will put in to request space under that policy.
So, some of the details of this policy. Minimum size is a 28; maximum size is a 24. So both are really small blocks. We are not talking about, oh, you are going to get a 60 (off mike) block. You will get a maximum of once every six months. So you can come back. That's one of the differences with the policy that has been accepted in -- on discussing. In the APNIC regions, you get one /22 and then that's it. Yeah, you can come back several times.
One of the side notes is that you may have to renumber, so we are suggesting that we use a sparser location to avoid this. But there might be a case where down the road you have already had gotten a /24 and you get another one where the staff may say, yeah, but it would be really better if we would give you a contiguous /23. So, you have to return your old /24 so as to preserve routing table size. This is really last resort space. This is not space where you can say, oh, we (off mike) number. Like the tradeoff has to be, no, we really need to conserve the space and make sure that routing tables do not get out of control.
So, a number of comments were received. So I'm going to address all of those that I have tracked. Staff made some comments. So, first comment was, I was supposed to allocate or issue a 30-day supply or 6-month supply.
This (off mike) a six-month supply, may not have been clear in the policy proposal, but that's really the intent, you get six months.
The policy proposal refers to the end assignment policy in terms of what is the utilization percentage ratio that you need to satisfy before getting something new. And staff made a comment, maybe we wanted to hardcode this to 80 percent. And our intent was just not to hardcode it because if the community decides that 80 percent is not a reasonable value anymore, we need to go to 90 percent efficiency, it should also apply to this policy. There should be no exceptions. So that's why we wanted to have a reference rather than hard coding a number here.
And there was a very good comment about membership. Membership is not required (off mike) you get resources from ARIN. That's just an oversight on my side. So we don't want to change anything in here.
Another batch of comments. This came during the Caribbean meeting. And there was a question of should this be implemented now or should we wait until the last /8? I will have no real problem to get this implemented now. But if we do so, when we have again the question, what are we going to do with the last /8? And this entire proposal was initially to say let's provide some visibility on what's going to happen in the last /8.
So if we implement it now, we may lose something. There was a question about do we need a contiguous block or can we get away with something different? Well, the reason why we need a contiguous block is because we are allocating up to a /28 and we have to have an easy way to identify in your prefix list. In that particular block, you may receive some prefixes longer than 24. So it doesn't really have to be only one /10, it could be two /11 or four /12. But what we really don't want is to have, like, 200 blocks (off mike) address base is coming from. So a few number of blocks could simply do the trick. However, finding a contiguous /10 is not that hard. So maybe for the sake of simplicity, that is the right thing to do.
And one of the most important comments that I received was is that big enough? Is it just not too small, the /10? Well, so I asked staff about some data, how many new orgs are joining ARIN every year? And apparently we had 3,000 new orgs in the last two years, so that's 1,500 a year. So,this base here (off mike) to -- for the long run. Because even if we've transitioned most everything to IPv6, there will still be some little need for v4. So we have to think about a 10-year horizon here. So 1,500 organizations a year times 10 years is 15,000. Now, let's say that everybody in the end got a 24 under that policy. A 24 from a /10 (off mike) 14 bits. And 14 bits is 16,000. So we are right there at the limit, 15,000 new orgs, 16,000 potential candidates in the year.
So, I read this as maybe (off mike) the /10 is a little small, but we may want to simply go with the /10 now to really provide the direction, and maybe later on next year update this policy and say, yeah, maybe we need something bigger than the 10. And have a discussion about what will be the appropriate size. Should it be a 9? Should it be a 9.5? Or 8.5? Or should it be a 10? Something like that. But right now, the proposal as it is, is with a /10. So, I think that's my last slide.
MR. CURRAN: Okay. Any questions on the proposal? Microphones are open.
MR. BICKNELL: Leo Bicknell, ARIN AC IFC. I'm certainly in support of the concept of the proposal. And I believe I could support it as it's written. The perspective that I have because I respect your opinion on why it should be from the last /8, to counter that I actually think, assuming it did not mess up ARIN's relationship with IANA because I am not sure how they would count this, if we could allocate it from the next block where we can get a contiguous /10, whether that's a current one or the next one ARIN gets, that would be preferable. Because since we are going down to /28s here, it is likely most people will have to update their filters to make that work. And so if we can tell people today, this is what your filter needs to look like, and have a year or two or three of being able to evangelize that, I think we stand a much better chance of this actually working, day one.
So I would support for that reason, having the block be set aside right now. I think your perspective is equally valid, so, I mean, it's a tough call.
MR. DURAND: Let me answer this one. The current policy does not say that a /10 has to come out of the last /8. It left it to the staff to decide where the /10 is coming from. The policy says that this block would be open when the last /8 is coming from IANA. So you could actually say we are going to take it from another block identified today and answer your (off mike). But only make it active when the last /8 is received from IANA.
MR. BICKNELL: I think that would be perfect.
SPEAKER: Okay, thank you. Center rear mic.
MR. POUNSETT: Matt Pounsett, CIRA and the ARIN AC.
I am in favor of this proposal and would support it as written. I'd also probably support it if the reservation was a little larger, but not a lot larger. I have to think about numbers a little bit.
I actually have a clarification question for staff about the staff comments. The fourth note about DNS, is that -- I just want to make sure I understand -- is that just talking about the complexity of ARIN managing its own ARPA zones?
SPEAKER: So, either Leslie or Mark can answer that question.
MR. POUNSETT: Leslie or Mark, yeah.
SPEAKER: We'll hunt down Mark and get him for you.
MR. POUNSETT: Okay.
MR. CURRAN: Actually, I think he's over there. So, Matt, could you repeat the question?
SPEAKER: Mark, find a microphone.
MR. POUNSETT: Sure. The fourth note about this making DNS complex or difficult to manage, is that just referring to ARIN managing its own ARPA zones? Or were you thinking about something else there?
MR. KOSTERS: Can we put up the comments on the screen? So, the comment is when you get over to, like, a /28, obviously you're (off mike) boundary.
MR. POUNSETT: Yep.
MR. KOSTERS: And so you have to do something like a (off mike) hack or something like that.
MR. POUNSETT: Yeah, yeah. I just wanted to make sure that that was all it was.
MR. KOSTERS: So, in that sense it's not really all that complex, it's just a difference in numbers.
MR. POUNSETT: Right, okay.
MR. CURRAN: Okay. Far right mic.
MR. DeLONG: Owen DeLong, ARIN AC. I support the policy as written. I am not sure what Matt would consider a little larger; /10 is 4 million, roughly, addresses. The next step up would be a 9; it'd 8 million addresses. And the next step beyond that would be an 8, which would be 16.7 million addresses. I think that a /8 would probably be a more appropriate size for this, but, you know, the /10 is certainly better than current policy. The sooner we determine which block this is going to come out of by whatever mechanism that determination is made, I think, the better. I don't know whether it's a good idea to delay implementation of this block for this purpose until IANA free-pool exhaustion or not. I'm inclined to believe it probably is, but there could be counterpoints.
MR. CURRAN: Okay. Center rear mic.
MR. WILLIAMSON: David Williamson, TellMe Networks.
I am in favor of the policy as written. I am not really keen on the timing of wait until the IANA free-pool is exhausted. It seems to me that if you have an environment where you want to run, like, DS-lite or one of the other transition mechanisms you described, if you wanted to do that before the free-pool ran out, you would have to either lie your way into a 22, which we should obviously not encourage, or wait. And if all you really need is a 28, why force people to wait until some more or less magical time in the future? I would rather see that, you know, 10 allocated sooner than make -- I think the purpose in mind is great, and I think we should actually encourage that faster rather than waiting for an arbitrary time.
MR. CURRAN: Okay. Center front.
MR. FARMER: David Farmer, University of Minnesota. I'm in support of the proposal, probably even as written.
I just had a question or a clarification. Is the intent that someone who is requesting to use this block only be granted allocations if they don't have any other IPv4 address space? Or only if they don't have any address space available? In other words, if I have my own chunk of addresses over here in the corner, can I get some of this for this purpose? For the specified purpose? Or do I have to use my other stuff?
MR. DURAND: The 80 percent rule applies. So you have to justify why you cannot use your other address space that is sitting somewhere.
MR. FARMER: Okay.
MR. CURRAN: Microphones remain open. Any other questions?
SPEAKER: (off mike). Not a question, just a comment that says this week we have used a final /8 (off mike) proposal (off mike).
MR. RHETT: Jo Rhett, Silicon Valley Colo, in favor of the proposal as written, but would recommend that we don't wait until the last /8 date.
It seems an arbitrary --
MR. CURRAN: Okay. Any other comments on the proposal? Anyone in favor? Anyone against? Want to speak on that? Okay. Thank you, everyone. Thank you, Alain.
MR. CURRAN: So, once again I'm up here because (off mike) to provide some guidance to the Advisory Council in doing their mission. And that means we are going to ask for a show of hands on Policy Proposal 2008-5. We're first going to ask for a show of hands in favor, and then a show of hands opposed. So I will wait for my polling machinery to get in place. Very good.
So, on Policy Proposal 2008-5, Dedicated IPv4 Block to Facilitate IPv6 Deployment, all in favor, raise your hands now. Nice and high. Nice and high. If you do this right, I will reward you with lunch.
Thank you. On Policy Proposal 2008-5, all those opposed, raise your hand now. Raise your hand really high. Okay. We're doing the tabulation. Need one of those old-style ENIAC computer background noises, you know. Click, click, click, whir, click, click, click.
On the matter of Policy Proposal 2008-5, number of participants, 129. In favor, 55. Against, 0. This information will be provided to the Advisory Council for their consideration. Thank you.
Back to you, Ray.
MR. PLZAK: Thank you, John. And so now John said we were going to reward you with lunch; that's noble.
And if I get some slides. Remember, the Cyber Café will be open again this -- it's open right now, really, for that matter; it's open all day. But you can take a break there any time.
Remember, we'll do one more survey drawing this afternoon yet, and you have to be present to win.
The help desk hours, our help desks are all still open.
Remember, you can find the AC at lunch. They will have the balloons with them. They are here for you. Seriously, they really are. They really appreciate your input. It is very valuable to them as they go through and do the deliberations, trying to determine the consensus on each of these proposals.
So, let's again thank our sponsors, CGR and Los Nettos.
MR. PLZAK: And this is definitely not (off mike). There is no security in this room. Take your valuables with you. This general session room is not locked and there is no security person present.
So, see you back here at 1:30.
MR. PLZAK: Good afternoon. The splash screen, please. Thank you.
Good afternoon. Before we get started on this afternoon's agenda, we have a special announcement to make. And so Bill, if you'd come up to the mike please?
MR. MANNING: So, yesterday we talked a little bit about -- or, actually yesterday morning there were the Friends of Jon's panel. Anybody remember that panel? Okay. You didn't drink too much or play too much last night.
Anybody remember Jon Postel? How many people worked with or for Jon? Stand up. You can count that, right?
SPEAKER: I can count that.
MR. MANNING: All right. So, there's a few of us still that remember Jon. And, we heard a lot of interesting and fun stuff about Jon. Or not, as the case may be.
But one of the things that we remember about Jon was that Jon had a sense of humor. And since this is the anniversary of his death, and this is what we did to remember him, was Jon had fun.
SPEAKER: Do you need a mike?
SPEAKER: No, I can just yell. Let's just remember, always take the work seriously, not so much take ourselves seriously.
MR. PLZAK: Okay, thanks. Okay. So an ominous-looking movie poster from All Silent on the Western Front. The secure web login demo will take place after the meeting. We've implemented a secure login feature on our website, so if you stick around afterwards you get a brief demonstration on creating an account, linking to existing points of contact and managing some of the information.
John will be enforcing these rules. And head table, we see John, RS and Paul's head is now popping up and Suzanne. One of the Bills. Scott will man the virtual mike and I will be at the end.
And so the first proposal for the afternoon is 2008-7, the WHOIS Integrity proposal. It will be up here in a moment. This is first proposed August of this year. It has been discussed at one policy meeting, the one in Nassau. A similar proposal has been adopted in the APNIC region. No discussions or anything in any of the other regions.
Basically what this says is that a resource must be covered by a registration services agreement before it can be updated. And note that it's "an" RSA not a specific RSA.
The shepherds are Paul and Bill. The council sees a liability risk. It says, clearly protecting or enhancing the accuracy of the WHOIS data is an appropriate goal of standard setting, and if it creates collateral requirements they are likely to be held by any reviewing legal authority.
Some staff comments could cause a serious delay in completion of update information and may cause additional data to become stale. And would require registration software update. And depending upon how this is implemented and what -- how well it is taken up we may have a major impact in terms of implementation up to 180 days. We haven't really done a thorough analysis of if we have to hire additional staff to do the anticipated work that this would produce.
There has been a lively discussion on the PPML. And the comments are there, I won't read them. Again, you're invited to go to the e-mail archives if you haven't been following this discussion.
And so we will now discuss this proposal. I'd ask Heather to come forward and make the presentation.
MS. SCHILLER: I need a reminder about how this works.
So, my name is Heather Schiller, I work for Verizon Business. And in the interest of full disclosure I work for a company that holds legacy resources, both IP addresses and AS number. So, we would be directly impacted by this policy, but we proposed it nonetheless.
And here's the exact policy statement. To ensure the integrity of information in the ARIN WHOIS database, a resource must be under an RSA, either legacy or traditional, in order to update the WHOIS record. ARIN will not update historical information in the ARIN WHOIS database until the resource holder can prove the organization's right to the resource. So, what problem is this policy meant to address? Primarily, I'm interested in routing security. The ability for a provider to have confidence that the WHOIS data is accurate and valid and that the organization asking us to route the upblock has the authority do so.
Secondarily, we'd like to prevent unverified transfer of resources either through ARIN or other -- through route hijacking.
Here are some statistics about the number of resources that would be affected. I've broken down by year from 1991 till 1996. The number of netblock records that have a last modified date of one of those years. In total it's 27,983 records. I have also done the same thing for AS records. In total 1,712 records.
I have done the same thing for ORG IDs: 19,041 ORG IDs have a last modified date between 1991 and 1996. But a last modified year doesn't necessarily guarantee that a record is inaccurate. There is always a possibility many organizations just have not had a change to their contact information in that time. But in a lot of cases, that's probably unlikely.
So here are some of the arguments that we've seen on PPML against this policy. And they mostly fall into two categories. The first category being folks who are against the RSA. For a variety of reasons, largely concerns that ARIN will use the RSA as a mechanism to be able to revoke a legacy holder's address base.
To that, ARIN legal has -- it's on ARIN's FAQ about the LRSA -- that the LRSA would not be -- that organizations who sign the LRSA will not be subject to policy that -- to future policy that would seek to revoke under-utilized resources. So, in my opinion that concern is not very strong if you actually go read the LRSA and what ARIN legal said about it.
The other concern is that folks are not in favor of the LRSA or standard RSA but not opposed to some other type of agreement with ARIN counsel. And if that's their concern, they should work with ARIN counsel on coming to another agreement. But it doesn't have to do with this policy.
And the second argument that folks are largely against this policy for is the fees that are associated with the LRSA, which is about $100 a year and in all honesty that is not a significant amount of money. But most folks are arguing that for legacy holders that have a 24 that the amount they pay per address is much higher than what a person who has a 16 or multiple resources for.
I think what's important to point out is that all of your resources under the LRSA have the $100 fee regardless of the number of resources you have.
So why have an agreement? Well, about the equivalent of 16,000 /16s don't have an agreement. That's a significant amount of resources that are not under an agreement with ARIN. The LRSA process provides a mechanism to verify that netblock holders have the authority to the resource. Going through the process of signing the LRSA will give ARIN and resource holders the ability to formally document their arrangement to that resource and update contact information as needed.
The LRSA also provides a mechanism to verify contact information every year through the $100 a year fee. And it gives resource holders assurance that ARIN will continue to provide them services.
This is the section from the LRSA that talks about the mechanism of verification that ARIN will go through in order to verify a resource holder's right to a particular resource.
And this is some information about the APNIC policy. I tried to pull most of the text to make it as similar to the APNIC policy as possible.
One of the things that I did not include is the second bullet about changing the -- APNIC changed the maintainer ID for all legacy resources until they got updated. And I left that out because I couldn't decide whether this would create more problems than not and I am still a little bit undecided about that.
MR. CURRAN: Microphones are open for discussion.
MR. SINATRA: Michael Sinatra, UC Berkeley. I am opposed to the policy as written. I am in support of the idea of WHOIS authentication. I appreciate the policy's conciseness and I do -- like I said, I support the ideas behind it. And in the interest of full disclosure, my organization has legacy and non-legacy situation. And we very much appreciate the effort that has been put into the legacy RSA and the revised version of the legacy RSA by the ARIN staff and ARIN counsel. And we are actively working with our general counsels to review that. It is unfortunately very slow and I assure you, painful process doing that.
I do not believe that the WHOIS information should be held hostage to that process, and I apologize for using strong words. It should not be contingent on that process. I do not believe that the policy -- in a certain respect we shoot ourselves in the foot when we do that because organizations that have been updating their WHOIS information that still have legacy resources that are actually trying to come into the fold will be kind of stuck in this situation.
So, I would rather not go this direction unless we can have a separate agreement that simply authorizes a particular entity to update WHOIS records for this particular netblock, but doesn't do anything else that the RSA or legacy RSA try to do.
Whether that's feasible or not, I don't know. Or until we wait until such a time as we have sorted out some of the RSA issues and we have got enough people signing that we think this is no longer an issue.
But I think when you look at the discussion on PPML, this policy whether it tries to or not, drags all of the RSA conversation back into the fold. And I don't know how -- I'm not going to ask staff directly how they're going to deal with that -- but how are you going to deal with a situation where somebody says, yes I want to update my records. I have -- I can't sign a legacy RSA right now, I can't sign an RSA right now. I want to do some other negotiation with ARIN counsel. How does the ARIN staff work with that? What kinds of resources does that impose on ARIN? I'm not sure. So, I can't support the policy right now.
I think it's a great idea. I think that hopefully some day we'll all be in this situation where we're all on equal footing and we all have these RSAs and we're done. And I appreciate that we're doing this. But I can' support this right now. Thanks.
MR. CURRAN: Okay. We have comment from a remote participant.
MR. LEIBRAND: This is from John Eggerly, State of Idaho. He says he represents a legacy address space holder.
His comment is, I am opposed to this proposal. While I agree that the information in the ARIN WHOIS database is important and that keeping current and correct is critical for this committee, I do not believe that this proposal will accomplish the proposal's stated goal of ensuring the integrity of information in the ARIN WHOIS database.
Without getting into the pros and cons of an RSA -- either standard or legacy -- I believe it is safe to say some legacy space holders are not willing to sign the current version of the LRSA. Given this, how would preventing current non-LRSA signed legacy space holders from updating their ARIN WHOIS information help keep the ARIN WHOIS database current and correct?
It seems that this proposal would be targeted more towards putting additional pressure on legacy space holders to sign an LRSA than attempting to ensure the correctness of the ARIN WHOIS database.
That's all for that comment. I've got another one that can go in queue.
MR. CURRAN: Okay. I'll come back. Front right mike again?
MR. DeLONG: Owen DeLong, ARIN AC. I'm opposed to the policy as written for much the same reasons that have been stated. The title proposes something good, the text doesn't accomplish what the title proposes.
MR. CURRAN: Okay. Center mike.
MR. RHETT: Jo Rhett, Silicon Valley Colocation (phonetic).
I am in favor of the policy as proposed. It just comes back to the fact that basically legacy resource holders want ARIN to keep doing work for them for nothing.
And, it gets tiring. It's not like ARIN was created last week. This isn't a transitional period. ARIN has been around quite a while. They could have come to the fold any time in the last decade.
MR. CURRAN: Okay. Remote participant, go ahead.
MR. LEIBRAND: This comment is from Michael Greb from Lenode. He says he is opposed.
Similar to others, I feel that the policy is counterproductive regarding the stated goal of WHOIS information current and accurate due to the issues with LRSA preventing people from updating records.
MR. CURRAN: Did that person state whether they were a legacy holder or not?
MR. LEIBRAND: I will ask.
MR. CURRAN: Okay. Far right microphone.
MR. WEILER: Sam Weiler. Opposed to the proposal for the same reasons that have been stated.
MS. SCHILLER: Are you a legacy holder?
MR. WEILER: No comment.
SPEAKER: We can't hear.
MR. WEILER: The answer was, no comment.
MR. LEIBRAND: Response from Michael. He says, I am not a legacy holder.
MR. WEILER: It might inform this discussion to have someone review the history of how ARIN became the registry of last resort. And the registry for all of this legacy space. And perhaps to speculate as to alternatives should the community not wish ARIN to perform that role in the future.
MR. CURRAN: Elaborate or?
MR. WEILER: I am hoping that someone else will provide that history who knows it better.
MR. CURRAN: Anyone want to speak on that topic? Okay. Center rear microphone.
MR. FARMER: David Farmer, University of Minnesota. We are a legacy holder. Of many resources.
I support the intent and even applying pressure to get resources under the RSA. However, I would think this would need to have a delayed implementation. Unless as you state up there, unless the ARIN council is ready to deal with 16,000 legacy holders within however the implementation timeframe we're talking about of this proposal is. That may not be all that practical, because we are talking about legal negotiations here.
So, if you were to implement such a proposal I could not support an immediate implementation. You at least need to give people the time to say, hey, this is going to be the new rules and you got until blah, whatever. You know, probably like a year to get this settled.
MS. SCHILLER: So --
MR. FARMER: And then ARIN's going to need to devote the resources necessary on it's side to settle this.
MS. SCHILLER: So, ARIN staff did make the recommendation that it would take up to six months before implementation and -- in the timeframe when I wrote the original policy text in the timeframe section, I said something about -- you know, as long as ARIN staff needed to implement. But in addition there should be a notification period to affected resource holders.
MR. CURRAN: Can I ask just a question for information? And it goes to several comments of urgency. Someone comes, they want to go to through a legacy RSA but that's going to take time and they don't want to have their updates interfered with while they are busy doing this process. I guess I'm trying to figure out how likely someone would have an urgent need to change a record that, I guess, hasn't changed in --
MS. SCHILLER: Seventeen years.
MR. CURRAN: Twelve years on the near side. Why waiting for assigned LSA would be a problem.
MR. FARMER: I -- It may or may not be a problem. But why would you -- you know, I think we've heard in other discussions related to, okay, what's ARIN's role. The primacy of the role is accuracy of the POC information and accuracy of the contact information. And if that's the stated primacy, then that needs to be the primary goal. And anything that could get in the way of the goal is not necessarily a good thing.
I would agree with you in many cases it's probably not in the way. But, if it's in the way of one, then it's probably a problem.
MR. CURRAN: Okay. So then, as you summarize, you would be -- if this were to be implemented, you'd want a delay or some announcement period and some delay before --
MR. FARMER: I actually would like to see something along this implemented. I think there needs to be a reasonable timeframe and proper resources from ARIN to negotiate this many legacy RSAs.
MR. CURRAN: Okay.
MR. FARMER: Because there's an impact on the resources of ARIN, too.
MR. CURRAN: Okay, sure. Bill, did you want to respond directly?
MR. MANNING: I'll be in queue.
MR. CURRAN: Okay. Go ahead, far right.
MR. SINATRA: Michael Sinatra, UC Berkeley. Just following up on two questions.
On -- regarding John's question about legacy holder updates for some of these old addresses. If there are things like area code changes in the point of contact phone number, our point of contact phone number stayed the same since probably the early '90s -- or probably since the late '80s. And yet, the area code has changed. So, there are instances where you might actually need to make an update on that.
But this policy also affects people who made an update yesterday but happens to have made an update on legacy resources. So, if you made an update -- if you've been keeping your records up to date and you need to make another change and you don't have a Legacy RSA or an RSA, then you can no longer make changes.
So, what we're going to start to see is, these numbers start to grow as the numbers of sort of locked WHOIS records increase.
MS. SCHILLER: Can I ask a question?
MR. SINATRA: Yes, go ahead.
MS. SCHILLER: Would you be more in favor if we included a section the way the APNIC policy does to lock a resource and publicly display that the resource has been locked?
MR. SINATRA: I don't know under what circumstance you would lock the resource there. Is it just because -- is it because of this policy or is it because the resource hasn't been modified in a certain amount of time.
MS. SCHILLER: No -- so, the APNIC policy says that resources that are not under an agreement with APNIC, they basically change the ORG ID to -- I think it's something like HM-APNIC. And so, what would happen is all of the ORG ID information would change.
MR. SINATRA: Okay. I wouldn't be in favor of a policy that was contingent at this time on the presence or absence of an RSA. I think that's sort of the hot button and why we are pushed back to this poly. Now, I want to follow up to one other thing. Which is, I am happy, and in fact would really like to find some way of paying for the services I receive from ARIN for the legacy blocks without having to drag my legal counsel and ARIN's legal counsel into this process. It would be so expedient if I could just say, I just want to pay for this stuff. Which is one of the reasons why I became an ARIN member.
And now that I have non-legacy resources, I'm hoping that at least some of that pays for some of the other services I'm receiving. So I really think the fees -- I know there are other people who don't like the fees and that's why they are opposing it. It's not the reason I am opposing the policy, I actually want to pay the fees. I don't want the legal baggage, at least not right now. That's going to take time to sort out.
MR. CURRAN: Okay. Center rear microphone.
MR. DUL: Andrew Dul, Perkins Coie, an organization that has both legacy and non-legacy resources.
I am in favor of the policy as written. However, I'd like to question to council whether or not the concept of a RSA light, which is sort of like a letter of authorization to change contacts is a good thing? A bad thing? Risks associated with that?
MR. CURRAN: Steve, if you want to grab a mike.
MR. RYAN: First, in response to David Farmer's question, lawyers are scalable.
I can assure you that no matter how many RSAs we got in a time period, we'd be able to address them all.
And the second version of the LRSA was really intended to begin the process of trying to figure out what people were asking for and to try and give that to them. You know, and we'll continue to do that. And I really see the next RSA as intended to do the same thing, to try and make this process easier.
With regard to the specific question, if you're asking my opinion, which I am glad to give. I have lots of opinions. It is hard to conceive of what this light arrangement is. Here's why. A contract is a set of requirements on each side. What is ARIN giving? You know, what set of services are we giving? And then what is the legacy holder giving in return?
You know, to tell you the truth, think the Legacy RSA is extraordinarily light. It is not a very onerous contract. It is as light as I thought we could make it at that time and it was intended to be that way. It was intended to be lighter than the RSA. But, you know, that's a policy issue for the community. If the community thinks there should be another alternative in the relationship and there's an appropriate policy balance between a desire, for example, to allow people to update WHOIS information and yet not bring their numbers within the system in the way the LRSA contemplates, then I think people ought to write a policy that addresses that. Because, you know, ultimately the board and the CEO direct the lawyer on what contracts to write for the organization.
But frankly given where we are now, I think we are trying to have a greater nexus between the legal contract writing and the policy process than we ever have.
MR. DUL: So, the question or the idea I was thinking of was more on the lines of -- because one of the things that came up on the mailing list was one of the reasons that we want some sort of paper or whatever is, in cases of fraud we have a piece of paper that says that a person who reported to be representing this group signed something that they were allowed to do this. Right? So if someone does that fraudulently you have a piece of evidence in the event that you need to do something about that.
So if you -- you are, you know, creating a letter that basically says I, Jo, you know, officer of company Z, is authorized to change ARIN records.
Sign my name. Is that a good thing that we would do? Or is that a bad thing because there is no other contract around that, then.
MR. RYAN: Here is the problem. Leslie has a staff of people who have to then make sure that Jo is Jo, and that Jo was the derivative person from the beginning of time who has that authorization.
In other words, otherwise the community would be defrauded by ARIN because we would be agreeing to certify that person as having a lawful right when we don't actually know it.
So from a registration services standpoint, I think we'd have to do a lot of work to ascertain that. And I think it's very interesting, it may interest the community, lots of people come in and start this process. And when we ask them if there's something squeegee in the information, we ask for more data, oftentimes they abandon the application to change these factors.
If you really want to find out about what is going on in the community, you would give us the direction that you want us to pursue those cases once begun. In other words that we would pursue them to find out why they abandoned because that, you know -- because maybe there's something there.
The large number of abandonments, once a question is asked about, is indicative of the fact that there are a lot of people in this community who aren't really who they pretend to be when they are seeking those changes. If that helps.
MR. DUL: Yeah, thank you.
MR. RYAN: Thank you.
MR. CURRAN: Thank you. Far left mike?
MR. PRUE: Walt Prue, Los Nettos. When I first read this proposal, the thing that first struck me was this would be a really good way to steal address space for an address block that had cloudy ownership. Sign the LRSA contract and then change the ownership so it obviously points to yourself.
I'm against this proposal. And it gets in the way of the first stated goal,which is to keep the WHOIS database up-to-date. And so I think it is going in the wrong direction.
A possible alternative would perhaps be to charge a one-time charge for a record change without requiring an LRSA signed contract.
MR. CURRAN: Okay. Well, one question for clarity. Do you believe that this -- you said it's a good way to steal resources by undergoing an LRSA and then updating the record. I guess because of what we just talked about with how our LRSA application is validated in the addresses, do you see this actually encouraging bad information in the database?
MR. PRUE: If somebody steals address space, that's bad information, yeah. I think it creates an avenue for people to -- being able to steal address space. And that's a concern of mine.
MR. CURRAN: Oh, okay. Understood. We have people in line at the front. Bill?
MR. LEIBRAND: Actually --
MR. CURRAN: I'm sorry. Remote.
MR. LEIBRAND: Another comment from John Eggerly, State of Idaho, who is reminding us that he's a legacy holder.
He says he does not believe they all legacy holders are simply wanting ARIN to perform inaddr.arpa and who is services for nothing. There may well be a whole lot of legacy holders with that intent, but I can guarantee that is not the case with the state of Idaho.
And then he also mentioned that, I can guarantee my working phone number will be changing within the next six months and my e-mail address may also be changing.
Although my address duties and responsibilities in relation to our IP address block will not be changing, ARIN staff has also made some other observations not yet presented this afternoon -- or my own comment is maybe not in detail.
One, requesting all -- requiring all requesters to have a signed RSA legacy or standard prior to ARIN making any updates to their records could cause a serious delay in completion of the update, which could negatively affect an organization's business.
Two, this policy may cause additional information to become stale in WHOIS since non- RSA/LRSA signatories will no longer be able to update their information.
Three. Since reverse DNS data is part of WHOIS data, a delay in processing or a refusal to process delegation update request could negatively impact requesters DNS operations, even if the contact information in WHOIS is correct.
And then he added that he's going to have a co-worker cuff his hands behind his back.
MR. CURRAN: Okay. And Bill, you were in line.
MR. MANNING: Yeah. So, I don't do this very often anymore. But -- Bill Manning, ARIN Board of Trustees. And holder of probably more legacy space than I maybe should.
I've turned a bunch in, I plan on turning more in. I have signed the legacy RSA before as many of the legacy resources as ARIN will let me. There are certain legacy resources where we are still negotiating because the resources were assigned to projects which no longer exist. The organization listed doesn't exist. And ARIN has a whole bunch of work to do to identify what the proper response is. Some of the address blocks are in use, and so we have this really interesting difficulty.
So if this policy passes, we could end up with a Catch-22 for some of these legacy resources where it's not clear how you identify who the right party is. And so you can't update the data because there isn't anybody to update the data and you can't really return it, because it's in use. It's problematic in a small percentage of cases.
MR. CURRAN: Bill, just go back to Walt's question. For the addresses that you have gone through in the process or just in general having gone through the process, do you believe there is a level of integrity on the things that are brought in under the LRSA?
MR. MANNING: Absolutely. If you bring them in under the LRSA, then there is no reason to not keep the stuff current.
MR. CURRAN: Well, I guess in terms of do you see it probable that at least given the process that you've experienced from the other side that something that's not -- would it be trivial or difficult or degree of difficulty in terms of bringing something in that wouldn't be legitimate going through the LRSA process?
Right now you can update your records without going through the LRSA validation that we go through putting resources under it. Walt was concerned that by going through the process of signing an LRSA we might be formally codifying resources to the wrong person.
MR. MANNING: I don't think that that's a strong possibility because the amount of vetting that gets done and the process of validating that the LRSA -- the person who actually wishes to initiate an LRSA. They check you out, they check out the organization, they make sure everything is clean before they, before they -- before ARIN will sign. And if they have any questions at all, they're going to come back to you and they're going to say, well, wait a minute. We think that X, Y, and Z, which is why I am currently in this situation.
We can't find the right holder or the right organization. None of the people exist anymore except me. And so we have to figure out what to do. That's the Catch-22. They won't let it in.
So, Walt, I think it's not a real high probability that you can use the LRSA to snatch address space.
MR. CURRAN: But it does result from the fact that if you have something that is legitimate but you don't have the documentation we end up with a stranded -- a set of address space that is in use but can't be changed necessarily because you can't make it through the process.
MR. MANNING: You can neighboring through the process, but you stepped into a pot of molasses and peanut butter.
MR. CURRAN: Okay. Does that clarify a little? Okay. Go ahead, R.S. Next in line?
ROB SEASTROM: Rob Seastrom here, ARIN Advisory Council, ClueTrust, and holder of assigned as in to me not to my organization legacy address space and AS numbers.
And I haven't signed a Legacy RSA yet. For reasons which are out of scope for here. But if this were to pass this would put me in a very interesting situation since I do conscientiously keep my contact information updated and have in fact last updated it a little over two years ago. And I would be in a position where I could no longer do that.
So, while the support the intention of making sure that the data in WHOIS more accurate, I believe that this way of going about it represents be a little step away from goodness.
MR. CURRAN: Okay. Back to the microphones. Far right.
MR. KNOWLES: John Knowles, Codine Communication. We do have resources, both assigned by ARIN directly and legacy resources.
I am against this proposal. We have not signed the Legacy RSA. That's out of my hands.
I try to keep it updated. If this passes, then I'm going -- hands are tied and the data is going to be out of date.
MR. CURRAN: Okay, simply said. Again, far right microphone.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. To me the fundamental problem with this proposal is that it addresses things that aren't a problem with the policy process.
It seems to me there are four issues wrapped up here, and I think they are all four issues that we as a community should take staff and the board to task on.
They are -- there is a verification of resources, and that has two components. Determining the true owner, the vetting process that was just described, and also making sure that the records do not fall out of date.
There are many simple steps ARIN can take. We have seen proposals to address these like e-mailing people once a year and other stuff. I believe almost all of these can be done proactively by the board and or staff and don't need any policy proposal process. And in fact, they should be much more aggressive about doing things to make sure that we know who the owner is and that that does not fall out of date in the future.
There is also the currently legacy LRSA process described by many. If anything, that to me makes this premature.
We should give that some time to work. I think it was brought to bear a little late in the game. But now that it's here, it does take some time to get through all of this. And I think staff is really ramping that up. So, I think putting more effort and resources behind that is an excellent thing.
I think we need to explore fee for services. One of the concerns with all of this is, these people aren't paying for the services they're getting. I see no reason why we couldn't charge $100 to make a change to your WHOIS record. That's a one-time payment. And would, in fact, be a higher fee if you change it a couple of times a year than if you had an agreement. So, it's more incentive to have an agreement. That's also not a policy matter.
MS. SCHILLER: But at that time -- how would you propose requiring, then, that ARIN staff verifies that you're authorized to make that change?
MR. BICKNELL: That's point one, they have to verify first. But somebody has to pay for the staff to do that verification.
Today you may send in an update and they may do 10 hours of verification proving that you are who you are, and then they do the update for free. Who just paid for the staff time? All of the rest of us. Charge the person who did it $100. Simple, recover it.
And last, there is the security framework. And this came up in the APNIC question. Part of the reason APNIC did this is because they actually went to secured updates of all of the data. You had to have a PGP key or SSL login or -- I don't know the mechanisms. But they actually fully secured and locked down the updating process. And I think that staff and the board and all that could direct ARIN to better automated and technologically secure it. Such that once we've done all this vetting, it doesn't fall out of date. Somebody's got a key, they've got a password. They can log back in and do it, and a year now we don't have to re-vet everybody starting at the bottom up, that whole 10-hour process. So I think there's four prongs there that aren't policy prongs that this policy touches on.
I have one comment and question to leave with. To Bill's point, I think there are a number of resources in the situation that Bill finds them in. And we would have to be amazingly careful in how we crafted the language. But I think some form of essentially an amnesty policy makes sense. And I don't know what that would look like. But while Bill may not be able to find the organization that got this and the person that got it and the project that got it and all of the other things, we may be able to do something like go to five independently operated BGP route servers and determine that Bill has in fact been the only person using it for the last 15 years. That may be close enough.
And so, I think, you know, we need to get feedback from the staff on where those problems occur and maybe craft some policy to allow them some discretion in bringing those in.
The last thing I want to leave with, because I've heard several people talk about this, is I know many organizations that have both legacy and non-legacy resources. Several of these organizations are expending huge amounts of legal time to sign an LRSA. You've already got an RSA through your organization's legal to cover all of your current records. Why do you not put all of your legacy records under that RSA, which my understanding is if you tell ARIN staff you would like to do that, they will simply add them to the list and put it under a single agreement you already have approved? Why are you going through the LRSA process?
MR. CURRAN: Two things. First, just to summarize, you are against the policy?
MR. BICKNELL: At this time, yeah.
MR. CURRAN: Okay. And to answer the second one -- and I will answer offhand based on what I have seen from the inside of ARIN as chairman -- recognize that the LRSA has a different set of privileges and rights than the RSA, which some people seek to preserve through the LRSA. So, it's --
MR. BICKNELL: I understand that. The question that I would have, though, is specific. I know, for instance, of ISPs for which by number of IP addresses, 98 percent of their IP space is under an RSA. They are going through the LRSA trouble for the last 2 percent. And that seems to me an interesting cost benefit tradeoff. And I understand there are different privileges for that 2 percent. But what makes them so valuable that it's worth spending a year of your and ARINs legal time on.
MR. CURRAN: Yeah. So, if you find yourself in that circumstance, please hunt down Leo and educate him and he can come back and report to us.
MS. SCHILLER: I would just like to say that for our company, we looked at this and basically came to the opposite conclusion. And my argument to our legal department was, we have resources under RSA and a bunch of resources not under any LRSA -- or, not under any RSA. Since we apply the same rules and policies to our non-RSA'd resources -- our legacy resources -- that we do our RSA ones -- what is the harm in signing the RSA.
And our legal department look at both and said no harm. If you can get all your stuff together, go ahead and do it. So.
MR. CURRAN: Okay. We have a remote participant.
MR. LEIBRAND: This is from Bridget Teet, State of Idaho. Comment is -- or she's a legacy space holder who is opposed.
The comment is -- okay, sorry. She just made a correction. The comment is that she's opposed because if this passes it will handcuff them. The LRSA process for us -- government -- is lengthy and not in my hands or John Eggerly's, so to date we do not have a signed LRSA. Talk to our CIO and our legal counsel.
However, we are good citizens by keeping our WHOIS info updated. If this policy is approved and we are in this limbo mode of having no LRSA we also can no longer be good citizens.
The intent of the policy is noble, but I don't think that it is in the best interests of all concerned.
MR. CURRAN: Okay. Far right mike.
MR. GASHINSKY: I have a question about the proposal. What is the justification or reasoning for requiring an agreement? Specifically RSA or LRSA and not some third agreement that doesn't alter any rights or apply any rights and just that I am who I say I am.
MS. SCHILLER: So, the process today contains a mechanism for ARIN to verify that you are the authorized resource holder. So, by being able to enter into the agreement with ARIN they go through the process of verification. And in addition, it contains a mechanism to maintain contact and maintain that the resources are up to date.
MR. GASHINSKY: Yet we currently allow people to modify stuff without that process. So, why are we altering that? Why do we seek to alter that?
MS. SCHILLER: For the goal of making sure that the folks who are modifying a resource are the ones who are authorized to do that.
Because, we have the problem where folks come to us and ask us to route address space, and the company names don't match and we say we're not going to route it because the company name that you signed up for service with us doesn't match the company name in the record. And they say well --
MR. GASHINSKY: I'm not questioning -- I'm not asking for what the goal is of the proposal, I am asking for what is the rationale behind specifically requiring an agreement like an RSA or LRSA?
MS. SCHILLER: The agreement is the mechanism that exists today for ARIN to do that verification process.
MR. GASHINSKY: Could we use an alternate verification process?
MS. SCHILLER: Today ARIN doesn't go through a process of verification for regular contact information updates. The agreement process gives them a mechanism to do the verification and then a mechanism to maintain that information.
MR. GASHINSKY: So, if ARIN had a way to verify your information and if you structure to pay for that or what not, could we use that without forcing people to sign an RSA and be in a situation that they are right now? Where they haven't signed the legacy RSA and for those records they can't update --
MS. SCHILLER: That's a question for staff and legal counsel.
MR. GASHINSKY: Yeah, right. It is.
MR. CURRAN: You see the -- that's actually a community question. If you propose such a mechanism, then it could easily be considered. Sure.
But right now we have a sort of situation where record updates are made -- and I'm going to try to use terms current versus accurate. Records are made current by updates processed, but they are not necessarily made accurate. They are made accurate by running through the verification process and ARIN actually going through that as part of the LRSA. This will have interesting implications if we ever get to RPKI, about whether we want current data or accurate data listed in it.
MR. GASHINSKY: So, I guess my question for the staff and legal counsel would be, can we get to the point where we verify it -- they're not willing to sign any sort of an agreement, but we have verified it and at that point allow who updates?
MR. CURRAN: Well -- so historically, this community said that to offer such folks a legacy RSA agreement so that they are participating in ARIN and paying for the services they get. That's what we were directed at when we sent forth counsel and said, go do a legacy RSA.
MR. GASHINSKY: Okay.
MR. CURRAN: Okay? Okay. We have far left mike?
MR. WEST: Ken West, Sprint. I'm against this policy as written. The reason being I'm having a difficult time getting the legacy RSA agreed upon internally. I don't anticipate that happening anytime soon or maybe not at all and we would like to be able to keep our WHOIS data as accurate as possible. And we have updated it in the last two years.
In addition, as a side note, I would be willing to pay -- I would be willing to pay for the services that we're getting for updating this and a different mechanism in place.
MS. SCHILLER: Could you also answer Leo's question, if I'm allowed to ask? About -- I'm presuming being Sprint you hold both legacy and non- legacy resources? So, Leo's question was about why you would put your legacy resources under -- why you would go through the effort of trying to get your legacy resources under the Legacy RSA and not put them under the RSA that your other resources are under.
MR. WEST: The Legacy RSA has kinder language than the non-legacy RSA? I guess would be the answer to that question.
MR. CURRAN: Okay. FYI, if you're going to speak on this topic remotely or here, approach the microphones or get your comment in. I'm going to be closing the microphone shortly. Center front?
MR. RHETT: No one is going to love me for this. This is Jo Rhett, Silicon Valley Colocation. Something that we have to go over here -- that having a third agreement that requires them to do nothing but it gives them authorization, continues the current policy of having a privileged class.
And one of the things frankly I'm really tired of -- it really shocked me not a single person who is remembering Jon Postel pointed out that he would have found this situation abhorrent. He would not have -- the amount of bad faith going on in these transactions is amazing.
And the whole idea of, I want to get special privilege over everybody else and not play ball, it is just amazing to me.
I had legacy resources. I signed an RSA for those resources. Immediately. Once ARIN had it's ground work in. This is what we were all doing 20 years ago, we were all shaking hands and doing things on hand shakes because everybody was participating in good faith. And this whole idea of let's make another thing to I can continue to not have to play in your ball court but get all the advantages of it -- it just -- you know, no. I wouldn't support anything like that.
Sadly, I would have to say I support the idea because we may not to be able to legally get it done, of charging them a fee. But the fee should be commiserate with the amount of work done, which makes it more than $100.
MR. CURRAN: Just to be clear. You'd support that position, but you actually support this particular policy.
MR. RHETT: I absolutely support this particular policy.
MR. CURRAN: Okay, just to be clear. Okay, far left mike?
MR. TEMPLIN: Pete Templin with Texlink Communications. We have resources to the best of my knowledge, none of which are legacy. I support this proposal completely.
I ask that you give me some sort of easy button so I can go in and say, yup, it's up-to-date.
Just out of curiosity, I took a look at records for where I went to college and thought so and so is still listed there, that's got to be out of date. No, he still works there. So, you've got places that would have old stuff. Give him a button to say, yup. It's up to date.
MR. CURRAN: Okay. Good to know. I am closing the microphones in 10 seconds.
MR. GASHINSKY: So, to follow up on my question, and I know my organization holds any legacy space, so I am just curious. There are people who -- there are significant legal costs to signing an LRSA because there's perceived, real or not, thinking that LRSA is more limiting than the past agreements beforehand. If the purpose of the policy is to just get the WHOIS record accurate, could we create a lightweight LRSA, which does nothing to limit any of those perceived rights, but does get in the fee structure where they will pay for maintenance of (off mike) and verification and could just get the WHOIS information accurate. Because I do have a problem with what was essentially said before, holding WHOIS updates hostage to -- basically, legal review. Because I understand that in many organizations that could take years.
MR. CURRAN: You said to get the information current or accurate?
MR. GASHINSKY: Both.
MR. CURRAN: So you would imply this other method would have some form of verification.
MR. GASHINSKY: Yes, and a fee that goes along with it.
MR. CURRAN: Okay. Microphones are closing, but I see counsel approaching the mike.
MR. RYAN: Yeah. We can sign an LRSA in a day with any lawyer or with just a client going through it with the changes. In fact, we can do it in an hour. So this is not laborious. We know what we are doing on this end because we handle them in a volume.
We have one person legally who handles them if I am not available. There is always someone available. And similarly the LRSA process actually is much slower at ARIN because they are verifying the resource holder. That is the part that takes time. It literally, by the way, takes less than -- the average right now is about a half an hour of discussion with lawyers. And that's only if people want changes.
If they want to sign the LRSA you never have to talk to a lawyer. And the version 2, frankly, is the lessons learned from that. So, I want to reassure people that it is intended to be as lightweight and easy a process we can make it, consistent with verifying resources themselves.
I just -- you said several times how hard or -- you know, how difficult it would be. It really is not or intended to be.
MR. GASHINSKY: I don't think the issue is so much how hard or difficult it is, but how long it takes to get through the internal approval process.
MS. SCHILLER: But, that has more to do with verification than with signing the LRSA. And --
MR. GASHINSKY: Other internal --
MS. SCHILLER: Your internal process.
MR. RYAN: Some organizations, the internal process for getting the legal approval for the LRSA, not working with ARIN but just internally getting someone to be able to act --
MR. GASHINSKY: Exactly.
MR. RYAN: -- may be more painful than any verification process of resources.
MR. GASHINSKY: Exactly.
MR. RYAN: I have heard that. Some people find me directly and tell me stuff. So, I have heard that directly on occasion.
All right, I think we have got a great discussion. Heather, thank you.
MR. CURRAN: All right, folks. It is time to provide guidance to the Advisory Council on this matter. I'm going to make sure my polling mechanism is in place, and I see it is.
Okay, this is the exercise component of our post-lunch program.
So, for people in the room and those remote participants, I'm going to ask for a show of hands regarding Policy Proposal 2008-7. I'm going to ask for everyone in favor and then everyone opposed.
So, everyone in favor of Policy Proposal 2008-7, WHOIS integrity policy proposal, raise your hand now. Nice and high.
Okay. Thank you. Everyone opposed to Policy Proposal 2008-7, WHOIS integrity policy proposal, raise your hand now.
MR. CURRAN: Okay, thank you. I'm not going to ask everyone holding legacy space under suspicious circumstances, raise your hand. But that's the next meeting, okay.
SPEAKER: Ask how many legacies there are.
MR. CURRAN: Are you saying how many people who have legacy space -- not legacy space -- how many people are legacy space holders.
For point of information, raise your hand if you hold legacy resources.
SPEAKER: (off mike)
MR. CURRAN: Either way. Yep, count it. How many legacy space holders in the room? Legacy RSA or not.
The same for the online participants. If you're a legacy space holder, throw your count in there, please. It's not a crime, you can raise your hand.
MR. CURRAN: We have great photography for this meeting. Okay we have them, thank you. We're waiting for the count. The count.
On the matter of Policy Proposal 2008-7, number of participants, 114; number in favor, 15; number against, 33. Of the participants, number of legacy space holders in the room, 38. This information will be provided to the advisory council for their consideration.
You have a comment?
MR. RHETT: Jo with Silicon Valley Colocation. I have one comment not specific to this proposal. But that this issue with the RSA -- this entire proposal, which is a good proposal, was bogged down in the issues of the RSA and LRSA. And this is probably our biggest problem is that ARIN has a lot of work that it needs to do that is completely being side-railed because of the desires to continue a privileged class.
MR. CURRAN: Okay. I'm going to ask -- a wonderful comment. If I had known you were going for that I would have asked you to hold it until open mike at some point today or tomorrow, thank you.
Let's keep -- anyone who has any other comments or views on that, pencil them down and there will be an open mike session where we can vent or voice them. Thank you.
MR. PLZAK: Okay. Now we'll move on to 2007-14, Resource Review Process.
First proposed in July of '07, it has been around through four meetings. Let's see, Albuquerque, Denver, Kingston, and Nassau. The community consensus has been to revise the proposal.
It has been revised several times. With a recent flurry of activity between the lawyers and the author, the latest version on the 14th of October, which is online and there are hard copies available.
If you need a copy -- hard copy -- raise your hands and it will be given to you.
So, I see several over here. So keep them up so we can see who needs them.
Okay, over here. There is no corresponding discussion of this in any of the other regions. This is -- from a summary perspective, provides clear policy authority to audit or reclaim resources. Guidelines for how it shall be done in a six-month grace period minimum for reclamation. Shepherds are R.S. and Leo.
Counsel says there is a risk that paragraph seven is broad and an ambiguous description which could contradict rights and obligations in 12,000 current RSAs. Staff has several issues in concerns in that the RSA allows ARIN to request necessary data without limitation of frequency. The single aggregate "block," is this a single CIDR prefix or a contiguous range of addresses.
And there's a fee -- there's some text in here related to fees that doesn't relate to the policy.
Staff says we could implement this in about 30 to 90 days. We have to make some registration system changes. We probably will have an increase in the registration services workload and or turnaround times. And moderate discussion to add to light. There's the comments. Again, you're welcome to read the archives. And I would like to call on -- I guess it's Owen -- to present this proposal.
MR. CURRAN: Okay we got someone at the microphone, pre-presentation. Yes, Heather.
MS. SCHILLER: So, the update that was handed out says that it was modified on October 14th, which was two days ago.
MR. DeLONG: Yes.
MS. SCHILLER: Which means it hasn't been discussed on PPML, which means that it's been changed since the 30-day mark before the meeting --
MR. CURRAN: Right.
MS. SCHILLER: -- which means it wasn't the version we discussed at the Caribbean meeting.
MR. DeLONG: That's all correct.
MR. CURRAN: This is changed October 14th?
MS. SCHILLER: Two days ago.
MR. CURRAN: Two days ago?
MR. DeLONG: It was as a result of a discussion with Steve Ryan. The changes are incredibly minor, do not change the intent of the policy, and I'll go into that if you'll let me get to the presentation.
MS. SCHILLER: I think that my disagreement is with the fact that this is not the version of the policy that was discussed at the Caribbean meeting and it is not fair to the folks who were at that meeting and are not able to attend, and it's not fair to the folks who are on PPML --
MR. CURRAN: Right --
MS. SCHILLER: -- and that the rest of the community hasn't been given ample opportunity to discuss it.
MR. CURRAN: Right. So the fact of the matter is we have a deadline for policy proposals prior to the meeting. So, while we're going through this we've got to discuss what had enough notice for the meeting and then you can discuss the suggested changes that you've gotten since that time.
Can you follow that?
MR. DeLONG: I follow that. But the changes that are in there are minor and editorial in nature and are strictly to address the staff comments and legal comments to address the issued they raised and do not change the intent of the policy proposal.
MR. CURRAN: Excellent. And they will be given to the AC to consider.
But what has to be covered in the meeting is the one that made the deadline for purposes of what we're talking about here. The good news is, since they are minor and have no impact, that won't be a big problem.
MR. DeLONG: Okay.
MR. CURRAN: Okay? Thank you, Heather.
MR. DeLONG: So, we'll go with the version that's already been proposed. Not this one, correct?
MR. CURRAN: We have to go with the version that's published. Thank you.
SPEAKER: Is the version on the web page the current version?
MR. DeLONG: Depending on your version of "current."
MR. CURRAN: The one with enough notice for the meeting.
MR. DeLONG: Nope.
MR. CURRAN: The one on the web page has been revised -- oh, I'm sorry. But there are previous versions?
MR. DeLONG: Yes.
MR. CURRAN: Okay. Folks? We need to make sure the PPML has notice before the meeting. And so --
MR. DeLONG: This was sent to the PPML on the 14th, along with everywhere else.
MR. CURRAN: Right. But that's two days ago.
MR. DeLONG: Yes.
MR. CURRAN: We close policy proposals --
MR. DeLONG: We close policy proposal submissions, not revisions.
MR. BICKNELL: John?
MR. CURRAN: Yep.
MR. BICKNELL: If I may, as chair of the AC, I just verified the policy process online -- on the website. Because I wanted to be sure I got this right. There is a 60-day before the meeting deadline to have your proposal submitted. There is no written formal deadline for changes anywhere.
The AC has chosen, in the past, to take a very dim view of proposals that were changed immediately before the meeting because of the concerns that Heather has raised. And so, I think from a process point of view there is no problem with Owen presenting a change. It may make him greatly risk the chance that this is passed by the AC. But in terms of the letter of our policy process, I don't believe that is a problem.
MR. CURRAN: Right. Now, the other problem is that there's also a fairness doctrine with respect to people attending the meeting and attending the meeting remotely who may or may not be aware of the fact that the policy change. And therefore, may not even be watching the session because the version they saw that went in was just fine. So --
MR. BICKNELL: And I believe the chair needs to make sure that we have a fair process.
MR. CURRAN: Right. So, I -- we have an unfortunate -- because we have the no hard deadline, I'm going to actually put this matter to the room. Okay?
There's been an appeal about the proceeding on this particular matter. However, I am more than willing to take the room and remote participants and take the consensus of the room of whether we use the version as of October 14th or the version that was discussed at the Caribbean sector meeting.
So, I am going to ask for a show of hands. I need the polling mechanism spun up. And I'm going to ask for the sense of the room.
MR. FARMER: Before you do that -- David Farmer, University of Minnesota -- one quick question. Is -- just to be very precise -- the version you're referring to is the version printed in the discussion manual?
MR. CURRAN: I will explain -- yeah, I will explain prior to the vote.
MR. FARMER: Okay, thank you.
MR. CURRAN: Okay, thank you. Okay. We all have a discussion guide with us, right? The version in the discussion guide is what version? It is the posted to PPML on the 14th of August, okay? That's this version, post-Caribbean sector version.
There is a more current one posted to PPML on the 14th of October. We're going to refer to these as the printed one, okay? And, the revised one. I'm going to ask for a show of hands on how many people believe we should use the revised one rather than the printed one.
So, if you wish us to move ahead and use the revised one for the discussion --
MR. CURRAN: Yes?
MR. DELONG: If I may explain what the difference between the two is before we call that question?
MR. CURRAN: It's a very simple matter. That's not actually relevant. And I understand, but we need to actually get to one and then you can describe the differences, okay?
Because we really have the remote participants to worry about as well.
So, I'm going to ask for a show of hands for people who wish us to use the revised version of the proposal. This was the October 14th version, which is -- October 14th, presumably in your presentation and presumably what I see on the web.
If you vote aye by raising your hand, we're going to use the current, revised version. If you vote against this, we're going to use the printed version.
So, all those for using the revised October 14th version, raise your hand. Remote participants, please vote if you want to use the revised October 14th version. Thank you. Everyone opposed to using the revised October 14th version, which means we will instead use the August 14th printed version, raise your hands. Thank you. It's coming up to me now.
Okay. The number of participants, 114; the number in favor of using the revised October 14th version, 21; the number opposed, 29. We're going to use the printed version of August 14th. It is what's in your discussion guide. And I will take a note to do the necessary administrative changes to prevent this from occurring in the future.
MR. DeLONG: Okay. Now that we've changed the rules at the podium again, I'm going to have to adapt a little bit. So let me explain the differences between the presentation and what we'll be discussing before I get into the presentation.
The presentation is based on having changed paragraphs 3, 7, and 8. The paragraph 3 we're actually discussing says, "ARIN shall communicate the results of the review to the organization." The paragraph 3 in the presentation assumes that it says, "At the conclusion of a review in which ARIN has solicited information from the resource holder, ARIN shall communicate to the resource holder that the review has been concluded and what, if any, further actions are required." This change doesn't change the intent of the proposal. It merely addresses a concern raised by staff.
Paragraphs 7 and 8 were modified to address concerns raised by legal. Similarly minor.
The paragraph 7, we're not discussing reads "ARIN shall continue to provide services for the resources while the return of revocation is pending except any maintenance fees assessed during that period shall be calculated as if the return of revocation was complete."
And paragraph 8 reads, "This does not create any additional authority for ARIN to revoke address space -- legacy address space. However, utilization of legacy resources shall be considered during the review to assess overall compliance."
I will be asking the Advisory Council to consider these as minor edits that don't affect the intent of the policy in their deliberations. I don't know what'll happen with that, but, you know, we'll obviously be doing the show of hands on the unadopted versions that legal and staff object to instead of the ones that have been addressed.
With that, here we go. Okay. Let me turn this over then so that it's the right button to go right.
We attempted to publish a revised policy. This gets into why the updates that we're not discussing. We tried to revise the policy in time for the 30-day deadline that we sort of have tried to impose on ourselves. Unfortunately, the feedback from legal and staff came, well, after the revisions. And so in order to try and resolve that with staff and legal with the turnaround times on e-mail and whatnot, basically the final revisions ended up being the result of a hallway discussion with Steve Ryan and that's what got rolled into October 15th, and that's why -- or October 14th and that's why such a late revision. The good news is that, you know, after all of this lengthy process, what we did actually roll in was pretty minor changes and it really just addressed some concerns from legal and staff.
Why this policy? It's not clear completely that ARIN has any review authority unless somebody comes for more space. There's still some ambiguity about that expressed by staff. Legal thinks that they have whatever ability they want in the RSA. And this policy just sort of attempts to clarify that, yes, that does indeed exist and needs to exist.
It also makes an attempt at limiting that authority a little bit in order to prevent abuse on either side. It tries to set a clear set of expectations on both sides. It tries to provide for greater scrutiny of the IPv4 utilization as the free-pooled windows. And it is intended to apply to all ARIN-managed resources, not just IPv4, but certainly the IPv4 situation is a driving force.
Almost all the PPML and prior meeting feedback has been incorporated into the existing version of the policy. The few areas or the few comments that were not incorporated were mostly, you know, things like, well, this is just a bad idea anyway, and they were pretty much in the minority.
The rationale's been completely rewritten because it was very clear from some of the discussion that the previous rationale was a bigger sticking point than the actual policy. So in order to try and address that perception issue, we've rewritten the rationale to be a little more clear.
And this really, in our mind, clarifies -- mine and the other co-authors' minds, clarifies ARIN's existing authority and puts some limits on it rather than actually expanding ARIN's authority to do resource reviews. So -- and that is consistent with what we've been told by Steve Ryan as well. So hopefully, you know, that puts it in a better frame of reference for discussion.
There were some concerns expressed by legal, and they apply to the version we are actually discussing. However, in the version we are not discussing, the authors did address the -- actually that did not make it into the text of the October 14th somehow. There is a sentence that should be added to -- or a phrase that should be added to the beginning of paragraph 7 to address one of Steve Ryan's concerns that is, "In case of return under Sections 4 through 6," which is strictly a clarification. All the other issues with legal have been addressed to Steve's satisfaction to the best of my knowledge. If Steve objects, he's welcome to comment.
Staff concerns. They were concerned that Section 2C was not consistent with the RSA's. That's sort of true. It is more restrictive on ARIN than the RSA. We think that's actually a good thing. We think that the restrictions are not onerous to ARIN and that they are legitimate and consistent with the intent of the policies of the community.
And so, you know, if the RSA doesn't match, we think it's perfectly possible for ARIN to comply with both by complying with this. And if it's necessary, the RSA can be modified accordingly.
Section 3 was revised based on staff recommendations. And the last word I have from staff is that those revisions do accommodate their needs.
Single aggregate block is intended to basically reflect the goal of maximizing the efficiency and aggregation of what is held and what is returned. We couldn't come up with a better term to give to staff, so instead we decided to stick with saying, you know, this is what we mean and staff has good judgment. Go forth and do the right thing. Ideally, we'd like to see what is kept and what is returned be a single CIDR prefix, but that's not always going to be possible. So, you know, carve it up into the smallest number of chunks possible and move on.
Okay. Questions, comments, respect, tomatoes, whatever.
MR. CURRAN: Okay. Microphones are open as is remote participation. Far left mic.
MR. TEMPLIN: Pete Templin, Texlink Communications. During your presentation you mentioned that paragraphs 3, 7, and 8 had changes.
MR. DeLONG: Correct.
MR. TEMPLIN: Upon a quick reading of what's in the printed manual and what's online, I see substantive changes in paragraph 1. Can you explain and elaborate reasons there?
MR. DeLONG: Editorial error. The version in 3.3 is what was supposed to have been in all along and I'm not sure where the version in the printed manual snuck in.
MR. TEMPLIN: Okay.
MR. CURRAN: Does the change in paragraph 1, one way or the another, matter with your support to the policy proposal?
MR. TEMPLIN: I'm unable to come to a decision on that because I suspect that all of my resources are covered under a single RSA. But I suspect that there are plenty of people whose resources might be under different versions.
MR. CURRAN: Okay.
MR. TEMPLIN: And I merely at this point ask that we keep the variances in mind as we discuss.
MR. CURRAN: Okay. Far right mic.
MR. GASHINSKY: I have a clarification question for 2C, where at any other time without having to establish a clause prior to review, has been completed in the preceding 24 months. Is a request for new resource review? So if you've requested a new resource in the past 24 months, does that mean that 2C will keep this review process from being instantiated for 24 months?
MR. CURRAN: I'd have to ask Leslie how she would interpret that because I'm not actually sure.
MR. GASHINSKY: What is the intention?
MR. CURRAN: What was your intention? Was your intention that if an organization received address space --
MR. DeLONG: The intent was to limit how often ARIN could do a review without you coming to them. We hadn't really thought through whether that would affect, okay, you've gotten your application six months ago, does that mean that ARIN can't review you, you know, nine months later? We didn't think that through.
SPEAKER: That's a pretty substantive difference.
MR. CURRAN: Right. Leslie, can I ask a question?
MS. NOBILE: Yes.
MR. CURRAN: Point of information. When an organization applies for address space, presume it's a trivial case of getting additional address space, and an extensive review of there resources were completed six months earlier, would their subsequent request for address space always trigger another review?
MS. NOBILE: It would trigger not a full audit, but we would ensure that their previous allocation was 80 percent utilized according to current policy.
MR. CURRAN: So there'd still be a review of sorts?
MS. NOBILE: There'd be a review, but we would choose several customers and reassignments to ask detailed questions about and we'd ensure that all the rest of the reassignments were SWIPed or RWHOISed.
MR. CURRAN: Okay. It would appear to me that any allocation of resources is happening after a review of sorts; that's just my guess. But, I mean, obviously this desire -- if there's a desire for clarity one way or the another, the language should be addressed to make it the way you want it.
SPEAKER: And just a clarification. You said the past or the last allocation is checked? Everything that is last minus 1 is not checked, right?
MS. NOBILE: Yes.
SPEAKER: Okay. So there's a very major difference in what's going to be.
MR. CURRAN: Okay. And would you be in favor of the policy proposal as written?
MR. GASHINSKY: I would not be without clarification.
MR. CURRAN: Okay, thank you. Center front.
MR. RHETT: I just have a question. I keep hearing the people saying what's -- you know, how often could it be requested? This information doesn't change and when it changes, you know, it's -- somebody asked me for the same information they asked me for a week ago, I'm going to forward them the same e-mail I sent them last time. I mean, what are we -- if somebody could clarify for me how this produces undo stress in an organization. I mean, I have to admit, guilty as charged, I've got a database that can just spit out the entire utilization of everything on demand, so, you know, I'm set up well, but.
MR. DeLONG: Let me make a slightly clarification first. As the rules stand today, although ARIN does not do this, Steve Ryan assures me ARIN can come to you every week and ask for this if they want to. So this at least puts a 24-month limit on how often ARIN can do it without you asking for something else. That limit doesn't exist today.
MR. CURRAN: So just back to Jo. The intent of the policy is to prevent you from being subject to having this asked routinely, time after time, without a request or without a 24-month intervening period. Are you for or against this proposal?
SPEAKER: I think there's lots of wording things that need to be worked out, but I think the intent is good.
MR. CURRAN: Okay. Far right mic.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. This proposal reminds me an awful lot of my comments at the last proposal, that this should not be a policy matter. If counsel believes ARIN can go off and do this, I believe it has been abundantly clear for many years that the community is unhappy that ARIN seems to not want to take this on. I don't know if that's a board problem or a staff problem or if the community's not saying it loud enough. But, you know, information is going stale and we have been screaming from the top of the rooftops, go check this out. And unlike the last policy, because I believe the community has been singing this for longer and Owen has suffered for a long time, that we need to force this policy through. ARIN's staff and ARIN's lawyers are writing this policy in the policy process because the board and staff haven't done this outside of the policy process. And it's been two years now. Your time's up. Let's pass it and force you to do it.
MR. CURRAN: Can I ask a point of clarification? Because I was confused for a moment.
If there's -- I mean, I see being reprimanded. Reprimand accepted, I think. But I actually thought the purpose of this policy was to prevent not external WHOIS resources, but internal data supporting your resource request from being capriciously reviewed. I didn't see this as a compelling command to hold reviews. I saw it as a statement for ARIN not to capriciously hold one. And is that roughly the intent or am I misreading it?
MR. DeLONG: It's a little bit of both. One of the complaints we have received from staff about why they're not doing these kinds of reviews has been we don't really have a processor policy to support doing it. Steve has said yes, we absolutely have the right to do it and staff probably could be doing it. And if that's the community, well, they should be doing it. The staff has a little bit less receptive to that position. The result being that we've sort of tried to write a policy that tries to balance both of those issues and come out with a fair set of expectations in both directions.
MR. CURRAN: Is it the intent of this policy that ARIN shall conduct reviews every 24 months of information?
MR. BICKNELL: It is the intent of this policy to provide a framework in which ARIN staff will feel more comfortable doing so. And it is the expectation that the community has called for ARIN to do some form of review on whatever schedule works best for ARIN and the community. That is not a policy matter, that's an operational matter.
MR. CURRAN: Okay, that's good to know. Thank you, Leo.
We have a bunch of folks. I'm going to go front and center. Jo.
MR. RHETT: Jo Rhett, Silicon Valley Colo. I'm going to just make my thing more explicit. I like this proposal because it does -- I've heard the same comments from staff. And it does give them the explicit directive to do this work that they've been telling me they need to have, and that's why I support this proposal. I would support it with or without the limitation on how often they can do it. I don't see it as an issue, but that's personal perspective.
MR. CURRAN: Okay. I have a point of information. Leslie? In the staff review of this, regarding the impact level, was it assumed that this gives you the right to perform reviews no more often than every 24 months or that staff would be reviewing all resources every 24 months? Did you presume that if this was passed, we would be going through and reviewing all resources every 24 months?
MS. NOBILE: No, the presumption was it gives us the right to audit them every 24 months --
MR. CURRAN: If needed.
MS. NOBILE: -- if needed.
MR. CURRAN: Okay. I just wanted to double-check the level of effort. Okay. Igor, front right.
MR. GASHINSKY: Yeah. I just wanted to clarify something I have said. I am against this policy as written. I want a clarification one way or another, and as long as it's clarified one way or another, I'm for it. I just want to make sure that it's explicit. I'm for whatever it is as long as it's explicit and not to interpreted. (Laughter) But one way or another I just want it to be clear.
MR. CURRAN: Once we know what it is, you're for it. Got it.
MR. GASHINSKY: Yeah, yeah. Once we know whether the last review is it or not, I'm for it. I just want it clear.
MR. CURRAN: Makes perfect sense, thank you. Center rear.
MR. HANNIGAN: Martin Hannigan, Verne Global. I'm against both of these policies.
MR. CURRAN: Okay. What a surprise.
MR. HANNIGAN: One, they're dramatically different, by the way. There's a lot more changes, but that's beside the point.
Two, they seem far overreaching. And the way I'm reading it, it's like giving Dick Cheney back his shotgun and I rather not do that.
MR. CURRAN: Okay. Microphones remain open for this policy proposal. I'm going to leave the microphones up for another couple of minutes. Yes? Oh, one more participant?
MR. LEIBRAND: No, this is my own personal comment.
SPEAKER: Oh, goodie.
MR. LEIBRAND: Scott Leibrand, ARIN AC. Having been through the last couple days of meetings, I really want to caution us not to get rat-holed on too many details. This policy proposal's been around for a long time. And every single time we say this is a really great idea, but X, Y, or Z. I fully support the proposal. I think it should move forward. There have definitely been some issues, as there always are, when you try and get into details. But I think this needs to move forward and I support it as is and as it will likely be revised when it goes to the AC.
MR. CURRAN: Okay. We've got lots of people now. Far right.
MR. KNOWLES: John Knowles, Cogent Communications. Just one question. If this is passed and ARIN requests a review, how long do I have before I have to give it to them?
MR. CURRAN: It says you'll cooperate.
MR. KNOWLES: A year? Two years? Six months? Two days?
SPEAKER: As long as you're cooperating, I think you're get the time you need. That's an operational detail.
MR. CURRAN: I don't see it stated how prompt your cooperation needs to be. Okay? It just doesn't appear to be anywhere in the proposal.
Far -- oh, sorry, center rear.
MR. FARMER: David Farmer, University of Minnesota. I'll just add that that was a comment I gave Owen, that having a timeframe to respond in would be kind of useful just for -- as someone who might have to respond, knowing what's an appropriate timeframe. So that I can -- if I need to respond in 15 minutes, I can build the system that I can respond in 15 minutes, or if I have two weeks, I might be able to do it in a more manual way.
But that was beside the point. That wasn't why I rose to talk.
I think this is an important proposal. I think it really does clarify a bunch of things and what the community's expectations on ourselves is and on ARIN. There's a bunch of things I could quibble with, but I think I support it as written and there's some changes that can be modified later.
One of those that I think is an important change to come is there's sort of an implication here that you can keep the resources you've got that aren't necessarily in use until ARIN comes knocking on the door. I think it's -- with IPv4 exhaustion, there's been folks that have said, well, there's nowhere in ARIN policy that says I have to return it. I disagree that that's what it says, but I would -- but it's -- that issue needs to be plain as day and jump out and bite you that should return any resources you're not using to current standards.
MR. CURRAN: Okay. Just I want to ask --
MR. FARMER: I support the proposal as written and it should move forward.
MR. CURRAN: Are you advocating that the AC embed that "should be clear as day" statement about returning unneeded resources in this when they consider it? Because I do not know if that's received --
MR. FARMER: I would love to see them do that, but I don't think that's necessary.
MR. CURRAN: Okay. I also do not believe it's received a sufficient discussion to go to the AC as a footnote, so I just want to administratively.
Okay, far left.
MR. TEMPLIN: Pete Templin, Texlink Communications. Scott, I want to kind of comment on what you just said. Yes, this looks like something that should be brought to a close. But as you can see, in this room it's a moving target. And there's some inconsistencies in how folks are approaching this that we need to stop, so that we can settle on something, so that we can vote on it and move it forward.
And to answer the usually question, I don't know exactly what I'm in support of. As a first-timer at ARIN, I didn't realize how much homework I should have done to prepare and be able to analyze these differences and track the stuff going forward.
MR. CURRAN: Interesting answer.
MR. LEIBRAND: I just will make one comment that you have elected us as the ARIN Advisory Council to do this hard work for you. If you support the policy proposal generally, please make that clear and we will do the work necessary to make sure that the appropriate level of discussion occurs and that any minor changes get incorporated as they should be.
I understand that having 200 people do this kind of work is a little bit less efficient than having 15. So if you're in support of the general proposal I would say that we should move it forward and figure out the minor details.
MR. CURRAN: Do you know if you're in support of the proposal?
MR. TEMPLIN: I believe so. It's just a little too wishy-washy.
MR. CURRAN: Okay, thank you.
MR. TEMPLIN: I don't read this kind of stuff and deal with this kind of stuff as a regular part of my job, so it's just not a skill I've practiced.
MR. CURRAN: Got it. Bill, you wanted to respond directly? Bill.
MR. MANNING: Just very quickly.
MR. CURRAN: I am closing the microphones. You have a minute to get to the queue.
MR. MANNING: Scott makes an interesting point. You elected him and the other AC members and tomorrow is election day. If you don't like them, you have the opportunity to put new AC members into play, so please stick around tomorrow and vote.
MR. CURRAN: A wonderful point. It is true, elections are coming up. Please keep that in mind.
The microphones are now closed. If you're not in a queue, do not enter it. Center rear.
MR. POUNSETT: I have -- it's sort of similar to what Scott was saying. I have a comment to make. This is not on behalf of the Advisory Council as a whole, but just my personal opinion as a council member.
I would hope that anyone who thinks that this is better than what we've got now would, when we ask for a show of hands, be in favor of moving it forward. And if you've got nits and things you'd like to see changed to make it even better, then come see an Advisory Council member later and we'll deal with that stuff in the spring.
MR. CURRAN: Okay. Far right.
MR. POUNSETT: Right, yes, or last call if they're minor enough.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. This actually reminds me a little bit of an old phrase that sys admins used to repeat. The user would walk into the sys admin having just discovered from their friend, co-worker, or whatever that the sys admin can read their e-mail. And asks them, you know, do you read my e-mail? To which the sys admin's response is why would I? I have better things to do with my time.
Igor is a nice guy. I think he comes back to ARIN every now and then. I think ARIN staff has a real good relationship with him. I don't think they're going to be real eager to go audit Igor, whether it's 6 months, 2 years, 10 years. I don't think there's any value to us as a community. I think a lot of people are worried about ARIN coming and auditing them, but they're people that are already talking to ARIN on a very regular basis and for which there would be no reason to audit them.
What I want people to keep in mind, there are many people who have documented that there are, for instance, legacy net blocks out there that were allocated, that are no longer in use, that the organization has gone for, and that maybe still have a person's name on it. And that in several cases were someone to merely contact the person they would say you know what? That ended 10 years ago, just get rid that. And that would be space back in the free pool. It would be an incorrect record out of WHOIS and would be a gigantic leap forward. And I have confidence that ARIN staff will start with the low-hanging fruit.
We're all, on some level, lazy and want to get the most benefit from the least work, right? That's a lot better than going to Igor and asking him to document every single IP that he's ever used and what he's used it for. So I think a lot of the worry that ARIN's going to be coming back and beating on you every six months or two years or whatever it is for all of your data is just a little unfounded.
MR. CURRAN: The microphones are presently closed. Heather, do you have a point of order?
MS. SCHILLER: Just a comment just to what Leo said. He said -- yes, it's a point of order. The version in the book says only resources under RSA. The version in the paper says all of them. So just to be clear, the legacy holders, because we're only talking about this version, legacy holders are not affected.
MR. CURRAN: Thank you. And final comment, far right.
MR. GASHINSKY: Actually a question. If we vote to move ahead with this, will the AC clarify what is meant over here without getting the community involved?
MR. DeLONG: If the AC moves this forward, then a finalized text would be posted to last call.
That is the standard policy process.
MR. CURRAN: Right. And whatever comes out -- whatever the AC decides to advance goes to last call, always. Thank you.
I'd like to give a big round of applause for Owen for standing up here.
MR. CURRAN: Oh, yeah. Okay. In addition to being able to participate in this process, the AC occasionally asks for a show of hands and we're going to get a show of hands from the room. And we're going to get it on Policy Proposal 2007-14, the Resource Review Process, the August 14th version as published in your discussion guide and on the web. For remote participants, that's the August 14th version, which is on the web. I'm going to ask for a show of hands of everyone in favor and then I'm going to ask for those opposed. My polling mechanism is in place.
Everyone in favor of Policy Proposal 2007- 14, Resource Review Process, raise your hand. Nice and high. One hand, nice and high. Thank you.
All those opposed to Policy Proposal 2007- 14, raise your hand. Right now, nice and high.
(Laughter) Thank you. Okay, we have the collation happening. Whir, tick, tick, tick, whir, tick, tick, tick.
I used to attend a conference where the moderator told bad jokes. I could do that sort of to kill the time while we're up here. That was a long time ago and usually only at the beginning of each -- right. I remember some of those bad jokes.
Okay, number of participants from in the room and remote, 114; in favor, 32; against, 5. This will be sent to the Advisory Council for their consideration. Thank you.
Back to you, Ray.
MR. PLZAK: Do I have some slides? Anyway, take a break. We'll be back here at 3:45. That's one half-hour from now. And no code words to go with the Cyber Café this time.
MR. PLZAK: Do you want to go ahead and go?
SPEAKER: We have a presentation, right?
MR. PLZAK: Two.
SPEAKER: Yeah, we should go.
MR. PLZAK: Okay, before we get started, if you recall yesterday morning when I was talking about remote participation, that we were going to have people asking questions and people could vote? Well, those things, as you can see, have happened.
I also said if you were remotely participating and if you were online, you could win.
Well, we have had an online participant win this afternoon.
So -- and the winner is Jody Huffines from -- I hope I pronounced your name right, Jody -- from Verizon Business. And you won some astronaut mint chocolate chip ice cream. If you are watching the webcast, here it is. It will be mailed to you and you will get it in the mail. So, congratulations. You are the first one and, no, I'm not going to give it to one of the Schillers to deliver it, because I don't trust you.
MR. SCHILLER: She is not in our location anyway, so she's (off mike).
MR. PLZAK: Then I really don't trust you.
SPEAKER: Yeah, their business units get --
MR. PLZAK: Okay. So, anyway, it will be to you -- the check's in the mail. How's that one?
Okay, so we've got two reports. The first one was one that was supposed to occur before lunch.
Axel, if you are prepared, would you please come up and give the update from the RIPE NCC?
MR. PAWLIK: Hello, I'm Axel from the RIPE NCC. A short update of what we have been doing the last year and what we are going to do for the rest of it, and some planning for next year, also.
So, a few things that we agreed to talk about in Berlin -- that's so, so long ago and we have the next one is coming up in 10 days. In any case, I'm happy to say again, that was the biggest meeting we've had so far, with over 400 people from 64 -- no, 46 countries. Well, we're working on the 64.
Focus, obviously, is similar to here -- what do we do with v6 and what do we do with the remaining v4? And we have a quite number of policy proposals, similar to you, that we'll talk about in 10 days time, and that are currently being discussed, also, on the mailing list.
Certification, we had the certification task force, which is a bunch of our members helping us think about this, and how to do this so it doesn't hurt them in terms of the business process, and the like. And outreach -- coming from the (off mike), there was this (off mike) corporation. We had a task force and we have agreed, finally, to have a corporation working group, and I'll talk about that.
We had a general meeting. They're always very exciting, especially in the beginning of the year. We'll have elections there. We had more than 200 votes. That maybe doesn't sound so exciting, but we used to have like 14 when we had GM separate from RIPE meetings. Now we have them together for a couple of years. People actually do come and take part properly. We had a differential report adopted, the Board discharged, and we had new Board elections, which might make it quite interesting.
We have this arcane process that goes whittling down the candidates to -- until there are just a very few left and an absolute majority for one of them. Now with seven candidates, you imagine it can take quite a while. We had one or two open seats, so balance the whole thing. We had four rounds, and then we had five rounds for the remaining seat to be filled. And you might have seen some of these guys this week: Andreas and Fahat are the new ones. And they have been here, or are here still, Andreas is. And Guillermo says, hello. He couldn't come this time.
We have also had, for about two years now, workshops with our bodies, one or two days preparing ourselves and our thinking for the time to come or the time that's already here now.
Basically, looking at what RIPE NCC should be doing after we run out of IPv4. (off mike) and, of course, how to deal with that situation. Basically, to insure stable development of the organization during interesting times, and for the benefit of all members.
Looking at that, we've identified three areas of attention -- of strategic areas. One is to explain the role, and to develop the role of the RIPE NCC further. Basically, it's community building. Getting new faces into the RIPE community, but also reaching out to new people, or not so new people, anymore, like governments and regulators, these people. Trust (off mike) of data, obviously. And we've seen some of the discussion here as well we have a database. We have the registry and we are responsible for that and we will remain responsible for that, so we need to make sure that that stuff is up to date. And remains up to date, regardless of ongoing changes.
Similar there -- what we call now numbers as life cycle management. It's beyond just handing out address space. It's also tracking it, seeing how it devotes, how holdership -- usership evolves.
Basically, also, a bit of reclamation where it's appropriate and possible. And certification goes with that, as well. So, those three main areas we are focusing on and we try to insure that everything that we do falls into that somehow.
So, apart from that, I'll go through them, just to --
Certification, the main news here is that we have proceeded quite -- oops, too many buttons -- that we proceeded quite nicely with what we have been doing there. We will widen the very small membership of the task, because basically we would do a test bed, that we will announce in 10 days time, roughly. And we still have plans to deploy the whole thing for all of our members in 2009, and it currently looks quite good. And, of course, we are working together with the other RIRs, also ensuring the profitability of the various systems that we have.
Obviously, development support, 2007-1, actually seems to go ahead. That was the policy that says that PI holders should be having contracts, so we can track them better. Contracts, either with ourselves or members of ours, who assigned resources to them. And there was quite a bit of back and forth because this falls into a funny area between policy and operations of the RIPE NCC, and financial and contractual stuff, but we are getting somewhere there. The last comment period closed last Tuesday, and we expect that this will go ahead. Of course, we have prepared for that in- house, as well.
2007-8, our transfer policy, is in review phase. We have a quite lively discussions, again, over the last two or three weeks, again, on the mailing list. It was a bit quieter before, and maybe, maybe we even have some developing consensus there, which would be great. And we will see, in 10 day's time. Information services, you know most of them already. We are trying not to look at this as data that is available but, actually, as some sort of a service that can be bundled and pushed. We are currently thinking of branding this or developing some branding there together with external help.
Membership, we -- that's a bit touchy. We expect still to have just over 6,000 members at the end of this year. And we've very nicely pitched the budget for next year to our Board, showing them how our new membership -- streaming in -- does very closely track the NASDAQ index. And I look at this, this morning, so I am not quite sure that I'm -- in any case, you know what I mean.
Growing quite nicely. We have regional meetings, as you know, typically in Moscow and also some in the Middle East. We were in Kuwait in April. We are, basically, just back from Moscow -- that was a really big one -- with 960 people there.
And it's developing, a little bit, into an operator's group meeting, maybe, even, if I dare say that. And then, of course, it already has happened in the Middle East. We have men out there and the next RIPE meeting will also incorporate a bit of MENOG activity there, in terms of presentations from the region. Very nice.
And we have a membership survey that we wanted to do for quite a time. We have now gotten through all of the questions and the vetting group.
And now it has started. I think I received my mail, to fill it in, yesterday. Of course, I won't fill it in. I hope that our members from this region will do so, however.
PR and outreach. We did hire a PR agency. That's something we tried to do for a long time, PR and the like, but we are geeks in the end and we are not so good at that. So we found a very nice agency in London, RacePoint. They are geeks who have developed further than we are at this time. They understand what we are doing. They understand the industry and they're actually quite good and they have helped us quite a bit. (off mike) update contains ASN's -- (off mike) -- oh well, they're not fully supported by the vendors yet, stuff like that.
We went to a (off mike) for the OECD administerial meeting with lots of support from those RacePoint people. That was quite successful.
We helped AFRINIC with the IT Telecom in Africa. We, together with APNIC, we helped there with the TelecomAsia thing. Basically saying, helping them is giving some support from the RacePoint folks, just to keep us all nicely in shape and lined up. And I mentioned information services is spreading. That's something we are now starting also with the PR agency to help us.
How is that done properly and what are the messages that we want to put forward?
Announce cooperation, if we want to say that one more time. We have a RIPE corporation working group now that resulted from the task force that I mentioned earlier. It's chaired -- or co- chaired by Maria Hall and Martin Boyle, both of them from government circles. Martin is now private -- a private company, (off mike).
In the U.K., the domain registry, those people know us for quite some time. They were about the earliest, and most consistent participants in our round tables that we do, once a year, sometimes twice a year. We did another one recently which was quite popular, and also brought quite a number of law enforcement people there. Along with government, and regulators, and probably law enforcers.
As be a separate user group, if you want to say that. It was quite popular and now we are going to do those things two times a year. Paul Rendek hates me for that because it's more work, but it's also good to reach out to those folks. Yeah.
IGF is going on -- it's sort of closing on which workshops and which main sessions are incorporating what. It looks fairly benign, at this point and time. But, of course, we'll go.
Also, we'll go to Dubai and you are, of course, invited to come. We try not to kick up a sandstorm. It looks like a sandstorm to me. It will be nice and warm outside, similar to here. It does start on a Sunday and, yeah, soon.
Afterwards we go back to Amsterdam. We had thoughts about maybe not doing that because the hotel was supposed to be renovated. They haven't even started that, so it's just as well we can go back to Amsterdam because it's nicely around the corner and some people do like it.
After that, I don't really know yet. I am not as advanced as Paul Wilson is in terms of telling you where to go in 2011. I leave that to one of the following meetings. If you have any questions? You're welcome.
MR. PLZAK: Any questions? Thank you, Axel.
MR. PAWLIK: Thank you.
MR. PLZAK: Thanks, Axel. I'm glad you clarified about how it -- the relative advancement between you and Paul. I am also curious about all of the police hanging out at the NCC, too.
MR. PLZAK: The next report is the NRO Numbers Council report and it will be presented by Jason Schiller, one of the three members of the council.
MR. SCHILLER: So, I know I stand between all of you and the open mike, which you are excited to get to, and then the beer which follows it, so I'll go quickly.
Who are we, the NRO? NC, the ASO AC? Myself, Louie Lee, who's the chair, and Martin Hannigan, who was just reappointed. The NRO NC is, basically, a collection of the five RIRs who have come together to make the NRO.
There's the Executive Council and the Number Council. I sit on the Number Council. And what does the NC do? Well, we appoint seats nine and 10 to the ICANN board. We also appoint a representative to the NomCom, and we process the global policies that come through all five of the RIR's, and certify that the process was open and correctly followed. We also offer advise to the ICANN Board, when they ask for it, and make our own procedures.
So, what's happened recently? Well, today Marty was reappointed to the NRO NC. We've also had a new member elected -- Naresh from APNIC. And Francisco was re-elected from LACNIC. We also had the global policy for the allocation of the ASN blocks to the regional internet registries.
This is the 16-byte ASN policy that was unanimously ratified by ICANN. We had the meeting in Paris and we also appointed Hartmutt Glasser to the NomCom. He was on it last year.
What is coming up? We have the global policy for the allocation of the remaining IPv4 address base. This is the N equals 1 policy. RIPE recently accepted this as a policy through their community. So, our global policy proposal facilitator team will be picking this up shortly and sending this up to the ICANN for ratification.
We've also have got the ICANN meeting in Cairo coming up.
I would like to thank a few folks. Ray, for all of his support. John, for all of his advice. And the entire ARIN Board for all of the time that they give us. Einar, for the fantastic job he does with all of the global policies; keeping everything sorted and easy to find. It makes my life much easier.
And Therese for dealing with all the travel details, all of our late e-mails, and our incomplete paperwork.
Lastly, I just wanted to remind you all, don't forget to vote. This is not an election year for the NRO NC, it was an appointment year. But the appointment was made by the Board of Trustees, and those are the folks that you guys vote for.
So, don't forget to vote for the Board, don't forget to vote for your ARIN AC members. If you don't know who the designated member representative is, go to the help desk. They will help you out. Don't forget to vote. Thank you.
MR. PLZAK: Any questions for Jason?
MR. MANNING: Yes.
MISTER PLZAK: Yes, Mr. Manning?
MR. MANNING: They won't turn the mike on -- oh, okay.
So, Jason -- how often, with what periodicity, does the ICANN Board ask you guys for advice?
MR. SCHILLER: Generally, as a formality, they ask for advice every time a policy comes up, but they generally do not ask for any specific advice. In my year in the ICANN, in the one policy that we've sent up, they have not asked for specific technical advice.
MR. MANNING: Thank you.
MR. PLZAK: Okay. Thanks, Jason
MR. PLZAK: So, now we are onto open microphone.
Remember, this open mike is open for every one here, plus everyone remote -- that's online. Remember, the meeting courtesies and the rules of discussion.
And if you're not sure what they are, they're in your meeting folder. And so, now, I will now turn over to the Chair for open mike. And remember, this is only for policy related matters and does not deal with any policy that has been discussed the last two days. Nor is it for anything that has to deal with member type items, such as fees.
MR. CURRAN: Okay, we have open microphone. Please feel free, if you have a matter to be raised, to approach the mikes. As Ray noted, we don't discuss policy proposals that have already been discussed and been voted on -- because that's going to the AC -- and we save all the membership/organization things for tomorrow. But everything else is on the floor. So, Marla, second rear mike?
MS AZINGER: Marla Azinger, Frontier Communications. As promised when I spoke the other day, I put together -- well, actually, I wrote this document a little over a year ago. And then, thankfully, other people wanted to help last night and Jason was awesome, and helped a lot. So we actually went through and wrote a -- excuse me, I forgot the title of it, sorry, Active Amnesty and Reclamation Process. We did not submit it officially as a proposal yet because we actually want community involvement, in possible revisions, and what you want to see.
So we really, really want you to go onto PPML and find that e-mail. It came from my e-mail address, and if you could just give input we appreciate it because it is another way of going after the black market issue, and making sure that we keep IP addresses -- getting back -- put it back into the pool, and databases correctly kept up.
My e-mail is much more clearer than I am at the mike right now. Sorry. Thanks.
MR. PLZAK: Okay. So, plan to go online and provide comments for that. Thank you, Marla. Okay, mike's remain open. I recognize R.S.
MR. SEASTROM: Yeah.
MR. PLZAK: I believe you have slides?
MR. SEASTROM: Yes, we even have slides. Rob Seastrom, ARIN Advisory Council, It has not escaped our attention that people seem to like transfer policies and the policies in general that don't have a lot of extra stuff thrown into them, and that are simple, short, and easy to understand.
And this one is kind of similar to ones that are in other regions. And we figured we would put this up for some comment and some thoughts and see if there's enough people who think this might be a good idea, that we should turn it into a proposal.
MR. CURRAN: Right, so I'm going to set the context. Obviously, this isn't a policy proposal that is formal right now. This is these folks getting input from this room, so they can form a good one to put into the process, which will definitely come back to another public policy meeting, but --
MR. SEASTROM: Exactly.
MR. CURRAN: But -- you have the floor, go ahead.
MR. SEASTROM: Yes, we would like feedback from the room. I would like feedback from the room about whether you think this is something that could go? Next slide, please?
MR. CURRAN: Point of information?
MS. ARONSON: Yeah, could you define "we?" Because you're on the AC and I'm on the AC, but I'm not part of "we?"
MR. SEASTROM: Yes, you're not "we." I'm not speaking about the AC. I had a talk with Scott.
MS. ARONSON: It's the royal "we?" No.
MR. SEASTROM: Yeah, it could be the royal "we." I would certainly like feedback on this, but --
MR. LEIBRAND: As Rob mentioned, I'm another part of "we," so, Rob's speaking mostly for me, as well as --
MR. CURRAN: So R.S. and Scott -- yeah, okay, continue.
MR. SEASTROM: So, this is -- what you see before you is the entirety of the proposal. And the rationale would be that we need to be able to move IP addresses around between resource holders. And the larger it seems to be, the more difficult people tend to get bogged down in the details. And this preserves the need-based requirements -- this preserves the requirement to be under RSA. I can read it aloud, if anyone's having trouble seeing that, but I don't think anybody should have a problem seeing that. I would like to solicit comments from the floor?
MR. RHETT: It doesn't prevent me from finding a /8 and selling it.
MR. SEASTROM: It -- if I understand it, it prevents you from -- it doesn't prevent someone from releasing their /8 to you. It does seem to prevent you from receiving it, and using it under an RSA, unless you can justify the exact amount under the ARIN allocation policies.
SPEAKER: (off mike)
MR. PLZAK: Microphone?
SPEAKER: I think I can just --
MR. PLZAK: We have remote participants, so just respect.
MR. SEASTROM: I'll just address the question and restate it, as well -- or concern. Which I think is that you -- not having a /8 -- could transfer one that you don't have to someone else. Is that correct?
SPEAKER: (off mike)
MR. LEIBRAND: Microphone -- okay. My response to that would be that -- by any authorized resource holder requires that you be the one who has that address. So, if you still think that's an issue, you can get to the mike and discuss it, but I don't think it is.
MR. CURRAN: So, your implication is that authorized (off mike) holder includes a level of validation by ARIN.
MR. LEIBRAND: Yes, this --
MR. SEASTROM: If I can address that?
MR. CURRAN: Sure.
MR. SEASTROM: The specific counter measures against fraud that would be undertaken to deal with this are not at all different from the specific counter measures against fraud that are already taken by ARIN staff every day. And I believe that that's an operational matter that's outside of the purview of the policy process.
MR. CURRAN: Okay. The floor is open for comments. Yes, far right?
MR. DeLONG: Owen Delong, ARIN AC. The problem I see with this is that under current ARIN allocation policies, I can easily justify a /32 and so can anybody else? And so, if I can find enough people that can justify /32s, my /8 can become a really big number of prefixes.
MR. SEASTROM: And you could certainly try to announce a /32 into the routing table right now.
MR. LEIBRAND: Another response for that would be that this requires that you be able to justify, under ARIN resource allocation policies -- which, to my reading implies that minimum allocation size, and everything else, apply to recipients in space under this policy, just like any other policy.
MR. CURRAN: R.S., you're also a tome author of this brief tome?
MR. SEASTROM: Yep. I agree with Scott. I mean, there's no reason to think that unless you were -- that you would find a large number of people who would be able to do /24s for critical infrastructure, let alone /32s, and there's nothing that I am aware of that would allow you to qualify for /32 to be issued. You can certainly justify one.
MR. DeLONG: Owen DeLong, ARIN AC. It is certainly open to interpretation, but as I read the ARIN resource allocation policies as they exists, there are distinct parts that refer to justification. And there are other parts that refer to minimum allocation units. And this would incorporate, by reference, the parts that refer to justification, while not necessarily incorporating by reference the parts that refer to minimum allocation units.
MR. SEASTROM: That's the second to last word on that slide.
MR. DeLONG: Allocation policies?
MR. SEASTROM: Yeah, it does in fact refer to the current allocation policies.
MR. CURRAN: So, your intent is that it would meet the minimum allocation side presently?
MR. SEASTROM: This is an addition. This is not intended to stand on its own without referring to the entirety of the NRPM, as it currently exists. Right.
MR. CURRAN: Okay, good feedback. Far right?
MR. DURAND: Alain Durand, Comcast. A point that was made yesterday by, first, Randy and then me. Let's say that I need and qualify for a /14. I can't get a /14, but I could get four /16s from other people. It seems to me that this policy will bar me from getting those resources, correct?
MR. SEASTROM: That is correct, the way it is written. Now, of course, you could certainly wait for one to become available. Certainly, we expect there to be some /8s available. But, yes, that is correct. And there are not as many /8s as there are /16s, so you would not expect to see that problem with /18s and /20s, the way that you would with a /14, but, yes.
MR. DURAND: Well, I do not share your optimism of large blocks being available.
MR. SEASTROM: I frankly have no optimism about IP addresses being available at a certain, point at all.
MR. CURRAN: Okay. Other comments or feedback to the team on their potential policy proposal? Yes, far left mike?
MR. CASSIMIRE: Nigel Cassimire, CTU. For more clarification, I'm not sure if I missed it. Does this proposal --
MR. SEASTROM: This is not a proposal.
MR. CASSIMIRE: Sorry.
MR. SEASTROM: This is -- they're simply seeking input over a potential future proposal.
MR. CASSIMIRE: Does this -- what should I call it? I'm not sure what to call it -- potential proposal -- have any limitation on the number or size of the transfer? It could be one. It could be as small as one IP address, or what?
MR. SEASTROM: It refers to ARIN resource allocation policies. So, you would be expected to qualify for a certain amount of IP addresses, just as you do today, a certain prefix length. And except under fairly extraordinary circumstances, that's not longer than a 22 or 23, depending on where you are.
MR. CURRAN: You wouldn't be able to obtain a block via this process that you wouldn't be able to obtain via ARIN, presuming it had the resources.
MR. CASSIMIRE: I understand. I just wonder, maybe, if you wouldn't want to put in something like -- in ARIN resource allocation policies, including minimum whatever, you know?
MR. SEASTROM: That's correct. It does not change those.
MR. CURRAN: Okay, I'm going to be closing mikes on this presentation. If you want to speak to this, please approach the mikes, because we do have other topics that we may have come up in open mike.
Okay, last chance to approach the microphones. Okay. I'm closing the mikes on this topic.
So, in order -- yes, rear back?
MR. WILLIAMSON: David Williamson, TellMe Networks. Obviously, we haven't had a lot of chance to really reflect well on this, but I really like the brevity. It certainly adds to the understandability. I think I'm hesitantly in favor of this sort of thing that (off mike) the proposal.
MR. CURRAN: You're referring to the white on black format?
MR. WILLIAMSON: The white on black is wonderful. It's a nice font choice, too.
No, look -- the one thing I see that seems a bit of a concern -- there's a lot of complexity in 2008-2, trying to address avoiding the markets springing up and art officially inflating pricing, if you will. There doesn't seem to be any limitation in here that would avoid the creation of a speculative market which, frankly, may or may not be a good thing. But I'm sure there are people that are concerned on that. I don't know if either of you have comments or ideas about how that may or may not be handled?
MR. SEASTROM: Only, that in this current climate, I think that everybody is acutely aware that you speculate at your peril, and I don't see any way to short selling, or anything else. It's basically accumulating --
MR. WILLIAMSON: Sure.
MR. SEASTROM: -- and hoping that things work out. And I am sure there will be some of that activity no matter how we try to avoid it.
MR. WILLIAMSON: Fair enough.
MR. SEASTROM: Okay? It is my sincerely hope that anybody tries that, loses their money.
MR. CURRAN: Also, rear mike?
MS. ARONSON: Hi, Cathy Aronson again. I guess I'm just -- I know it's so short and sweet, and that's great, but it doesn't really say who you have to justify it to. So, I could easily say to somebody, well, I have this RSA, and I have this address base, and they could justify it to me, and I could give it to them. I mean, it doesn't say you have to justify it to ARIN or to --
MR. SEASTROM: I think that's sort of implicit in all of the proposals that we have ever had -- that you're dealing with ARIN analysts or something.
MS. ARONSON: But those kind of say it. You know, there's like a certification, or a -- so anyway, I --
MR. CURRAN: Okay. Does either of you to -- Scott --
SPEAKER: You know it.
MR. CURRAN: -- or that would be fine? Okay. You're fully responded? Okay, over here? Mr. Huston?
MR. HUSTON: Thank you, Mr. Curran. Geoff Huston, APNIC. What I was saying this morning was that the reason why we had sort of drafted the way we -- I had done it at APNIC, was that I didn't believe that a registry was actually, as a registry function capable of carrying the burden of a regulatory overload. The allocation actually had the regulatory part and that a registry, like any title office, thrived when it was neutral. If I look at this, I find it a bit wordy. And, you know, the first paragraph kind of works --
MR. SEASTROM: Well, I considered deleting every other word, but I thought it might detract from the readability.
MR. HUSTON: Well, let me help you, once you get to the word RSA, put a full stop. Stop trying to carry a regulatory overload in a registry function. Because by the time you're getting into this, there's no more allocations. There's no more, if you will, resource allocation policy because, in v4, there aren't any.
So, what you're really saying is, when these things move around, you would like them to be under an RSA, to know where they are. That's it. The RSA says, if I get some from you under this, the RSA places burdens on me that if I ever come near ARIN for any reason -- I don't think they've got any addresses, so I am not sure why. But I'm covered under the policies, no matter what. I've signed under the RSA. So, what you're trying to do, I think, is perpetuate what by then is history.
There are no resource allocation policies when you have no more to allocate. So, as I said, my gentle suggestion is -- you've got 1, 2, 3, 4 -- you've got about 13 too many words.
MR. CURRAN: Thank you, Jeff. And final comment, center rear.
MR. RHETT: Jo again. So, the issue I had with the source is that -- and this may be over weighed -- I don't like the idea that a legacy holder can come get a whole bunch of money, put a lot of load on ARIN, without coming to play ball. However, I'll put that aside and the fact that all those resources become RSA members. I find myself violently in agreement with him. Why don't you just say, "under current RSA policies?" You could probably drop the entire last -- every word after RSA.
The only other thing is, as we've stated in other proposals, you really should mark this that this policy becomes effective only when ARIN no longer has the ability to issue the same-size resource.
MR. SEASTROM: Why, on the last point?
MR. RHETT: Because you are creating a market now that doesn't need to exist.
MR. SEASTROM: I don't know that there's any market associated with this at all. Whether or not money changes hands in this, is completely orthogonal to the question of whether addresses can change hands.
And, in point of fact, there are many people in this room that, if they came to me and asked for one of my /24s, and they had a reasonable project that was for the good of the Internet, I would simply transfer it to them, with no money. And I think that there's a lot of people in this room that are like that.
So, the notion that you're, by definition, creating a market here, I think is incorrect.
MR. LEIBRAND: I'll take the opposite angle on that. This is Scott Leibrand, ARIN AC, speaking for myself. It seems to me, like if we're trying to say that our policy doesn't enable a market, we're deceiving ourselves. And I don't think Rob said that. But just because a policy allows a market, if there is no financial incentive for a transaction to take place, it won't. If there's -- if ARIN has addresses to give out and the conditions under which you can transfer addresses are the exact same as if you get them under ARIN, but the only difference is you have to go find somebody to give it to you. Most people are going to go to ARIN. So, I see that as a really small, corner case, not likely to be a problem.
So, if you can tell me why that would be -- why there would be significant supply and/or demand for those addresses prior to exhaustion. And secondly, why that would be a problem. I'm all ears. But I don't see it.
MR. CURRAN: You're saying the circumstance creates a non-problem. Do you want to respond, Jo?
SPEAKER: Well, I'd like to sort of touch on the -- I'm not Jo.
MR. CURRAN: He's first. Jo, do you want to respond to Scott's point?
MR. RHETT: Really fast. I would say that when you're standing here, it's easy to think that everybody knows how easy it is to get IPs from ARIN.
I mean, I meet people with significant amounts of address space who are clueless about this. And people that have justifiable demand need, that I help them fill out the paperwork on a fairly regular basis. I don't think the clue level of how easy it is to get from ARIN exists. And I think the people who are selling that, would tap into it.
MR. LEIBRAND: Well, those people still have to go to ARIN to get their justification, so there will be a contact with ARIN, if this is --
MR. SEASTROM: Frankly, it sounds like insulting opportunity.
MR. CURRAN: So, first we have Bill next in order, but I see Mr. Hannigan in back. Unless it's a point of information or a direct query, Marty, because we've closed the mike.
MR. HANNIGAN: Oh, I'm sorry. I didn't hear you close the mike. It is a point of information.
There really is a market. If you want to learn about it, come and see me afterwards. I'll explain it to you. I'll tell you how much money is involved. It's real. Just stop saying it's not real, it's here now.
MR. SEASTROM: That wasn't an offer to sell, right?
MR. HANNIGAN: No, right.
MR. SEASTROM: Just checking.
MR. HANNIGAN: Isn't that the disclaimer at the bottom, this is an offer to sell securities in any place needing registration?
MR. CURRAN: Okay, Bill, you are also the last one in line, go ahead.
MR. MANNING: Okay, I didn't think that was an offer to buy, either. So, a number of resources may only be received under RSA. I'm thinking the Republic of South Africa probably doesn't want the obligation of holding all of the number space anymore, so.
MR. SCHILLER: Clarifying the RSA is helpful, Geoff.
MR. HUSTON: You're saying it can be too brief, got it.
MR. SEASTROM: I think that it probably doesn't require, actually, any clarification. That once it's integrated into the NRPM, I think it will be pretty self evident.
MR. CURRAN: Okay. All right, thank very much.
MR. SEASTROM: Thank you.
MR. CURRAN: Oh, wait, you have one more slide, don't you?
MR. SEASTROM: No.
MR. CURRAN: Okay, thank you. Microphones remain open. Open mike period. This is the opportunity to ask questions, raise issues, concerns? Yes.
MR. FARMER: David Farmer, University of Minnesota. I've been perusing the NPRM, and I think I got the acronym the right way around, but -- I mangle acronyms. There seems to be -- for IPv4 address spaces there is end user allocations and policies about the end-user allocations, a policy about ISP allocations. I was wondering if it would be helpful if there were some policies about legacy allocations? And they would need to be very carefully worded, but reading the legacy RSA there's kind of an implied policy in there already. And that is that ARIN is requesting that legacy holders review their need, and return anything beyond their 10-year need.
That kind of sounds like a policy to me or, at least, a request. And maybe it would be worth putting in the policy, where it's easily found. And I think there could be a handful of other related kind of things about legacy space that could be stated in clear and concise manner that makes the community's expectations clear to legacy holders.
MR. CURRAN: Okay. A couple of quick questions. Are you saying some of the implied policy in the legacy RSA should be duplicated in the network resource policy manual? Or occur only in the network resource poly manual?
MR. FARMER: I think probably duplicated, because I believe some of the particular pieces in there need to be in the contract, as well. Just like there's certain pieces of policy issues in the regular RSA, as well, that need to be very clearly stated in contracts.
So -- but more of what I was trying to get at is that I think there's some of these things that we could -- as a community -- clearly state what the expectations on legacy holders are, in the current -- as we're approaching exhaustion.
There's plenty of places where we've said certain things in prehistory, and in all sorts of RFCs, but there's people in certain legacy holders -- like at universities that are rather young'uns, and might not even have ever seen some of those old RFCs. And so, having freshly updated policy on that would be -- you know, I think it's something we need to do.
As I mentioned earlier, I think there are certain things that we're going to need to start saying plain and clear, and they need to jump out of policy and bite you; that this is what you're supposed to be doing. Particularly if we're going to expect people to do them.
And so, I'll take any comments from anyone. And, if you're interested in helping me work on it, please find me.
MR. CURRAN: Okay. Response or a new topic?
SPEAKER: New topic.
MR. CURRAN: Okay. Anyone else for this? Seek him if you want to provide feedback.
SPEAKER: I hope he was referring to me when he said "young'uns" in the university?
MR. CURRAN: Young'uns in the university, yes. Anyone who'd like to work on that, please find him.
SPEAKER: Okay, go.
MR. DARTE: So, I'm Bill Darte and I'm on the ARIN AC. And there's an emerging new IRPEP -- policy evaluation process, apparently. And I was wondering if -- I know Scott Bradner is sort of railroading this, and he's not here, but I wondered if anyone on the Board, or you, could provide some input to the community about the status of that, and the intention of that, and the timing of that, particularly as it relates to policies that are in the works now?
MR. CURRAN: Right, so we talk about the revisions to the IRPEP at the last meeting, and we did not pull the trigger on the new IRPEP because we had existing policies, and were coming up to this meeting, and did not have -- did not want to undertake the process of changing the status of the existing policies to follow the new IRPEP process.
But let me describe the significant difference. The most significance difference in the new IRPEP process is that the advisory council is more of the owner of the policy proposals, once they are proposed, and that they're responsible for running with them, disposing them, merging them, discarding them.
There's, of course, an appeal process at every part of the way, so the author could continue despite not having the cooperation of the AC. But the AC truly owns the policy proposals.
We felt it was appropriate to get through this meeting and see where the AC is on the policy proposals at the end of the meeting, and then we would put the IRPEP in place, the revised one, and set all the proposals at the right phase, accordingly. It is -- because this IRPEP has already been presented to the community, it's just a question when the Board formally decides to adopt it and, we work with the staff to make sure all the policy proposals end up on the revised IRPEP, in the right box.
So, it will happen shortly after the meeting. And, of course, the AC has been instructed to begin thinking of their new-found freedom. When we were talking about proposals today and yesterday, we noted that the AC does have remarkable freedom to work on the policies, even as it is. We're now encouraging them to use the freedom they have, even under the existing policy.
So, we will be switching over formally shortly. But for all practical purpose, I expect the AC will work on policy proposals, take the input from this meeting, and make use of it as best they can, starting immediately. Does that answer your question, Bill?
MR. DARTE: Thank you.
MR. CURRAN: Sure. Any other questions? This is open microphone. It's your shot to ask questions of ARIN, the Board, the AC staff. No? Any good IPv6 jokes? No?
Okay, seeing no further, I'm going to close the microphones. This includes the remote participants. I'm closing the open mike session, momentarily. Microphones are closed. Thank you very much. I turn it back to Ray.
MR. PLZAK: Thanks, John. I guess we'll have an IPv6 joke hour tomorrow.
First of all, let's thank our sponsors, CGR and Los Nettos.
Remember, the consolation prize is still out there. Remember, those of you that are participating online, that you will be eligible for the consolation prize, if you haven't won anything, and you participated, and you fill out the survey for the your feelings regarding the meeting. And the same thing for the persons that are in the room, here. If you are not going to be here tomorrow, make sure you fill out the meeting survey. The winner will be announced on the 27th of October. It will be an 8-gigabyte iPod Touch.
Some reminders: Breakfast is tomorrow at 8:00. The member meeting, which is open to all, begins at 9:00. The agenda's in your meeting program. Remember, immediately following this meeting, we'll have the secure login demo. And we just recently introduced this Secure Login, so if you want to see it in action, this is the place to do it. And with that, I will see you in the morning.