ARIN XX Public Policy Meeting
Day 2, Draft Transcript
Thursday, 18 October 2007

"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."

Meeting Called to Order

MR. PLZAK: Good morning.

SPEAKERS: Good morning.

MR. PLZAK: Okay. Actually, before I do that I do want to extend our sincere apologies for not being able to control the weather. And we'll get better at that. So -- but, I think we did have a good time despite cold, and wind, and so forth. So, anyway, onto this. The -- Bill Gates just gave me a fanfare some place. The Number Council winner -- the election winner, is Jason Schiller. (Applause)

MR. PLZAK: So, Jason, I'm duty bound to ask you, will you accept this role? (Laughter)

MR. PLZAK: I don't need a speech. You can just nod your head violently.

MR. SCHILLER: Yes, thank you.

MR. PLZAK: Okay. You now have an appointment for lunch that you didn't have before. (Laughter)

MR. PLZAK: And you'll contacted by, probably Einar, and he'll give you the details. Okay? So congratulations. And also, at this time, thanks to all of the other candidates who ran for office. We only have a good election if we have good candidates, and we had a very, very, good field of candidates this time. So, reminder about the CyberCafé, price wheel is working and running hard. And don't forget, you got to complete the raffle forms, the survey forms to be eligible, spin and win. And if you don't win, you get to go for the consolation prize, which is the biggest surprise, if you haven't paid attention to what's going on. Remember, we have all the health house opened and now, because of the upcoming elections for the Board and AC, the election helpdesk will now be open to handle questions in that regard. So -- and if you haven't been to the AC desk, please go there. They would like to talk to you. Don't forget, you need to complete the meeting survey and not only do we have one prize, we got two. Thanks again to Shaw Communications for that. (Applause)

MR. PLZAK: And I put the rules slide back up here. John, I think must say a few words.

MR. CURRAN: Sure. Yesterday we were a little relaxed in our handling of the meeting. People pointed out that we have nine policy proposals today, so I would point to everyone in your packet you'll actually find some standing rules for how we run the meeting. They include such things as identifying yourself. They include that you address, you don't have personal attacks or personal responses. You address things to the meeting, or to the Chair. I ask everyone get up once, say whether you support or oppose the proposal. Talk about any specifics you'd like, and that you not find the microphone again until you see that everyone else has had a chance to speak once on the issue. This allows everyone a fair shot. We had some cases yesterday, where I'm not sure everyone got a chance to have their say, because we had some folks who were frequent microphone members. And so, we just want to make sure everyone has a chance to have their say before people go back to double dip. If there are any other questions, as I said, the guidelines are in your information packet, and we're going to run this one very fast and very tight. I will be enforcing a strict 3-minute timer. Okay? At the point, if you're still speaking at 3 minutes at the microphone, I will say please wrap up and I ask you at that point to wrap up briskly. Thank you very much.

MR. PLZAK: Thanks John. Sponsors, One Connect IP. (Applause)

Statement from Sponsor

MR. PLZAK: And of course, you. We couldn't do this without you. And so now, a word from our sponsor. And here comes John.

SPEAKER: Good morning, John.

MR. OSMON: Good morning.

SPEAKER: Good morning.

MR. OSMON: Good morning, everyone. Welcome to Albuquerque. Hope you all are having some fun. I'm going to get out of the way. I almost didn't make it here. No one explained to me that as the host you actually end up doing your real job, taking care of your family, and trying to do all of this at once. So, we're a little late this morning. No prepared remarks. I'm hoping everybody is enjoying themselves. I hope the network is working well for you and One Connect is glad we're able to help out sponsor you guys to take care of things, and let's get some work done, and try and make the Internet a better place. Thanks.

MR. PLZAK: Thanks John. That was one of the better sponsor's speeches I've ever heard. (Laughter)

NRO Activities Report

MR. PLZAK: And so, now I'm with the show. Okay.

SPEAKER: (off mike)

MR. PLZAK: Well, yeah. Okay, we don't have the displays up here. I know but there is nothing. Okay, anyway. I do not have slides for this. I do not do PowerPoints for a lot of presentations these days. And so, I'm now actually at 9:15 in the morning, which is the NRO activities report, and I'm going to give you a brief summary of what's going on. First of all, this year, it's been my honor and privilege to serve as the chair of the Executive Council of the NRO, and primarily the NRO has been concentrating on two things this year. One is the participation in the Internet governance forums, which in not only the Internet governance forum meetings itself in November in Rio, but also in activities leading up to it; to include making presentations before the government advisory committee of ICANN. We've done it twice so far this year. We'll do it for the third meeting this year in Los Angeles. In the communications area, we have been preparing outreach materials to support these efforts, and we will have a booth or table, or whatever it is that they call it at the IGF in Rio where we can put out documentation and literature about what the RIR system is, how the policy process works, how it does an effective process, and we can certainly hold forums like this as examples about how effective this process is, and how we can go about and tackle at health problems. The other important thing we're working on is trying to establish some sort of relationship with ICANN, and quite frankly this is going a little slow. A part of it lies with ICANN, and a larger part of it lies with us. Our problem is coordinating amongst five IRRs, five boards, and so forth. But we're moving along on that. We've also been working with people in the ICANN that do the IANA function as far as working on some procedures and so forth in that area as well. The other activities we're doing are the routine technical activities that we coordinate amongst ourselves such as rerunning the reverse domains based upon our allocations from the IANA, and things of that nature. So, that's it, briefly on the NRO activities. Does any have questions of me on that? Okay, thank you. If not, disregard what your watch says, it's really 9:30.

2007-15: Authentication of Legacy Resources

MR. PLZAK: And we now are going to begin the first policy proposal of the morning which is policy proposal 2007-15, Authentication of Legacy Resources. This proposal was first introduced in July of this year, and was designated a formal proposal several weeks later. This is its first public policy meeting. And it was revised once, and that was in August of this year. Text, of course, is always in the meeting packet, and on the website. Staff understands that this proposal would add new sections to the policy manual Section 4.9 regarding legacy resources. The purpose is to "encourage legacy resource holders to sign the RSA. The shepherds are Alec and Paul. In terms of discussion on the PPML, prior to being a formal proposal, there were about 50 posts by 28 people with little support for removing name servers. There were three -- and afterwards the proposal formally, 88 posts by 33 people, 3-4 for against comments as they're shown here on the screen. Legal assessment; this policy may have legal implications. The ARIN Board has authorized the creation of a legacy RSA 1.0 which contains very favorable terms for legacy address holders designed to entice or provide incentives, both signed and specifically designed RSA to obtain continued future services, and to return underutilized resources to ARIN. Policy 2007-15 takes a step one -- takes this one step further, and as the incentive of the future fixed date reduction of in-addr services or stick, not carrot to the policy alternatives. If the policy is adapted, there is a modest risk. Legacy holders who have received free services in the past without any agreement with ARIN could attempt to litigate about such policy. Currently, I'm unaware of any contractually binding or implied duty of ARIN to maintain such service in the absence of policy to this effect. Therefore, I've no current legal objection to the proposed policy." Counsel's opinion as of October of this year. Staff comments: ARIN interprets, "evaluate, and verify chain of custody of any resource records" as the standard ARIN vetting and verification procedures currently in use. And we'd place this in Section 4.9; these comments are as of October of this year as well. From an implementation standpoint, we think it'll be significant. It would take at least 6 months to a year after the Board of Trustees ratifies it. It's going to require updates, registration services guidelines, staff training; additional staff may be required. We haven't figured out quite how much that would be. Database changes and new tracking tools. This is the assessment as of October 2007. So, with that I'd like to ask the proposal author, Andrew Dul, to please come up.

MR. DUL: Good morning, everybody. So, basically as we talked about, and I think most people know, this policy does two things. It sets a date for when legacy records were basically locked. No changes are allowed after a specific date, and the other part is that it did asks ARIN to develop a legacy RSA for people to assign which ARIN has already done and published. And I also would like to point out this as policy is very similar to a policy that was implemented in the APNIC region in 2005. So, why this policy and why now? Well, that is probably a pretty good question. This policy sort of has grown out of a number of conversations I had with people over a number of years as to what we can do to try and get more members of the legacy community into a formal relationship with ARIN. A lot of people believe this is important as the free pool runs out, and just to basically codify the relationship in terms that everybody understands rather than ambiguous that the current legacy holders are. It mirrors the changes as we've talked about with other RIRs, specifically APNIC. A lot of people on the mailing list believe that some sort of outreach needs to the done with legacy space holders. And when I started this conversation, shortly after the last -- the last meeting, there were a lot of, you know, how do we get there, how do we get ARIN to do this outreach formally. And one of the reasons -- one of the ways I thought would be able to get this done formally was to submit a policy proposal that would basically ask ARIN to do an outreach, (off mike) legacy RSA, and you know, have some incentive, some people call it carrot stick, you know, whatever you want to call it, that would basically set a date for changes. So, what are the issues that people have raised about this policy proposal? Basically, a lot of what I hear right now is that the date is too early. And I think that this can be easily changed, and as a matter of course depending on the discussion, I might ask the chair to ask if a later date would be appropriate. This policy could lead to stale data because we're locking the WHOIS data for legacy space holders. I totally agree that that could happen. And whether we -- what we need to decide is whether that is a risk that we're willing to take, to basically bring more legacy space holders into the formal relationship. Because without it, basically, people can continue in the status quo, which might be fine. You know, you come in ARIN and ask them to change your records and this, that and the other thing, and ARIN will continue to do that as long as we continue to say that that's what we want people -- ARIN to do. And the last comment is that the legacy RSA that was announced over the weekend is not exactly what the community would like to see in a legacy RSA. And I think that conversation is largely orthogonal to this policy proposal. However, you know, if there isn't a valid and reasonable legacy RSA that people think that could be implemented, then maybe we need to take a second look at this policy, and I think that's reasonable, and I think also another reason to push this date out to maybe another year from now. And that's my slide, so --

MR. CURRAN: Okay.

MR. DUL: -- I open for your questions or comments.

MR. CURRAN: Microphones are open for comments on 2007-15. Yes, far microphone. Time.

MR. BURDEN: Here we go. Thank you. Ken Burden, Hewlett Packard. Certainly the timeframe is way, way too short. So, a little over two months from now is not practical particularly with the holidays, et cetera. The time will have to be extended out further, please. Thank you.

MR. CURRAN: Okay. Center microphone.

MR. WEILER: Sam Weiler, Sparta. You were saying you don't care whether we call this carrot, or stick. I'm going to call it vinegar as in you catch more flies with honey than vinegar. I'm happy encouraging the Board to create some incentives, but I'm not happy creating sticks, independent of the timeframe. So this community is much better served by having up-to-date with this information, than by getting people to sign contracts with their own.

MR. CURRAN: So you'd be opposed to the policy proposal as written?

MR. WEILER: As written, and even if we change the date.

MR. CURRAN: Okay, thank you. Far microphone.

MR. LEWIS: Ed Lewis, NeuStar. On -- the part that I disagree with this policy is preventing the registrars from changing their data after certain date if they don't sign the RSA, because that victimizes the people who rely on the data, not those providing the data.

MR. CURRAN: So would you be in favor of the proposal as written --

MR. LEWIS: Against.

MR. CURRAN: -- or you would be in favor of it if the data could still be maintained in the absence?

MR. LEWIS: I wasn't prepared to answer that question, sorry.

MR. CURRAN: Well --

MR. LEWIS: I'm for outreach of the legacies. I just don't want to see us penalize the -- victimize other people in doing that.

MR. CURRAN: So, to the point where you would not -- you would not recommend this policy as written?

MR. LEWIS: Yeah.

MR. CURRAN: Okay, thank you. Far microphone.

MR. VEGODA: I, Leo Vegoda, ICANN. I'm opposed to the policy as written, because it could have the impact that there is no technical -- working technical contact, even when someone wants to provide a working technical contact. I think that's bad. If the policy was changed to allow a working technical contact, although other information was frozen, I'd have a look at it again. I'm not sure if I would support it, but I'll definitely take a second look. But I think there is real value than having a working technical contact for all networks.

MR. CURRAN: Okay, good feedback. We've center microphone, and then we have some head table. Center mike.

MR. BICKNELL: Leo Bicknell, IFC. Along with the same vein as Ed, I won't be too long. I do think freezing it is dangerous, and I think that perhaps looking at some other mechanisms to make it disadvantageous to wait would be good. I hesitate to even saying it here in this policy forum, but perhaps if you wait past the date, they cost you $5,000 to update your WHOIS or something like that. I know, fees aren't policy, but preventing them outright is a problem. Making there'd be some penalty, I think, would be acceptable.

MR. CURRAN: Okay. So, as written you would be opposed to it?

MR. BICKNELL: Correct.

MR. CURRAN: Okay, thank you. Head table, Rob Seastrom.

MR. SEASTROM: Yeah, Rob Seastrom, ARIN AC although I'm speaking as a legacy resource holder, not as an AC member here. I welcome the intent of this policy, but I agree with both Sam and Leo that there seems to be something that is coercive, and hurried, especially the December 31st deadline, and I would welcome something that seemed a little bit more like honey than vinegar.

MR. CURRAN: Okay. All split head table. DO you have a name? Bill Woodcock. (Laughter)

MR. WOODCOCK: I'm not going to speak to whether I like or dislike this particular proposal, but I would -- I do feel strongly about all incentives being aligned in useful ways, and one thing I would like the membership to think about is who it is that benefits from the WHOIS information, and whether WHOIS is a service that is being provided to the individual holder of a resource, or whether WHOIS is a service that is being provided to everyone else. And I think that's kind of my take on what Leo Vegoda was just saying. And that's why, I think, that's an important thing to keep in mind that, I think, WHOIS is a service that ARIN provides to the community, not to individual members of the community.

MR. CURRAN: Okay. Good point. Far microphone.

MR. DeLONG: Owen DeLong, JITTR Networks, and I oppose the policy proposal. I'll let go the comments to a certain extent, briefly that the termination of WHOIS is a disservice to the community at large, more than it is a disservice to the legacy holder in question, a matter I don't care much one way or the other. And a policy proposal, if you wanted to use that as a stick, I wouldn't strongly oppose, but the current proposal, I think, is a stick to the entire community to punish people that have done no wrong that aren't actually going to be the recipients of the stick. So, it doesn't make a lot of sense to me.

MR. CURRAN: And are there particular changes you'd recommend so the policy proposal was supportable?

MR. DeLONG: Not really. I'd really recommend abandoning it.

MR. CURRAN: Okay, thank you. Far microphone.

MR. OBERMAN: Kevin Oberman, ESNet, opposed to the policy as currently stated. I agree with what people said about WHOIS, and I'm not going to bother repeating that. I do think IN-ADDR might be a much more appropriate stick, because it punishes the person who does not register in the various network services. The check on such things will suddenly stop working for him, and give him a strong incentive to register. WHOIS is a service to the community. So, taking that away punishes everybody else a lot more than it punishes who you're trying to take the stick to.

MR. CURRAN: Okay, so you would not support it as written? Is there a particular change that would make it supportable?

MR. OBERMAN: I'd have to give it a little thought, but in general I think I would support it if it was limited only to the IN-ADDR portion of the date that it would no longer be maintained, and WHOIS would still be maintained.

MR. CURRAN: Acknowledged. The chair recognizes the point of information, Suzanne Woolf.

MS. WOOLF: Sure. Suzanne Woolf, ARIN AC. As part of a level setting for this discussion and all of them about the legacy resources, I'd like it if someone from the staff could comment on exactly what happens today when a legacy holder comes to ARIN for a change in updating information.

MR. CURRAN: So, Leslie, could you address what happens when someone comes to change information on a legacy block?

MS. NOBILE: We make any change they request.

MR. CURRAN: Yeah. So you process it as is?

MS. NOBILE: As is.

MR. CURRAN: Okay. Okay, microphone's open. Far side.

MS. ANDERSON: Hi, Celeste Anderson, Los Nettos and Pacific Wave. And I have kind of a question of how many people are registered where there is no contact whatsoever. Because I noticed when I was trying to bring my resources together, that many of the.org IDs that have been created previous to ARIN, and there were multiples for resources that were for Los Nettos, there was nothing listed. So there was no way I could go in without a lot of paperwork and change that. And if that is the case for many other legacy holders, December 31st is an absolutely undoable timeframe by which you can sort through all of that.

MR. CURRAN: Okay.

MS. ANDERSON: So, I would recommend abandoning it until you can get some clear numbers on how many legacy holders in.org IDs this affects.

MR. CURRAN: Okay. With respect to the policy as written, you'd be against it. Would you be for it with an implementation date that was further out?

MS. ANDERSON: I'd have to take a look at that --

MR. CURRAN: Uh-huh.

MS. ANDERSON: -- but I think, I'm more towards abandoning it and rewriting something after we have a little bit more information on the impact.

MR. CURRAN: Okay. Thank you. Microphones remain open. Any other comments on this policy proposal? Okay, I'm not going to prolong debate if there is no reason to have discussion. Everyone feels informed on the topic. I'd like to thank Andrew. (Applause)

MR. CURRAN: At this time, as a result of the discussion that we've had, it's now time to have a show of hands to help guide the Advisory Council in doing their job. So, I'd like everyone to be prepared. We're going to ask for everyone in favor and everyone opposed to policy proposal 2007-15. First, we're going to ask for those in favor. All those in favor of policy proposal 2007-15, please raise your hand now. If you're in favor, raise your hand now. We -- we have a count. All those opposed to 2007-15, please raise your hand now. Nice and high. We have a count. Thank you. I recognize center rear microphone.

MS. AZINGER: Thank you. On behalf of the AC, I'm wondering if you could do a vote just so we get more guidance.

MR. CURRAN: I want to be clear on one thing. You're not asking any question about the vote we just had.

MS. AZINGER: That's straw poll. Sorry.

MR. CURRAN: Okay.

MS. AZINGER: But to give us more guidance, if you could do a straw poll on if things were changed in it?

MR. CURRAN: Sure.

MS. AZINGER: If they would then -- all right.

MR. CURRAN: And I'm going to ask Andrew, the policy proposal author, whether or not he'd like me to ask for a show of hands on some alternatives of this proposal, such as a different date or different enforcement mechanisms. Andrew, would you --

MR. DUL: No.

MR. CURRAN: No. That's fine. I'll ask -- it's the policy proposal's owner's job to really decide if he wants that or doesn't want that. Yeah. You can work with him, but I can't force that. Okay? All right. We're moving on to -- let me take the poll as is? Okay, on policy proposal 2007-15 with 145 people in the room, a show of hands, all those in favor, zero. All those against, 74. Thank you.

2007-17: Legacy Outreach and Partial Reclamation

MR. PLZAK: Okay. Moving on to proposal 2007- 17, Legacy Outreach and Partial Reclamation. Proposed first of all in the end of June of this year, and designated as a formal proposal in August of this year. This is a first public policy meeting discussion of it. It's been -- the last time it was revised was in September of this year. ARIN staff understands that the proposal would modify policy manual Section 4.6, ignoring the parts that concern fees and waivers. The proposal would change the current policy by changing the timeframe for returning address space to ARIN. The shepherds are Cathy and Lea. Prior to this being a formal proposal, there were about 56 posts by 80 people with two in favor, and none against. Since it's designated as a proposal, 11 posts by five people, one for and one against. Comments as -- as you could see. Legal assessment. Eye chart. "I have reviewed this policy and believe it poses no significant risks of litigation by outside parties. However, in my non-legal opinion, acting as counselor to the Board and Advisory Council, the policy does something I have never previously seen, and encroaches on how ARIN has operated by custom. To date, the ARIN Board of Trustees has unilaterally debated, and set the rates of payment for any ARIN services. Overall this policy proposal substitutes a policy with specific numerical promises. This would impinge on the Board's ability to holistically adjust such economic numbers, for example, to create a new incentive by going even further than the policy, or less than the policy, to achieve its aims. The author and the AC might consider substitution of the alternative draft policy that gives strong directional adjectival guidance to the Board, but does not contain specific amounts. For example, and I believe consistent with the proposed policy, the policy adopted can address -- make clear the community is sending clear guidance that the economic inducements for legacy holders -- address holders to sign a new and publicly available alternative RSA for legacy holders can be accomplished more deftly by providing an RSA, not a policy. The discussion approved to accompany the policy can contain non-binding but specific recommendations for this purpose, which the Board would probably welcome. An RSA is a contract. ARIN can unilaterally bind itself in such contracts promising consistent future terms, including any promise ARIN chooses to make to not charge for certain services. But the RSA can also be phased out, not impacting contracted parties, but not be available for future parties who do not sign up. Such flexibility in the RSA, with the Board following the aspirational policy is a correct direction for the continued development of this proposal." This is it.

MR. CURRAN: Thank you Ray. (Applause)

MR. PLZAK: kc, are you in the room? (Laughter)

MR. PLZAK: You probably could do it faster. Staff comments, there's fairly an aggregation policy in the manual. This proposal seems to be confusing and perhaps contradicting that existing policy. Does this proposal replace the existing aggregation policy 4.7 in that policy manual? Implementation assessment take us about 30 to days after the Board ratified it. We'd have to update guidelines to do some training, and we'll have to develop some tracking tools for the return of space. And so I would ask, say who -- yeah, Owen.

SPEAKER: Owen.

MR. DeLONG: Thank you, Chairman. Sorry, I didn't expect this to go into mirroring mode. Yes, okay. I have the display I expected, and the big monitors have what you expected. Okay, so this policy has been through a couple of revisions. It was originally motivated by discussions at the last policy meeting of what to do about outreach to legacy holders, the possibility of offering some carrots for the return of space, and bring some more to that. What we are really talking about is an overhaul of Section 4.6. The amnesty in 4.7 really addresses a different issue, and I think this proposal is pretty unrelated to that. A lot of these Counsel's comments were addressed in this reversion, in that it doesn't contain a specific set of fee proposals and such anymore. IPv4 reclamation is unlikely to significantly extend IPv4 free space life time. And that really isn't the primary motivation for doing this. The primary motivation for trying to seek reclamation is that unused IPv4 addresses provide a place for abuse to originate from more readily than most other forms of IPv4 addresses. And by allowing as many of those to be reclaimed as possible, it allows projects like Cymru to get them into things like Bogon filters, and reduce the potential for them to be used for abuse. Actually IPv6 uptake is going to worsen that problem over time, because more IPv4 space is going fall into disuse as IPv6 becomes more widely used. And so I think having a process for reclaiming defunct IPv4 addresses is well worthwhile. Aggregation should still be encouraged. Free space garbage collection is actually hard as we've all discovered. And therefore, I think we should make it as easy as possible to provide some carrots for doing so. This proposal also seeks to somewhat increase IPv6 uptake. I don't think auto-assigning IPv6 to people who don't really want it helps the situation, because although it creates the illusion of IPv6 uptake, it doesn't create actual IPv6 uptake, and it makes it harder to get a real statistics about who is or isn't using it versus if they requested it, you can at least make some assumption that at some point they intended to use it whether they actually did or not. IPv6 carrots could be one way to reach out to legacy holders and offer them something in exchange for joining the ARIN process, and/or surrendering space they are not using. Carrots are probably useful in terms of trying to do that. This policy asks the Board of Trustees to develop some carrots. Ideas for other carrots are welcome. Fees aren't a policy matters so that specific set of fee proposals was removed from the policy proposal at the recommendation of the Board of Trustees Counsel, the ARIN EC and several other parties who hammered me on that. And the proposal suggests that the Board of Trustees do consider fee-based carrots but again fees aren't policy. What about sticks? Well, we don't really have a lot of sticks that are likely to be effective against legacy users. We're more likely to make the situation worse by trying to use what few sticks we might have. And primarily I think that the discussion of sticks on the PPML has already kind of produced a level of irritation and anger among the legacy holders represented there. And I think outreach and trying to befriend them will be much more effective. These are not people who've committed a crime against us. We shouldn't be trying to treat them like thieves and criminals. We should be trying to talk to them about what we want. Nine out of 10 rabbits respond better to carrots than sticks. Questions.

MR. CURRAN: Microphones are open for discussion on this policy proposal. Oh, there's no one who wishes to speak either for or against this policy proposal. I found someone center of front mike.

MR. HUSTON: Geoff Huston, APNIC. By circumstances of employment, I'm neither for or against this proposal, but I do have a question. And it's a question about your opinion. Do you believe that the fees associated with services provided by ARIN to its members are sufficiently a barrier here, that by waiving them you think you have a sufficient inducement? The commentary about this and the reason why I ask is that legacy holders, I think, of address space have concerns that I think of probably far different than merely a relatively minor amount of fees. In terms of the services provided to the industry, the fee is associated with registry maintenance microscopically small, you know, compared to any other kind of industry service of this nature. My own personal suspicion is that fees are not really the inducement or the disincentive here. So the question really is, is it a fee issue or are you searching for something else?

MR. DeLONG: Well, so first I completely agree with you that fees are not the big disincentive to joining the process. But I was looking for what few carrots we had to offer legacy holders to join the process, and I think that the combination of fee waivers and the RSA that has been developed are a pretty good set of carrots. And I'm hoping that we don't need a whole lot of carrots to overcome what is the resistance to an essentially neutral change for them otherwise.

MR. CURRAN: Okay. Center rear mike.

MS. AZINGER: Marla Azinger, Frontier Communications. Forgive me if I do have the incorrect version, because I'm trying to keep up with the updates and I missed the very beginning of your presentation. So I apologize. So if I say something that isn't -- isn't anymore, please let me know. As it's written, I don't support it. The spirit of some things in, I absolutely do. So the things that I would ask to be considered is I don't know why the proposal directs to buy -- to create an incentive plan for returning addresses when this proposal already includes incentives within it. So should the included incentive text be taken out and handed over to the BOT or --

MR. DeLONG: It was.

MS. AZINGER: All the incentives were taken out?

MR. DeLONG: The incentives were taken out and replaced --

MS. AZINGER: Okay.

MR. DeLONG: -- with the suggestion of BOT development incentive plan.

MS. AZINGER: Excellent, thank you. And then the second one is, I feel the proposition includes really two different things: reclamation, RSA compliance. If you want to encourage return of IPv4 address space and keep to just that and then create a second proposal that just suggests RSA compliance, and I would support that. So --

MR. CURRAN: Okay. Good comments. Microphones remain open for discussion of this policy proposal. Center front microphone.

MR. WEILER: Sam Weiler, SPARTA. I support this proposal very strongly. I support it because it allows people to do good things with address space namely return it or aggregated or exchange it for aggregatable blocks without signing an RSA. I think I have a response to Jeff's question. I think we promised the RSA, not the fees. And for those who couldn't hear him, Jeff said, "So do I." I think keeping the "no RSA" provision, in fact, no contract provision generally is a very important part of this proposal.

MR. CURRAN: Okay, other comments. Center table --

MR. DeLONG: I'd like to kind of respond to Marla a little bit and expand on this.

MR. CURRAN: Sure.

MR. DeLONG: The proposal addresses both RSA and reclamation, because those two things are actually somewhat closely tied together. It is an attempt to create policy that allows people to return things without penalty, and to create some carrots for them to be able to get different or better things in response to their return. And in order to issue them new stuff, currently they were required to sign the current RSA. So this policy attempts to make that less of a barrier by allowing them to keep their existing RSA, sign the current RSA or in the case where what they're getting is a smaller block than what they're giving back, sign no RSA if they don't already have an RSA.

MR. CURRAN: Uh-huh.

MR. DeLONG: And I realize there's some opposition to people not signing RSAs for new space. But in the case where we get space back, as a net gain to ARIN, forcing the RSA in order to not get that space back -- you know, forcing the RSA in order to get that space back is sort of like penalizing. It's like taxing somebody's donation to the government. (Laughter)

MR. CURRAN: Yeah, okay we've Bill, and then we have center front.

MR. WOODCOCK: Yeah, it didn't take quite so long for you, the time. So Sam, a question for you which is, are you familiar with 4.7, and is there something about 4.7 that does not meet the goals that you were expressing. That is 4.7 is the aggregation -- the current aggregation policy which does not require the signing in RSA.

MR. CURRAN: If Sam wants to take a moment to consider that, we'll consider Sam to get the mike when you are ready. Center front.

MR. BICKNELL: Leo Bicknell, IFC, ARIN AC. The only thing I am opposed to in this policy is the lack of signing a contract, and I use that word not the RSA. If the current RSA or the legacy RSA is the barrier, I think the Board and legal and whoever should develop a contract that is suitable, but I think that it all needs to be under a contract. Even if all that contract says is you got this from ARIN, and there's no other terms or anything. That to me, it's preferable to have a written- down relationship because that is the major thing we are lacking today even if the terms are greatly permissive as opposed to having the continued situation where there is no written-down relationship between the parties.

MR. CURRAN: Okay, acknowledged. Microphones remain open. Center front.

MR. LEIBRAND: Scott Leibrand, Internap. I support this proposal. I think it does a good job of providing what few sticks are appropriate, I mean, excuse me, what few carrots are appropriate without putting any sticks in place, and as has been elicited earlier, encourages people to do the right thing without penalizing them. And I think we need to remove all the barriers we can to people doing the right thing in this kind of situation.

MR. CURRAN: Okay, acknowledged. Further comments? Microphones at table, far right?

MR. SPRUNK: I'm Stephen Sprunk, Polycom. I supported this proposal until last Friday. I think now with the legacy RSA, I think it's mostly moot. If there are people who are not willing to sign the legacy RSA to, you know, either return space or exchange space or things like that, I think that we need to look at what we need to do to fix the legacy RSA as opposed to changing policy.

MR. CURRAN: The -- just to be clear, as written in your poser, is there a simple change you would make to or do you believe it's -- it's not worth discussing until the legacy RSA is addressed.

MR. SPRUNK: The latter.

MR. CURRAN: Okay, thank you. Center front, Andrew, in response to the query that you had.

MR. WEILER: Sam, not Andrew. Hi, John.

MR. CURRAN: Sam.

MR. WEILER: Thank you for the extra time I had -- I had read 4.7 yesterday, but I didn't read the refresher. As I understand it, the only difference that I would care about here is the extra slack time in returning addresses which is a pretty minor change. So given the extra -- 4.7 is adequate, I think for that purpose.

MR. CURRAN: Did he answer your question? Okay, thank you.

MR. WEILER: Also thanks to the staff for providing the pieces of paper. (Applause)

MR. CURRAN: Yes, thank you.

MR. WEILER: The pieces of paper are very handy.

MR. CURRAN: Yeah, for those people who don't get the reference exactly, you have a copy of all the policy proposals and the NPRM in your packets.

SPEAKER: NRPM.

MR. CURRAN: NRPM, thank you.

SPEAKER: Not a notice of proposal making.

SPEAKER: Okay. Microphones remain open for comments. Last chance. Microphones are closed. Thank you. (Applause)

MR. DeLONG: Thank you.

MR. CURRAN: Okay, once again it's time to have a show of hands to provide the Advisory Council with guidance in doing their job. The proposal on the table is Policy Proposal 2007-17, Legacy Outreach and Partial Reclamation. We are going to ask for a show of hands on this, all those in favor and then all those opposed. So, all those in favor of Policy Proposal 2007- 17, please raise your hand now. Nice and high. One hand, raise one hand high. We have a vote, thank you. Okay, all those opposed to Policy Proposal 2007-17, raise your hand now. Nice and high. We have a vote, thank you. Oh, show of hands. We have a count. As your show of hands is been tabulated by advanced electronic technology, on Policy Proposal 2007-17, number of people in the room are 145, those in favor 12, those opposed 29. Thank you.

MS. AZINGER: John, point of order.

MR. CURRAN: Yes.

MR. AZINGER: So, the AC has more guidance.

MR. CURRAN: Sure.

MS. AZINGER: Is there a chance you can do a straw poll to find out those that were opposed to it, if it was that they want modification done to it.

MR. CURRAN: I would ask Owen. Owen, is there a particular -- well, my question is, is there a particular question you'd like to have asked? Asking do you want modifications doesn't really help us is -- unless there is a particular modification you're thinking of that's been discussed before the floor such as --

MS. AZINGER: An example would be taking out the RSA information, and just having it be an adjunct reclamation.

MR. CURRAN: I'm happy to have a show of hands on any topic that's received adequate discussion on the floor. So, if there is a particular modification you'd like a show of hands of, please let me know.

SPEAKER: (Off mike)

MR. CURRAN: If modifying it --

SPEAKER: (Off mike)

MR. CURRAN: Set of contract is required, okay.

SPEAKER: Contract instead of an RSA, so a simple contract.

MR. CURRAN: No.

SPEAKER: -- that --

SPEAKER: (Off mike)

MR. CURRAN: No. And so no RSA. It is the option whereby if you put space in and get smaller space back, we allow that with no paper work at all. Leo is addressing that that would be done and would still require some -- and let it be clear -- some form of agreement, okay. So the question on the table and -- is, we discuss the fact that the policy proposal as written, if someone is returning space and receiving a smaller block back presently allows that with no agreement whatsoever. If policy proposal 2007-17 were modified such that in that circumstance where someone was returning a block and receiving a small block back, some form of agreement was required, would you be in favor or opposed to this proposal. Does anyone have questions about the proposal as modified that we are about to have a show of hands on? Any questions about the proposal as modified? Marla?

MS. AZINGER: I don't see a big difference to be e-voting on.

MR. CURRAN: Well --

MS. AZINGER: Because it --

MR. CURRAN: -- Owen does and he is the proposal author.

MS. AZINGER: Well, you were asking if people are confused. So, I'm confused. I don't see a big difference.

MR. CURRAN: Okay. Do you recognize -- the question, I guess, that comes up is, do you see the difference between requiring no agreement whatsoever and having some form of agreement.

MS. AZINGER: So you are asking if there'll be some form of agreement, but the proposal already consists of some form of agreement.

MR. CURRAN: Not on the circumstances, where someone is turning in a block and receiving a smaller block presently.

MS. AZINGER: Okay.

MR. CURRAN: I guess, Leo, do you wish to speak to this?

MR. BICKNELL: I had a brief side-chat with a couple of people who asked me what exactly I meant and, I think, at least one part of the confusion is we now have a legacy RSA that many people in this room are not that familiar with yet, because it just came out. And the question that was posed to me by two different people is what in the legacy RSA isn't good enough, what are people objecting to.

MR. CURRAN: Uh-huh.

MR. BICKNELL: And we don't know yet, which is why I used the word contract and not legacy RSA.

MR. CURRAN: Okay.

MR. BICKNELL: It may be the legacy RSA is the appropriate thing in that case. It may be that it needs to be modified for reasons that have not been brought to the floor yet. So I just generically want to say that I feel if any transaction occurs with ARIN, there should be a written contract between the two parties. I hope it is the legacy RSA, but if we have to make changes or make even a third agreement, just that it is written down is the key to me.

MR. CURRAN: Understood. Bill, you'd like to respond? Bill?

MR. WOODCOCK: My usual state of confusion is particularly penetrated by the confusion here between -- in this policy as stated, there are two possibilities. You can either assign the current RSA or no RSA, and in the future situation which would include a newly-drafted legacy RSA, there would be three possibilities: the non- legacy RSA, the legacy RSA, or no RSA. And the mismatch of these two and three possibilities may be causing some confusion to people.

MR. CURRAN: Owen, would you like to respond?

MR. DeLONG: Yes. So, as I would probably revise it if the community gives me guidance that they want to see it continued to be worked on rather than abandoned --

MR. CURRAN: Right.

MR. DeLONG: -- which is really the question we are trying to boil this down to, but trying to do it within your framework, John, if the community feels I should continue to work on it, I'm really going to solicit more input on PPML into exactly how to modify it. But primarily, I think, the issue that is most likely addressed is to clean up the contract situation to address the current context rather than the context that existed at the deadline for proposal submission.

MR. CURRAN: Would you like to see a show of hands still or do you not need one?

MR. DeLONG: Yes, I would like to see a show of hands because I'd like to know whether the community wants me to continue working on this or abandon it. Because if they want me to abandon it, I've got better things to do.

MR. CURRAN: That's all you'd like to say, just should we continue to work on this? Certainly, we've had good discussion. So, there is now request by the proposal author that the only additional show of hands he'd like to see is whether or not we should continue work on policy proposal 2007-17 or should it be abandoned. So that is actually what we are going to ask. We're going to ask for a show of hands. And all those who wish for us to continue work will raise their hands and then I'm going to ask for a show of hands and all that that wish it to be abandoned will raise their hands. Is that clear? Okay. On policy proposal 2007-17, all those that wish work to continue on this proposal, please raise your hands now. Nice and high. We have a count. Thank you. All those who wish to see 2007-17 abandoned with no further work, please raise your hand now. Okay. Thank you. The count is making its way to me now. While we wait, Ray will sing.

SPEAKER: (Off mike)

MR. CURRAN: Yeah. Okay, on should we continue work on this proposal, all those in favor of continuing work -- oh, number of people in the room are 145 and none of you managed to slip out. Should we continue work on this proposal? All those in favor, 40. Should we abandon 2007-17, 7. So 40 in favor of continuing work, 7 in favor of abandonment. Thank you.

2007-21: PIv6 for legacy holders with RSA and efficient use

MR. PLZAK: Proposal 2007-21, PIv6 for legacy holders with RSA and efficient use. Introduced in July, designated form of proposal in August, not revised. ARIN staff understands this proposal would make direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered under an RSA. AC shepherds are Suzanne and Ron. Prior to a formal proposal, there were about 165 posts by 33 people with five in favor and two against. Since it was designated as a proposal, 11 posts by five people won four, none against. One comment is shown here. The Counsel sees no liability risk. Wow, Counsel didn't write the (off mike) yet, okay. Staff comments as of October 2007, the title uses the words "legacy holder" which was never mentioned within the policy text and this would be a modification to section 6.5.8.1. Impact as far as implementation, minimal. We could do it in to 90 days. We have to change some guidelines and do some staff training. And so, with that, I would like to yield.

MR. CURRAN: Okay. Good. Bill?

MR. WOODCOCK: The actual point, I don't see the phrase "legacy holder", I do see the phrase "LIR" in the policy. Has it been edited?

SPEAKER: (Off mike)

MR. WOODCOCK: 2007-21.

MR. CURRAN: They are referring to "legacy holders" in the title.

MR. WOODCOCK: Oh, in the title. Yeah, right.

MR. PLZAK: You said title.

MR. WOODCOCK: Right.

MR. PLZAK: Staff comment directed -- was directed towards the title.

MR. WOODCOCK: Yeah, which won't actually have any effect on the --

MR. PLZAK: Well, I would --

SPEAKER: (off mike)

MR. WOODCOCK: Okay.

MR. PLZAK: Okay, anyways. Scott?

MR. LEIBRAND: Okay. Really simple change. I'll try and make this quick. The problem as identified on PPML to -- as far as I understand it, is that there are currently mechanisms for getting -- IPv6 PI only if you qualify for an IPv4 /22 assignment. That means that legacies that have -- or networks that have legacies /23 and /24 assignments, but don't qualify for a /22, can't get IPv6 PI space. Because they have to use IPv6 PA space, and lose their provider independence if they want to go that route. Other considerations in making this proposal were that a lot of legacy assignments were not covered by the RSA, it is a common theme today. Some may not be efficiently utilized. So I tried to make a very simple change to the direct assignment criteria, to add this phrase in blue that in order to qualify for a direct assignment, you can demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by an RSA. The rationale for doing it that way is to stop discouraging IPv6 adoption by early IPv4 adopters, legacy holders, encourage efficient use of legacy space, and return of unneeded space, and encourage adoption of legacy RSA. Staff commented that legacy holder is in the title but not in the policy text. That is intentional, title is descriptive. So I tried to make it -- use the common language of PPML, whereas in the policy text, where a legacy holder is, as I understand it, not clearly defined -- I simply broadened the existing conditions to specifically state what the requirements are rather than creating a special- case conditional. So questions, comments?

MR. CURRAN: Okay. Microphones are open. I recognize Scott at the head table.

MR. BRADNER: One question on your exact wording. It says "a v4 assignment". Yeah, it says "a direct IPv4 assignment". Does -- do you mean any particular one or all of the ones that somebody has or what?

MR. LEIBRAND: If you have at least one IPv4 assignment or allocation directly from ARIN and --

MR. BRADNER: See, the problem is that --

MR. LEIBRAND: Okay.

MR. BRADNER: -- somebody may have ten or five assignments --

MR. LEIBRAND: Right.

MR. BRADNER: -- and they could show 10 -- they can show the efficient use of one of them, but --

MR. LEIBRAND: If they have five assignments, my presumption was that they would qualify under the /22 rules currently in place. So I --

MR. BRADNER: Even if they have two --

MR. LEIBRAND: I could see that as a loophole, and the intent of the policy was that you would demonstrate efficient use of all your assignments.

MR. BRADNER: Then I would suggest some tweak to say that.

MR. LEIBRAND: Right.

MR. CURRAN: Okay. So noted. Microphones are open. Center rear mic.

MR. WILLIAMSON: David Williamson, Tellme Networks, a Microsoft subsidiary -- the lawyer says I have to say that. I support this proposal. I am a little concerned about some of the ambiguity. I would support moving this forward and letting the AC make appropriate modifications to reduce the ambiguity. I think the intent is very good. I think it is entirely the direction we should be going to encourage v6 adoption. Thanks.

MR. CURRAN: Okay. Thank you. Far right microphone?

MR. DICKSON: Brian Dickson, Afilias. I support the proposal. I would actually encourage relaxing things further by allowing a direct assignment to anybody who has an ASN.

MR. CURRAN: Okay. Interesting.

MR. LEIBRAND: I would respond to that by saying that is a completely separate proposal that broadens the conditions for getting v6 space, and I believe that should be a separate orthogonal discussion.

MR. DICKSON: Proposals can be made by anyone. There is very low entry criteria. So start typing.

MR. CURRAN: Okay. Microphones remain open for this. Any other comments? Yes, rear microphone?

MR. NARTEN: Thomas Narten from IBM. I guess that I would have to say I've become opposed to this policy, and my concern really has to do with route table bloat. And I think what we are doing here is we are allowing yet more end sites, allocations that will end up in the routing tables, and in particular, these are for end sites that don't qualify for /22s and so forth. So they are clearly smaller sites than are currently eligible. And -- a number of the benefits that you listed up there, I think actually aren't really applicable. I don't think this is really going to encourage IPv6 deployment. I think the issues of IPv6 deployment are -- go much beyond the ease of getting address space.

MR. CURRAN: Okay, interesting viewpoint.

MR. LEIBRAND: A response to that. If you have a network that currently has an IPv4 /24 and they are using that in a provider independent fashion, my argument would be that those folks would be encouraged to stick with v4 as long as possible under the current regime rather than lose their provider independence and go to v6. Do you think that is not an issue that they are going to go to PA space, or are you not concerned that they will stick with v4?

MR. NARTEN: I worry that this is a short term encouragement to move to v6, and that in a long term, it will have consequences that are in our best interest.

MR. CURRAN: Okay. Microphones remain open. Any comments? Okay. Yes, center rear microphone?

MR. HERRIN: Bill Herrin. And speaking for myself, I support this proposal. We have all spent the last few days hearing how important it is to get IPv6 deployed as soon as possible, and obstructions to that like preventing legacy users with small assignments from continuing to multi-home. These are things which will delay that process and cost us in the long run far more pain than a mild additional bloat to the routing tables. Thank you.

MR. CURRAN: Okay. Thank you. Far right microphone?

MR. DICKSON: Just a question more than anything else. Do we have any statistics on the number of potential recipients under v4 that would be affected by this policy?

MR. CURRAN: Okay. Point of information. Someone from staff have any way of answering the question of how many people would be -- how many organizations would be affected by this policy? How many folks have --

MR. LEIBRAND: I think I would clarify that to ask, how many /24 and /23 assignments and allocations does ARIN have on its books. Do you know that answer?

MR. PLZAK: Ah, Leslie. You want to get up and say what we don't -- do and don't know or what we may or may not be able to provide? (Laughter)

MS. NOBILE: Okay.

MR. PLZAK: I'm sorry, Leslie.

MS. NOBILE: I would need a bit of prep time for this. I don't --

MR. CURRAN: Well, it needs to be half --

MS. NOBILE: Yeah, I don't have this -- I don't know the numbers. I can give them to you later, but I don't have them, I don't know.

MR. CURRAN: Well, we don't have them at this time. But it is an interesting question.

SPEAKER: Yeah.

SPEAKER: My hypothesis is the number would be actually quite low. The other comment I have is that in early stages of adoption, the rate of adoption is usually bounded by the number of people who have something and the -- multiplied by the number of people who don't, and boosting the number of people who do speeds adoption. It is classic disease propagation or new gadget.

MR. CURRAN: Okay. Microphones remain open. Center rear mic, yes?

MR. DARTE: Yeah, this is Bill Darte, I'm with the Advisory Council. The question raised by, I believe, Scott earlier about whether it is "a" or "all" direct IPV4 assignments, I suspect might have a significant impact on people's count -- on the counts that might arise from this, and so I wonder if the author would consider in the call for a count, that this would be either "a" or "all" or just "all" in leverage of this?

MR. CURRAN: At present, the author has clarified that it will be "all", okay, all though it is not written. It is written as "a." Do you feel strongly that it should be one or the other?

MR. DARTE: I feel strongly that I would like to know if that were going to make a major impact.

MR. CURRAN: Would you -- as written with the letter -- with just "a" there. Are you for the proposal?

MR. DARTE: I abstain from that. My job is to assess consensus here, and that is what I'm trying to arrive at -- is whether the consensus would differ if it is "a" or "all."

MR. LEIBRAND: I would like to hear from anyone who believes that there is a significant difference. Because of the small subset of people who don't qualify, /23s and /24s, I suspect that there would be a small number of people who would have any difference between "any" and "a". So the intent of the proposal as I see it is to -- if you have two /24s, a /23, or some combination like that, that you would demonstrate efficient use of your allocations. If anyone sees that there is a difference between that intent and what is written here, please speak up.

MR. CURRAN: What he said. Thank you. Far microphone and then Scott.

MR. SPRUNK: Stephen Sprunk, Polycom. You mentioned the requirement is currently a /22. That is only for people that are multi-homed. For people that are single-homed, it is /20. And I think that, you know, there are people who are single-homed using a /24 legacy space today. And that would make -- that would become a significant difference. You know, if we are talking about -- you know, efficiently utilizing a /24 out of perhaps their current total of the /21. You know, that is actually a reasonable amount of space, and just because they are not multi-homed, you know --

MR. LEIBRAND: One other --

MR. SRPUNK: -- they wouldn't qualify for the /22.

MR. LEIBRAND: One other aspect that hasn't been brought up in this presentation and maybe I should have put it in there is that -- on the discussion in PPML the intent was here -- if you have a /21 and you are using a /24, that you would return most of that v4 space and be able to qualify for v6 then. So that is another -- I mean that is not part of this proposal in the sense that I'm not changing the way that, that is done. There is other aggregation and return policies that allow you to return space. Once you have returned space, you would then have a block from ARIN that is efficiently utilized and would have the ability to get a v6 PI assignment under this policy.

MR. CURRAN: Okay.

MR. SPRUNK: Well, so I guess my point is that if you have a /21 that is not efficiently utilized, then if it is "a," all you have to do is say that a /24 is efficiently utilized, and you are not required to return the rest of it. You could optionally do that, yes, and hopefully, you would. But you are not required to under this proposal.

SPEAKER: Correct --

MR. SPRUNK: So that is where I see the difference between "a" and "all."

MR. LEIBRAND: You are not required to, under the proposal that's on the screen, but under the proposal that is intended, you would be required to demonstrate efficient utilization of your -- of all your v4 assignments.

MR. SPRUNK: So --

MR. CURRAN: So --

MR. SPRUNK: That is where I -- you know I would support this as "all," but I would be against it as "a." Thank you.

MR. CURRAN: That is what I was going to ask. You would support it as "all," but you would be against it as written. Scott?

MR. BRADNER: I don't think ambiguity is anybody's friend.

MR. CURRAN: Uh-huh.

MR. BRADNER: If it mean -- if you meaned it to mean "all," then you should state that.

MR. CURRAN: Okay. And perhaps if --

MR. BRADNER: I think it is a significant difference.

MR. CURRAN: Okay.

SPEAKER: If I had a keyboard here, I would change it.

MR. CURRAN: If anyone wished to speak at the microphones for maintaining this policy proposal with "a" as opposed to "all" -- if you believe this should read, contrary to the author's intent, of a direct IPv4 assignment, please approach the mic.

MR. WEILER: Sam Weiler, SPARTA.

MR. CURRAN: Yeah.

MR. WEILER: I think it should remain "a," because I see opportunities for gaming the system by doing no-op transfers of the resources to other people, so that you only have one for just long enough to qualify for the v6.

SPEAKER: Okay.

MR. WEILER: I suggest to leave it at "a."

MR. CURRAN: So you would support it as it is with "a," but oppose it if it was "all?"

MR. WEILER: Sure.

MR. CURRAN: Okay. Anyone else who feels as though it must stay as "a" to be supportable, approach the mic. Okay. In order to create clarity here -- I'm sorry -- yes, go ahead. Speak, Andrew.

MR. DUL: Andrew Dul, Perkins Coie. So we've been talking about Randy's talk that he gave on Tuesday about some --

MR. CURRAN: Uh-huh.

MR. DUL: -- of the statistics about legacy holders, and one of his charts shows a little over 20,000 /24s that are marked "legacy." This would include other RIRs as well.

MR. CURRAN: Uh-huh.

MR. DUL: And then the ARIN staff did a quick look in the database and found about 20,000 legacy and non-legacy /24s in the database. So the number of -- is about 20,000.

MR. CURRAN: Got it.

MR. DUL: So --

MR. CURRAN: Okay. So that is answering the point of information. We have here a discussion about whether or not the policy should read "a" or "any" -- or "all," excuse me. And we need to actually resolve that before we bring the motion forward. So people who wish to speak on the topic of whether it should say "all" or "a", please approach the microphone. Owen?

MR. DELONG: Owen DeLong, JITTR Networks. I support the policy. I think it should say "all." But to clarify the 20,000 unique prefixes, wouldn't be 20,000 assignments under this policy, because 20,000 unique prefixes probably isn't 20,000 unique organizations. And each organization would only get one IPv6 regardless of the number of v4 prefixes they have.

MR. CURRAN: Right. It would be an upper bound. You don't know the lower bound based on multiple holdings. Agreed. Well, I try not to wordsmith proposals while they are before the floor. We also wish to be able to give good input to the AC to do their job. So I'm actually going to be asking for a show of hands in a moment on changing the proposal as written to read "demonstrate efficient utilization of all direct IPv4 assignments." We are only going to be asking whether we change this proposal. The author has advocated that change, but we have had comments on both sides of the topic. If anyone wants to speak about the pros and cons of changing it from "of a direct IPv4 assignment" to "of all direct IPv4 assignments," approach the microphone. Seeing discussion on this is complete, we are going to have a show of hands about changing the proposal before the group. The author has proposed changing the wording of 2007-21 to read -- and I'm reading the last section, "or demonstrate efficient utilization of all direct IPv4 assignment or allocations covered by a current ARIN RSA." If you are in favor of this change from "of a direct" to "of all direct," please raise your hand now. Are you in favor of it as the author? I just -- I'm curious, because I said you were. So -- raise your hand. Nice and high. Okay, we have that. All those opposed to changing the proposal, so the proposal would read before this group as written, "demonstrate efficient utilization of a direct IPv4 assignment," please raise your hand. Okay, we have a count. Actually, you know the outcome of this count, but anyway. By consensus of the community, the policy proposal is amended to read "or demonstrate efficient utilization of all direct IPv4 assignment or allocations covered by our current ARIN RSA." This is the current policy proposal text before the group and should be reflected in the notes that are given to the AC. Okay, so now we are discussing the amended proposal before the community. Does anyone wish to speak in favor or opposed to the amended proposal? Okay. It is -- thank you for your presentation. (Applause)

MR. CURRAN: Okay, now is the time when we provide guidance to the ARIN Advisory Council so that they can do a good job, and we are going to do a show of hands on policy proposal 2007-21, as amended. The policy proposal reads -- in part "or demonstrate efficient utilization of a direct IP -- of all direct IPv4 assignments and allocations covered by our current RSA." So if you are in favor of policy proposal 2007-21 as amended, raise your hand now.

SPEAKER: Well, the author --

SPEAKER: Yeah, that is a point.

MR. CURRAN: Nice and high.

SPEAKER: Well, except the author --

MR. CURRAN: Okay, thank you. If you oppose the policy proposal 2007-21 as amended, raise your hand. Okay. We have a count. It is making its way to the front. Okay. Number of people in the room, 145. On the topic of 2007-21 as amended; in favor, 47; against, 11. Thank you.

RIR Update - LACNIC

MR. PLZAK: Thanks, John. We have minutes before the break, and so instead of breaking early, I'm going to ask Ricardo if you can come up and give the LACNIC update. Ricardo?

MR. PATARA: Sorry for that. Good morning. My name is Ricardo Patara. I'll do the LACNIC report, and I'll try to not delay for the coffee break. Just introduction about LACNIC is the economies we cover in our region. We have 29 economies, and these are the -- basically the economies and the countries that we provide service to. Some numbers about LACNIC, the membership evolution. These are the -- how membership is growing from '99 to this year. As we can see, there is a high increase of number of members in 2007. This is due to the agreement that was signed between LACNIC and the NIR. We have two NIRs in our region, one in Mexico and one in Brazil. This year we signed the agreement with the NIR in Brazil, so all the NIR members are also LACNIC members. So this explain the increase of -- the number increasing in 2007. The great majority of our members are in the small or medium category. This would show you how the membership is distributed in the region, be in Brazil, Mexico, Argentina, in Columbia, the countries which create the most numbers of members. And talking about numbers, LACNIC staff, we are also growing since 2002, when we were recognized. So far we have 15 -- actually 16, yeah. This is how they are distributed. We have five people working for the administration, four for technical parts, technical area, five in the policy and external relationship and two -- and the actions which the CEO and his secretary. During 2007, actually during 2006, we start to do some strategic planning. The idea was to be more focused on your -- our services and also in what the community expect from us. It is our change of mind but also provide us some adjustments inside of the organizations, and also help us how to do the budget for the following years was a very nice experience. We come up with our vision. That is basically, the vision should be believe in the construction and articulation of the collaborative effort in Internet development and stability in Latin American, Caribbean, and the mission, but I will not read all of this. But this should give you an idea that we have now a mission and a vision so we can try to be focused on that and try to be a very good organization for the community. Last May, we had our meeting. It was in Venezuela, the Isla Margarita, very nice place. Some summaries about that meetings, we had a very impressive number of attendees, which was 325 people there, a very, very good number, 29 different countries represented. And this number is also due to the fact that we had some other groups meeting together with us like ccTLDs, Internet Exchange Points, Security Group, IPv6 task force. So this make LACNIC meeting a very interesting meeting inside the region. We had 11 different proposals presented, six of them reached consensus. They are listed here, but the one that I would like to highlight is the 2007-07, which the distribution of the remaining IPv4 address space, which we should consensus on that. It is basically the same policy proposal that was presented yesterday. We also have our group working for the revision of the text, the policy text we have. There are some ambiguities and some questions about the wording. So we have our editorial working group revising that. Some information about LACNIC and information society in the region. As you might have already seen before in all the presentations, we have a project we call plus Roots. Actually in Spanish, it would be mas Raices, which is the translation for that. The idea is to install or distribute any guest root servers, copies of root servers. We so far have been able to install five of them. We have space for more too. We also have this program called FRIDA. The idea is to support small projects related to the ICT in the region. It is a collaborate effort with LACNIC, IDRC, and ISOC. Talking about the information society, we had some activities like Internet Day. We had a very important event in the region in El Salvador, which was an Internet exchange workshop with the help of the CISCO, the local government, PCH, ISOC, and ICANN. We also signed with ARIN and LACNIC and Caribbean Telecommunication agreement. We signed an agreement to improve the collaboration in the Caribbean region. And we also start to -- actually we start sometime ago before, like in 2005 to promote very aggressively the IPv6. But this year we deployed IPv6 portals to give the community some information about IPv6. I mean how to start the transition. We also have this in the region this program called eLAC-2007. The idea is to help the government to implement some actions to improve the information society. There are 70 goals, 70 objectives in LACNIC with their work -- LACNIC, which is work held directly to -- with 2005 -- 25 of them was very important in making LACNIC a very important actor in development of the internet information society of the region. And finally, our next meeting, it will be in May 2008. It will be in Brazil# in the city called Salvador. It is a very amazing place. You are all invited to go there. And that is it. If you have any comments or question. Thank you. (Applause)

MR. CURRAN: Question to the --

MS. ARONSON: Hi.

MR. CURRAN: Okay, sorry.

MS. ARONSON: I guess I wasn't fast enough.

MR. CURRAN: Okay, go ahead, Cathy.

MS. ARONSON: I'm Cathy Aronson, ARIN AC. I noticed that you mentioned that you guys have now -- have national Internet registries. There are two of them, right?

MR. PATARA: Yes.

MS. ARONSON: Okay. So I didn't know that they were -- those weren't being created anymore because of --

SPEAKER: Pre-dated.

SPEAKER: Pre-dated.

MR. PATARA: They -- pre existent --

MS. ARONSON: Okay, so my question then -- okay, so they pre-dated LACNIC. Do they have their own policy forums like in other regions or --

MR. PATARA: No, actually they do not have their policy forum. They are invited to come to our LACNIC. But they have their local meetings, but the idea of their meetings are not to propose policies. They have to come to LACNIC meetings in order to do that.

MS. ARONSON: Okay, thanks.

MR. PATARA: Okay. Thank you.

MR. PLZAK: Just to close the loop on those two NIRs. We are talking about NIC Mexico and NIC Brazil. And they were in the ARIN region, considered to be delegated registries. But basically in the ARIN region, at the time, they were basically administers of the address space, and subject to all policies developed in the region, and in essence that is what transferred over into LACNIC. So we are at the point of time where we can take a break. So go to cyber Café and view all those neat stuff, and if you don't get that stuff, you can always go for a consolation prize. Visit the helpdesk and get the help that you may need. And so be back in here and let us go for 10:45 a.m. And I'm cutting you close, but let us keep on moving. Thanks. (Recess)

IPv6 IAB/IETF Activities Report

MR. PLZAK: The next thing that we are going to get is a report on IPv6 and also IAB, IETF activities report, and that is going to be given from Thomas Narten who will be in the room momentarily. And so -- (Discussion off the record)

MR. NARTEN: Okay, so I'm going to give just sort of an overview of what is going to be happening in the IETF since the last ARIN meeting. And I'll start with this sort of a standard disclaimer to observe that this is not an official IETF report and one of the reasons for that is there is no such thing. There are no formal liaisons -- relationship between the IETF and the RIRs. However, you know, I certainly believe it is accurate. I have gone and done much of homework in getting information and any errors are my responsibility. Okay. So, one of the areas that there has been a fair amount of activity is in the routing and addressing space and how to deal with the route scaling problem. You've heard about that at the NANOG meeting, you've heard about it in some of the presentation yesterday as well. In terms of what is going on, there is a problem statements being worked on and he 01 revision was issued I think last week. It tries to define exactly what the problem is and what is causing it and what are the difficulties with it. The solution efforts are currently being worked out on in the routing research group, and they have at present about 9 separate proposals that people are working on, some of them are more mature than others. It is not really clear which ones are going to sort of come out at the end of the current model that they are following, so let them all sort of go about at their own rate, and you know, if there is interest to push them forward from the contributors and people that are following it, that's really the best way to gauge whether it is a you know, the right direction to go in. And they are going to be together for the Vancouver IETF. They have been meeting at the previous IEFT. I think they have a two -- like a -- like 5 hours worth of meeting time schedule, and I have provided the URL there just to see what the actual chart of the routing group is and you know, pointers to the mailing lists and so forth. So, once again, you know, I would encourage you to join that effort, follow what is going on there, because you know ultimately, the only way we are going to solve this problem is if we come up with a solution that really works for people, and that takes people contributing. Here they also published the -- as an RFC, the report from the workshop, which was held about a year ago, that sort of started this whole effort again on the IETF side. Okay. And I'm just now going to go over some of the working groups that I sort of arbitrarily think are of most interest to the people that are here. The Shim 6 working group, that site multihoming -- that has been discussed on and off a lot here. They have been trying to come up with a multihoming solution that is based on the end station or the end node being heavily involved in that. It is something that the operators have expressed a lot of displeasure with, but the work still goes forward and they are trying to finish off the documents, the three core documents are now with the IESG and will presumably go through the IEFT last call process and all soon. So I would expect an RC to pop out in the next, you know, six months, give or take. And they have other related documents they are also working on that are sort of related to but not the core ones. But in terms of what happens next, you know, it sort of depends, we need implementations, we need experience, and depending on where that goes, you know, presumably the community will reassess, you know, how viable that approach is and what the applicability is. On the IPv6 side, we have a new working group called the IPv6 Maintenance Working Group or 6man and the original or the previous IPv6 working group is formally closed. Now, what that means is that with the maintenance working group, they are trying to refocus the efforts so to try to send a signal that the main work on IPv6 is considered done. They don't expect to get more proposals that come in to invent wonderful things that will automatically be taken on by the IPv6 working group. Instead, the working group is now focused on doing maintenance, taking existing RFCs, cleaning them up, reissuing them, advancing them up the standards track and so forth. That is not to say that no new v6 work will be taken on. But there -- you know, any new proposal to do substantive v6 work will have to go through the standard process of having a BOF, making sure there really is community consensus for its well-defined problem and so forth. Okay. There is a number of active documents that the working group still have on its plate. The two that are probably of the most interest, one of them is the ULA-central, the centrally assigned unique local unicast addresses. It has been talked on and off on -- you know, on the PPML list, on NANOG, I mean, on IPv6. But all I can really say is that there is no consensus at the current time to go forward with that. I believe the current approach is there is another -- revision of the document plan, which is trying to summarize the issues and you know, the pros and cons better. But in terms of where that is heading, it is really unclear at this point. And there has been a lot of focus in the last six months on a certain kind of routing header. It turns out that there is a bit of a security vulnerability where the routing header, the way it is defined. You can put a lot of addresses, repetitive addresses in the routing header and then have a ping pong loop go back and forth across a link if you set it up correctly. And the many reaction of some of the open source people, was to simply disable a feature in there and -- and flag it as a security problem and the IEFT as a process, basically deprecated that feature since it is not really used in practice anyway. Okay. They've also published a few RFCs in the last six months. The main ones are -- that the basic neighbor discovery and related documents were reissued. I think it is like the third time they have been reissued, you know, again cleaning up things that have been learnt from implementation and deployment experience. V6 operations, this is -- they have a lot of things on their plate that they are working on. They are looking at a number of documents that have to do with operational considerations. For example, there is a Unicast address assignment consideration. This is intended to sort of provide background and guidance to people that are trying to deploy IPv6 and who have questions about, well, how should I layout my infrastructure and why would I not want to do the same thing I did with v4 with v6, okay? And likewise with the campus transition scenario, description analysis, and things like that. So, there is a lot of more operational oriented documents that are trying to provide guidance to people that are considering deploying v6, okay? They've got a couple of documents the IESG is working on. They have also published a long list of RFCs in the last six months as well. Okay. The soft wire working group, this is one that is working on the problem of how do you tunnel, as an ISP, if you're like -- how do you tunnel v6 across of your infrastructure so that, you know, an end site can easily set up a tunnel and have it all work right? And they are continuing to work on things. They had their problem statement published as an RFC, and they are still actively working away at their core documents. DNS operations, again they have a number of active documents. There is one that is being -- you know, being worked on by the IESG. Some of these are, you know, directly related to have like the AS112 main server operations considerations, considerations for the use of DNS reverse mapping, and they recently published the requirements for -- I'm sorry, the mechanisms for identifying a name server, which allows you to query a name server and get back an identifier for it in the case where Anycast is used. Okay? DNS extensions, this is working group that's currently undergoing re-chartering. They have been focused heavily on DNSSEC for the last few years, but they feel that they are very close to getting to the point where they consider themselves done, and then you just go into a sort of a mode where they -- they clean up, and revise in response to operational considerations. So, the current -- I think there is the charter that is going up and has already gone out for review, and it simply says they are doing maintenance kind of work as opposed to taking on fundamental new work. Okay? Again they have a number of documents that the IESG is reviewing. They have published a number of things in the last six months. Well, I guess I misspoke. It is the name server identifier option which was recently published. That's the one that allows you to query a name server and determine what its ID is, which is useful when you are debugging issues related to operation, issues related to using Anycast for DNSSEC servers -- services. The OPSEC working group, you know, has a couple of documents the IESG is working on, filtering and rate limiting capabilities for IP network infrastructures, routing control plane security capabilities. They got other documents that they are currently still working on, and they recently published The Operational Security Current Best Practices. Okay. Another group that is actively working is SIDR, the Security Internet Domain Routing. This is one that clearly had a lot of applicability with -- to work that is going on here. It is really about providing the certificate infrastructure to secure, you know, delegations for address space and so forth. They don't have anything that has gone to the IESG yet. But they are churning away to make that happen. Another group that is of interest here would be GROW, the Global Routings Operations, and I have to -- I have, sort of -- unfortunately, I can't report that they have done very much in the last six months. They were -- they had a discussion back in March about whether they needed to shut down or whether they needed to re-charter. They did get some new chairs installed, but if you look at what has happened on the mailing list, there has been very little traffic, and they haven't actually re-chartered yet. So, I think this group is still one where there is a feeling that it is a good idea to have the working group. There is work that they ought to be doing. But it is unclear whether we really have the energy and the people participating to make it happen. Okay, and then to wrap it up, the Vancouver IETF is happening in December, next to next one in terms of new work that is going to be going on there, the BOF schedule is not really out yet. There is one BOF that has been approved officially, performance matrix for other layers, because a number of other possible BOFs that are still being discussed. There is a Wiki that lists them. It actually has a lot of stuff written there about possible new work, much of it that won't actually make it into a BOF this time around. I suggest people just go there and have a look to see if there is anything there that relates to what they are interested in, or go to the agenda to see what has actually officially been scheduled. Okay, and then I just have a page of general references if you want to get more info. The main place to go is the tools.ieff.org website. If you go to the working group page, they have all the information you would ever want to know about all the working groups, and if you click on one for a particular working group, it has all the charters and all the drafts that, you know, explains what this state is and so forth. So it is a one- stop-shop to find out what is going on. And that's it, any questions?

MR. CURRAN: Microphones are open.

MR. NARTEN: Thanks, then.

MR. CURRAN: Thank you very much. (Applause)

2007-13: Removal of ISP Immediate Need from End-User

MR. PLZAK: Okay. On we go to Policy Proposal 2007-13: Removal of ISP Immediate Need from End user. Introduced in April of this year, designated a formal proposal on 18th of May. A first discussion is going to be at this meeting -- has not been revised. ARIN staff understands this proposal will remove Section 4.3.4 from the policy manual, "Additional considerations." In order to remove text that conflicts with Section "4.2.1.6 Immediate need." Shepherds are Stacy and Leo. Excuse me, 10 posts by people, 5 for, none against. There is exemplar comment. "The Counsel again, sees no risk" Staff comments, "If immediate need clause is removed from this policy, then immediate need policy (Number Resource Policy Manual section 4.2.1.6) needs to be amended to provide for end users. Otherwise, ARIN may not be able to meet the needs of end users who have no current address space in use." So, the change would be to removal -- we probably is going to change the removal of 4.3.4. Implementation assessment minimum, but it might take us a little longer, so we are saying 120 days -- need change guidelines, and do some staff training. And so I would like to call Owen. (Pause) (Discussion off the record)

MR. DeLONG: Okay, worked on the first try this time. So this policy proposal grew out of the discussions from last meeting also and basically it removes the following section from the NRPM. The net effect, this is essentially a no-op language clean-up. 4.2.1.6 -- really is no longer used by end users because they primarily qualify under the multihoming policy in Section 4.3 and the language in 4.2.1.6 specifically states that it applies to ISPs only. And then this weird clause in 4.2.1.6 -- or I'm sorry, 4.3 that we are trying to delete -- refers to it for end users. So it is not really necessary anymore. Removal of this section won't actually disable the other end user policies. So staff should be able to meet end user needs using the multihoming and micro-allocation policies and the other end user policies that are still in existence. Okay, that is it.

MR. CURRAN: Microphones are open. 2007-13 -- microphones remain open. Yes, front microphone?

MR. LEIBRAND: I'm Scott Leibrand, Internap. I'm not sure you addressed the staff comment. Would you care to elaborate on that?

MR. DeLONG: Yes, the staff comment was that 4.2.1.6 would need to be modified in order to meet the needs of end users but 4.2.1.6 is a policy that specifically refers to immediate need for ISPs and it is not clear that any end users still need that functionality that is provided there. The immediate need policy really doesn't reference immediate need. I don't know if it is possible to get 4.2.1.6 on the screen or not. But it is --

MR. CURRAN: Everyone has 4.2.1.6 in their folders, if they want to look at the Resource Manual.

MR. DELONG: The bottom line is that for the most part, end users that -- I think the community intends to give space to qualify either under the existing multihoming policy, the exciting end user policy or the existing policies for critical infrastructure, the micro- allocation policy. And I don't think that the immediate need policy really expands that scope in a meaningful way and the language in the policy document, as it is worded, creates sort of this conflict between the cause referenced from the end user and the cause that -- the cause itself, where the cause referenced in the end user policy specifically says that it applies to ISPs only. But then there is this reference to it in the end user policy saying it could be applied to end users. And so, you know, technically the policy manual disagrees with itself, and the easy way to clean that up is to remove the statement from the end user portion where it is not really benefiting anyone anyway.

MR. CURRAN: Okay. Far microphone?

MR. SPRUNK: Stephen Sprunk, Polycom. I do support the policy, you know, referencing 4.2.1.6 from the end user section is definitely incorrect. I do have a question though. It looks like 4.3.3 says that, you know, you can only get new end user allocations if you have efficiently utilize previous ones. So, without the reference to the immediate need policy, will staff still interpret that as, you know, you can get an initial allocation since you don't have one you can previously utilize?

MR. CURRAN: Okay. I want -- which section are you referring to exactly?

MR. SPRUNK: 4.3.3.

MR. CURRAN: 4.3.3. If we could get that up, that would be useful.

MR. DeLONG: Right. 4.3.2.1 and 4.3.2.2 are the policies under which you would qualify for an initial assignment. 4.3.3 is specifically for additional assignments.

MR. CURRAN: Right, subsequent assignments.

MR. SPRUNK: Well, that is not how I read it. I mean, I read it as 4.3.3 also, you know, specifying when 4.3.2 applies.

MR. CURRAN: Okay. So, point of information. Leslie, would you approach the mic?

MS. NOBILE: Stephen is correct. That is for initial assignment to end users, that Section 4.3.3.

MR. CURRAN: Okay.

MR. DeLONG: Including utilization, right.

MR. CURRAN: Okay, so that clarifies the interpretation. Given that, would you vote for this policy proposal as written?

MR. SPRUNK: Yes, I still support the proposal. I've just -- I just want to make sure that you know, taking out this section isn't going to make it impossible to get a first allocation -- sorry, first assignment for an end user.

MR. CURRAN: Okay.

MR. DeLONG: Sir, that certainly is not the intent of the author in writing the proposal and my understanding in reading, you know, section 4.3.2 and 4.3.3 was that 4.3.3 would be applied either to your provider assigned addresses where it existed or it would, you know, your request would be reviewed based on your justified utilization of the space you don't have yet.

MR. CURRAN: Okay.

MR. DELONG: This would create a deadlock.

MR. CURRAN: Right, Leo?

MR. BICKNELL: Leo Bicknell, ARIN AC. I kind of have a question for staff over this, because I think they have commented generically on this issue at a previous meeting. And that is, I believe staff has resolved this conflict because you are right, policies and the manual today are in conflict in the favor of giving end users assignments under this, whereas your policy goes the other way, resolving it and removing that as able. So, I just would like staff to say if they have actually given out space under that interpretation.

MR. CURRAN: Point of information. Leslie, could you answer? Have we given out assignments to end users under the immediate need policy?

MS. NOBILE: Yes, we have.

MR. CURRAN: Okay. Do you know the number or order of magnitude?

MS. NOBILE: I have -- I can look. I have those stats previously.

MR. CURRAN: Okay.

MS. NOBILE: But the staff comment was if this is removed from the end user policy, there is no other option for an end user if they actually do have an immediate need and have no utilization of existing space, which is a requirement in the current policy.

MR. CURRAN: Okay.

MR. BICKNELL: And I guess the only other question there is back down to, how often has it been in --

MR. CURRAN: Can you check the number?

MR. BICKNELL: Okay.

MR. DeLONG: In that case, is it too late for me to withdraw the policy? (Laughter)

MR. CURRAN: No, you can withdraw the policy.

MR. DeLONG: The policy is withdrawn.

MR. CURRAN: Okay. Policy proposal is withdrawn. (Applause)

MR. DeLONG: Thank you -- thank you all.

2007-22: Expand timeframe of Additional Requests

MR. PLZAK: Okay. Policy proposal 2007-22: Expand Timeframe of Additional Request. First introduced in August, and that's in a formal proposal. Several weeks later, this is the first discussion of public policy meeting. Text has not been revised. Staff understands that proposal will change the allocation timeframe of 4.2.4.4 from 6 months to 12; Shepherds are Marla and Matt. Prior to being a formal proposal, there were about 51 posts by 22 people with 3 in favor, 2 against. Since the formal proposal, 3 posts by 2 people, none for, one against. Do you see the coma -- comment? Counsel's being consistent now. No liability risk. Staff comments, "In addition to change in time period from six months to one year, this policy removes the qualification criteria that a member must be a subscriber with a direct ARIN allocation. If an organization has no allocation history with ARIN, it makes it difficult to reliably verify and evaluate a 12-month projection." ARIN staff changes -- suggests changing the section name of the policy manual from 6 months to 12 months, and the change would be a modification section 4.2.4.4. Minimal impact as far as putting it in this plate, 30 to 90 days after ratification, need to update guidelines, need to do some training, and we will have to change a couple of templates. And so -- Dan, who is standing right behind me? 115 (Laughter)

MR. ALEXANDER: Okay. Good morning. Based on the staff feedback I did make the modifications that were mentioned. So, what is above the line was the original request and what is below is the updated where the header -- the section header's name would be changed and it also includes the fact that it needs to be a subscriber member to mean that the member is already a holder of address space. The main reason for this was simply for organizations that repeatedly go back and get address space because they are growing, those subsequent allocations aren't always contiguous. And there is a desire to provide better aggregation. When looked at the other RIRs, noticed everyone has some variation of a 12- month allocation window with the exception of ARIN being three and six months. The 3-month-timeframe hasn't been -- there is no request to change that, because it is a good throttle for organizations that don't have historical trends established -- to kind of gauged that what they think they need based on what they really need, it is a good policy. The postings on the PPML, some of the concerns were you know does this promote hoarding of address space? And the question (off mike) has raised is, is the allocation window really the best, you know, means to control something like that? The application review process when ARIN reviews an app is, you know, really the netter place. Reclamation policies would be a better place for something like that. And I'm not sure, you know, if that is really the -- a concern worth withdrawing this. The other concern was does this increase the run on the bank, you know, where people -- you know, does this mean that the end date would be reached faster? And the -- you know, the slow start method of allocations and the application review process. With those in place, this doesn't really change how fast organizations are consuming address space. The -- one other thing I would point out is it was specifically put in there that, you know, they may choose to request up to a 12-month supply of address space. When ARIN reviews an application, that doesn't mean that they are going to get it. And that is it.

MR. CURRAN: Okay. Policy proposal 2007-22. Any discussion, please approach the mics?

MS. AZINGER: Marla Azinger, Frontier Communications. I support this policy proposal, which kind of surprises myself, because the run on the bank issue is a concern of mine. But when I look at how ARIN staff make people justify their space, and the fact that someone actually has to have a history of how quickly they are using it, I know from experience that the ARIN staff is really looking through everything. And I don't know if they got the chance to get the numbers together, but there are organizations that come back for address space very quickly and then the -- contigious address space doesn't occur, because they didn't reserve a large enough block for them, because they didn't expect to actually come back that fast, and it is. So, historically the staff, I do trust, has an ability to look at someone's request and figure out if they really do need it or not, like it says, up to they can ask for it. But again, if ARIN staff really doesn't think they grew that fast, then no. They are not going to get it. And I'm all for trying to do the best we can to getting contiguous address space out there as opposed to chunking it up and getting worse routing going on. So, that's why I'm in a spot.

MR. CURRAN: So would you -- you are for this proposal?

MS. AZINGER: Yes.

MR. CURRAN: Okay, thank you. Microphones remain open. Rear microphone?

MR. NARTEN: Thomas Narten, from IBM. I agree this won't lead to a run on the bank per se. But I think it does actually change the endgame somewhat in the sense of when you are -- when there is not a whole lot left. There is less than a -- you know, a year's worth of address space left in some sense. It will impact who gets the remaining bits -- you know, the remaining chunks, because if you can get 12 months worth, that means that somebody who is right behind you may get zero. Whereas, if you only can get six months worth, then they might be able to get some more. You know, that said -- so this is one of the -- in some sense is related to the whole run out question. You know, that said, I think I'm in support of this generally, though just observing that the run out -- does that impact on the run out?

MR. CURRAN: Okay. Good to know. Microphones remain open.

MR. LEIBRAND: Scott Leibrand, Internap.

MR. CURRAN: Yes.

MR. LEIBRAND: I am not willing to support this proposal because of the you can call it run on the bank, you can call it endgame, whatever the issues are that people will be able to go ahead and request their (off mike) allocation a bit sooner and end up with more IP addresses and it is less equability. And I share your concerns about aggregation, and I think that could be better addressed by ARIN reserving bigger blocks for people, and if they don't use them, well, then, give them to somebody else. I'm not sure that we are moving in the right direction with this policy proposal. I would be more in favor of making other changes in our region and if we want global coordination of time frames suggesting to other regions that they drop theirs from months to 6. I would be less opposed to this proposal if we had some assurance that at the endgame, ARIN would not be giving out 12 months. But I don't think there's any assurance in this policy and I don't know that ARIN staff can make that assurance. So, without that assurance, I don't think I support this.

MR. CURRAN: Okay. Any response?

MR. DeLONG: I -- I purposely left out a lot of details, as far as trying to deal with the end-game, because I felt that that should be addressed in -- in a policy, you know, in and of itself.

MR. CURRAN: Okay. Rear microphone?

MR. WILLIAMSON: David Williamson, Tell Me Networks, a Microsoft subsidiary. I support this proposal, I don't think there's any fair way to achieve the run out in -- or run of the bank, or anything resembling the endgame, in any equitable way, anyway and I think this will definitely help preserve, you know, better aggregation, what's in the routing system, which I think is going to become more and more of an issue as tie goes on. That said, I -- we can also, if the committee decides, you know, a year-and-a-half from now, as we're getting much closer to the endgame, that 12 months is too much, we can always change it again. So, I think for now, this an entirely adequate proposal. Thank you.

MR. CURRAN: Okay. Microphones remain open, rear microphone?

MR. SCHILLER: Jason Schiller, UUNet, Verizon Business. I want to address some of the things that Scott said, and I also want to echo the comments that David just provided. I am in favor of this policy, mostly because it helps with aggregation, which keeps routes out of the routing table. With regard to -- and being able to put space in reserve, assuming that they actually do decide to put space in reserve, that doesn't necessarily help with the aggregation problem, internally, inside someone's internal network. The problem being, if you're given a small allocation and then you want to further subdivide that to do aggregation within your network, and then you grow into the adjacent block, you have to double-stack those aggregations. So, while it does help with Internet aggregation, it does not help with internal aggregation, and that's something that we have struggled with in IPv4 in the past I'd also like to address the endgame scenario. If people think that we need to change, how we're giving out addresses, when exhaustion is on the doorstep, then I would urge people to start putting forward policies that specify how that last /8 should be used, assuming that global policy we discussed yesterday, doesn't get adopted. (Applause)

MR. CURRAN: Got it. Okay, microphones remain open. Any other comments on 2007-22? Rob Seastrom?

MR. SEASTROM: I'd like to thank Jason Schiller for making that comment, because he actually just changed my mind on whether I support this proposal or not. I was initially opposed to it, because as Schiller just pointed out, there is space -- there's reserve to buy ARIN adjacent to the allocation you got, and -- that really doesn't help you if you can't put that space into play on your network for purposes of internal aggregation, and that's important for larger networks. So, I haven't supported this proposal.

MR. CURRAN: Okay. Front microphone?

MR. CASSIMERE: Nigel Cassimere, Caribbean Telecommunications Union. I would tend to support this proposal as well, because, at least based on my understanding that I don't see anything in here that obliges ARIN, to grant a 12- month allocation on request. People can request up to a 12-month allocation, but, I mean, I would -- I would trust that ARIN would be a good steward and based on the circumstances, at a point in time, allocate what would be prudent in the best interest of the overall community. So, if -- as the endgame approaches, 12-month allocations might not be that -- the best thing to do in the best interest of everyone who might need addresses. I think you can still request your 12-month if -- if there is not a change in policy by then. But maybe, ARIN might only be allocating 3 months at a time, 6 months at a time, as might be appropriate, and I think, I think they would do that.

MR. CURRAN: So, you would be against this proposal as written?

MR. CASSIMERE: No, no, I would say I am in support of.

MR. CURRAN: Okay, that's what I wanted to understand. (Discussion off the record) (Laughter)

MR. CURRAN: Okay, uh, I'm here, more coffee. (Laughter)

MR. CURRAN: Microphones remain open. Microphones remain open. Seeing no further discussion; thank you for the presentation. (Applause)

MR. PLZAK: Okay. We're going to ask for a show of hands on this, to help the Advisory Council in their deliberations on this topic. Policy Proposal 2007-22 is the policy proposal before us. I'm going to ask for a show of hands in favor and a show of hands opposed. Everyone is to participate. We ask that you raise your hand only once in this practice. Everyone in favor Policy Proposal 2007-22, please raise your hand, now? (Pause)

MR. PLZAK: Okay, thank you. Everyone opposed to Policy Proposal 2007-22, raise your hands, now? Nice and high. (Pause)

MR. PLZAK: Okay. (Pause)

MR. PLZAK: This is an important way we get community input. The other way we can probably get community input is to vote for things like AC Members and Board Members, remember to do that too. (Pause)

MR. PLZAK: Okay, on the topic of 2007-22, with a 153 people in the room, uh, all those in favor, 64; all those opposed, 1. The information on the show of hands will be given to the AC for their deliberations, thank you.

2007:14: Resource Review Process

MR. PLZAK: Okay, Policy Proposal 2007-14, Resource Review Process. First introduced, May of this year, designated a formal proposal 24 July, that's because there was some work with the author by the AC, discussed first time and -- the meeting would be here, not revised. This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a minimum 6-month grace period so that the current users you shall have time to stop using any resources to be reclaimed. The shepherds are, Rob and Leo. Prior to this being a formal proposal, there were 17 posts by 7 people, with 3 in favor, 2 against. Since, being designated a proposal, 8 posts by 6 people, 2 for and none against, there is a comment. And Counsel says, "Counsel strongly supports some version of this policy being enacted and believes adoption of this policy will save significant future legal fees. This policy proposal spells out a series of customary contractual policies in rights that are important to make as clear as possible. "Counsel does not agree with that portion of the description, which states, ARIN, 'feels that current policy does not give them power,' and believe such powers are adequately vested in ARIN, but believes instead, such powers can always be more carefully delineated for ease of understanding." This is as of October of this year. "Staff," as of October this year, "2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency." Point 3 requires ARIN notify an organization each time a review is conducted. ARIN interprets a review to mean a full-audit of an organization's resource, conducted by ARIN staff. Point 4 uses the terms, single or aggregate block and whole resources. "Are these terms used synonymously to refer to a single ZIDR prefix, or to a contiguous range of editor assets?" Point 6 compels ARIN to take action, which doesn't reconcile with the RSA, which as articulated above, allows ARIN to take whatever actions necessary. It also didn't indicate where it should be placed in the policy manual, staff reported in Section 12, "Resource Review Process." Minimal impact on an implementation, 30 to 90 days, we'd change guidelines, we have to make some registration system changes, needed staff training. This may cause a increase in workload and may increase turn- around time -- and those would actually show up in result of experience. So, with that I would ask Stephen, if you could come up and make a presentation? (Discussion off the record)

MR. SPRUNK: Okay, so at previous meetings statements made by, you know, someone to -- Owen, and someone to myself that despite the fact that the RSA grants there an authority to conduct, you know, reviews or audits at any time, they didn't believe that the policy actually enabled staff to take advantage of that part of the RSA. This policy is intended to clarify that ability and also to prevent any abuse, not that we think it would happen but, you know, that's always a good thing. So, the spirit of the policy is to help -- is to help recover disused or abandoned address space. It's not intended to create and automatic annual audit, which was one of the common comments on PPML -- its not intended that you know, you're going to have to submit to this every year or everyone's going to you know, that staff is going to go out after everybody. You know, the intent would be to go after the low-hanging fruit, the ones that you know, without even having viewed the review ARIN knows there is a good likelihood of success, in recovering some space. There is a Legacy exemption for spaces in active use, and that's because of the current, you know, legal question about what we can do with that space, if anything. That exemption does not apply to space that is not in use, specifically, space that would be abandoned or that the Legacy holder may not even realize they have anymore. So, staff comments, as far as reconciling with the RSA, the difference is intentional. The RSA says that staff can, you know, audit you as often as they want -- they can audit you anytime they want, they can take any action they want. That makes me really uncomfortable. And, you know, the limitation, you know, without cause of once per year, I think that's reasonable, you know, the guarantee of time to read number, I think that's reasonable. And also, you know, what is limiting the actions that can be taken as far as -- you know, taking back only part -- you know, parts of a block, you know, trying to retain aggregation when that's done et cetera. So, the idea is to try to make this as fair as possible. You know, some folks were talking about, you know, annual audits were you know, a bunch of ARIN's storm troopers would come into your office and review every document you had. That is not the intent. The intent is that it would be a review similar to the same type of paperwork you have to go through today whenever you're requesting a new allocation. In fact, you know, the majority of you are likely to never see this done under this policy because you're going through that paperwork more than every 12 months anyways. Okay, compliance staff's interpretation is consistent with ours. It does mean compliance with policy at the current -- at the time of review. That's something that we should be keeping up with anyways. There is a small risk here. If policy is significantly changed, you know, as we get close to exhaustion, this could mean, you know, something what you're in compliance today suddenly becomes non-compliant. That's something that folks who are thinking about making radical changes in policy would need to keep in mind and, you know, we would need to keep in mind if looking to adopt those policies or not. The question about the term "aggregate block" was just an attempt to minimize the fragmentation of return space. So if someone has a /16 and they're only using half of it, we don't want them returning every other /24. We want them returning a /17. You know, exactly how that plays out because I know that not all allocations are an exact CIDR block. That would be up to staff to do something reasonable. But I think that all of you would prefer to see as much aggregation as possible. We wouldn't want, you know, someone who has a block today end up with 17 blocks after some sort of reclamation was done, whether voluntary or not. And last one is the question about the whole time. This was actually an earlier draft. So that doesn't apply anymore, just the comments would arise. Okay, so based on PPML, there seems to good consensus that some sort of reclamation effort is needed. You know, reducing abuse for blocks that are no longer used or people aren't keeping track of, it may help us find more addresses to hand out later. However, it's unlikely as to make any significant effect on the run out date, that the amount of growth and the rate of consumption is just too high. You know, we -- there's not enough unused address space to make a material effect any more than 6 months or a year. And in the grand scheme of things, that's not much. You know, there seems to be good consensus that the current standard of ARIN can be whatever it wants, whenever it wants, isn't good and we need some sort of defined process, and that the review process shouldn't be anymore stringent than the existing standard. Okay, the -- probably one of the most contentious parts was the 12-month number, and that number was fairly arbitrarily picked. Actually, it was picked based on double the current 6-month allocation window. And, you know, so there were quite a few people who are not wanting to get into an annual review-type situation. We don't expect that to happen. I asked at least once if there were any other numbers that people would be more comfortable with; 12, 18, 36, 24, and didn't get any responses; however, we're open to changing that definitely. And if it ends up getting adopted, then we're going to switch to a 12-month allocation window. Perhaps it would make sense to increase this. So, if anybody is specifically against the proposal only because of this number, if you could state that and suggest what number you would find acceptable, I'd appreciate that. That's it.

MR. CURRAN: Okay, microphones are open. Public Policy Proposal 2007-14. Yes, Bill?

MR. WOODCOCK: Questions for the authors. Has any thought been given as to the degree of guidance or non-guidance to staff about how they would go about picking once the review is intended just as a mechanism to allow them to go after folks that they consider fraudulent, or this also -- like another way of doing it would be for staff to say, we're going to pick 1 percent of resources or 50 resources each year and do this randomly, and then you've also got, kind of, a preventative effect as well as a retributive effect or something? I don't know. Just something for discussion.

MR. SPRUNK: So my response to that is that that's really more of an operational concern than policy. It's also heavily dependent on the resources that are available. And one of the staff comments is that this would increase the staff requirements potentially depending on how much effort they put into it. So I think that's -- you know, it's a matter for the board to determine if they want to increase staffing for this purpose. You know, and I think that there's an obvious set of low-hanging fruit that, I think -- that, you know, and I see Leslie nodding her head, that they would want to go after first. And maybe, we would put in some sort of recommendation because the ACSP is where they would go for. But I don't want to put any specifics in the policy because I don't think that's the appropriate place.

MR. CURRAN: Okay. Microphones are open. I'm going to take -- I actually miss the order of people at the mic, I'm sorry. I'll take counsel first. Could you just clarify your intent -- let me give a hypothesis and see how you would respond to this. Let's assume that we had completed an audit of someone in a routine way, 30 days previously, and now we had an indicia of fraud that staff felt required an audit. Would your policy permit that?

MR. SPRUNK: "To be" does not place any limitation on the frequency if the ARIN staff has reason to believe that there is fraud.

MR. CURRAN: There is --

MR. SPRUNK: Yeah, "to be" does not give any limitation on the frequency if there is a reason to believe there is fraud. The limitation on the frequency is only for a review without cause.

MR. CURRAN: Okay, microphones on.

MR. DeLONG: All right, I think Stephen just covered what I came up to say because I didn't think it was completely very well covered, but, yeah, the 12-month limit is only for things where there's no cause and ARIN just wants to do a review because they feel the space hasn't been reviewed in some time or whatever reason they come up with. But we don't want to see them doing that any more often than once a year. Certainly, we don't expect them to start doing it once a year to everyone or anything like that.

MR. CURRAN: Okay. Far microphone?

MR. WEST: Ken West, Sprint. I'm against the policy as written. I believe a 12-month is too frequent a timeframe the do a complete review. If we had to review our entire address space, it could take the better part of 12 months.

MR. CURRAN: Okay, so you're against the policy for that reason?

MR. WEST: Correct, for that reason.

MR. CURRAN: Would there be a timeframe that for which you would support the policy?

MR. WEST: I would have to look into how long I would think it would take for a complete audit, but 24 months just off the top of my head.

MR. CURRAN: Okay, good information. Far microphone?

MR. BURDEN: Ken Burden, Hewlett-Packard. I realize this is probably oriented mostly towards IPv4, but what, for example, in the IPv6 PA space requirements? Historically, there's been a 1-year 2-year and now 5-year timeframe in which to provide services. How does that relate to this? Are there periodic checks, or do you wait until the end of that period? How will that relate to that?

MR. CURRAN: Could -- I hate to say it, but could you repeat that --

MR. BURDEN: All right.

MR. CURRAN: -- one more because I'm not sure I got it.

MR. BURDEN: All right, if you look at the IPv6 provider aggregateable or assignable whatever we want to --

MR. CURRAN: Correct.

MR. BURDEN: PA space criteria, one of the rules in there, which one historically has said 1 year, now -- then 2 year, but currently says 5 years (off mike) after the 4 years.

MR. CURRAN: Yes, for 200.

MR. BURDEN: How does that relate to this? They have 5 years until this would happen, they -- nothing happens in the interim? Is -- how does that relate to this? I know it's a little bit different than perhaps you're intending mostly for IPv4, but on IPv6, and I'm curious what the ramifications would be.

MR. SPRUNK: Well, I think, there's two issues there. First of all in IPv6, especially, if you're in the 5-year window for that initial allocation, there's really nothing ARIN can -- ARIN can't take back from you because you already have the minimum. But, beyond that, you know, going into future allocations, I think, that if ARIN did do a review during that period, you know, they would look at, are you on track to making that goal? So if review you a year later, but you have four years left, you know, are you on track, if you have made any progress, or you have you -- really have you done nothing with it in the mean time?

MR. BURDEN: Those are my concern. If you waited right until the end of 5 years versus say 4 years and say, have you -- are your plans anymore firm than they were four years previously, for example?

MR. CURRAN: I do not know how the staff would interpret this, but with respect to our requirement, that was partially fulfilled. Since the current guideline say 5 years for 200 organizations --

MR. BURDEN: Right.

MR. CURRAN: -- it's -- you know, people are known to have hockey sticks at the end of their growth curve. It's possible you did 4-1/2 years of excellent planning and you're on track if it doesn't look --

MR. BURDEN: So then the question would be, in 5 years that they haven't given it to anybody or they haven't -- they've only gotten half of those. What does that mean?

MR. CURRAN: Presently, there's no definition for what happens in an organization that needs that --

MR. BURDEN: Exactly. That's my question.

MR. CURRAN: This policy doesn't change that circumstance.

MR. BURDEN: Right. I'm just trying -- I'm trying to understand how this might relate to it, and apparently it doesn't.

MR. CURRAN: Correct. Would you be for or against the policy?

MR. BURDEN: Well the timeframe being from a very large corporation or anybody, that you've got a large chuck of address space, your renumbering time is going to be bigger than if you had a smaller chunk of address space. So, be it some variability based on address, block size or something, maybe something worth considering, but 1 year seems like a little too short.

MR. CURRAN: So you would be against the policy as written?

MR. BURDEN: As written, yes.

MR. CURRAN: Yes, okay. Some guy in the back?

MR. DIVINS: Dave Divins, Server Vault. I'm in favor of this policy. And I just wanted to make a comment regarding -- to the comments with, "It could take a year for somebody's address space to be audited." The policy, as written, appears to be that no additional audit could be done if the audit was completed within 12 months. So if it took you 14 months to do your audit, at the end of that audit, it appears that you would have another 12 months before another audit can be done. So, even if it took that 14 months, you can't have -- it appears as written, you can have a stacking effect. Is that correct?

MR. SPRUNK: Yeah, that would be correct. The other comment I would have is that, you know, the type