ARIN XX Public Policy Meeting Day 2, Draft Transcript - 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.
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.
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 188.8.131.52. 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: 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.
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 --
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 "184.108.40.206 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 220.127.116.11) 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. 18.104.22.168 -- really is no longer used by end users because they primarily qualify under the multihoming policy in Section 4.3 and the language in 22.214.171.124 specifically states that it applies to ISPs only. And then this weird clause in 126.96.36.199 -- 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 188.8.131.52 would need to be modified in order to meet the needs of end users but 184.108.40.206 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 220.127.116.11 on the screen or not. But it is --
MR. CURRAN: Everyone has 18.104.22.168 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 22.214.171.124 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. 126.96.36.199 and 188.8.131.52 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 184.108.40.206 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 220.127.116.11. 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 -- the review would be the same type of review you do today whenever you're requested to do a block. So a large ISP, I mean, you're going to be requesting today a block at least every 6 months. So obviously, you're -- that review process isn't taking you more than 6 months today. And also, if you're coming back every 6 months, the "without cost" part would never affect you. That is only for people who haven't requested anything in the last 12 months.
MR. CURRAN: Microphones remain open. Front microphone?
MS. SCHILLER: Okay.
MR. CURRAN: Okay, rear microphone?
MS. SCHILLER: Heather Schiller of Verizon Business. Not in favor of this policy, but not for the reason that I'm going to ask because I have a clarifying question. So part eight says legacy resources and active use regardless of utilization are not subject to revocation by ARIN. Does that mean legacy resources not in active use are subject to revocation?
MR. SPRUNK: That's -- I will -- I know, but that's more of a question for the counsel. Based on the comments of the panel at the last meeting, there was a theory that if a resource is abandoned, then it would have sheaved back to ARIN. I don't know if that is something we could put into practice or not. I definitely want to provide the exemptions for people who are using their address space. As far as what happens to people who aren't using that address space all, I think that's still a little unclear what we can do if anything. There's theories that we can do something; there's also, of course, theories we can't.
MR. CURRAN: I was going to say, with respect to this policy proposal, it doesn't answer the question of what ARIN does with respect to a legacy block that's unused. That is still an open question before the community.
MS. SCHILLER: And the other part of my question is, what do you mean by "utilization of legacy resources shall be considered during our review to assess overall compliance"? Compliance with what, and for what purpose?
MR. SPRUNK: So the idea is that if you have both legacy and non-legacy resources, then ARIN would look at the utilization of both. And while they can't take away your legacy resources, then potentially, if both were not justified, then they could potentially take away some of your ARIN resources.
MS. SCHILLER: Yeah, so there are -- already there are some policy today unless they, well, correct me if I'm wrong, that they can already review your legacy resources if you're requesting additional address space?
MR. SPRUNK: Yes.
MS. SCHILLER: So, not sure if that part is needed?
MR. SPRUNK: Yeah.
MR. CURRAN: Okay, microphones remain open. Front microphone?
MR. WEILER: Sam Weiler, SPARTA. I support this policy. According to the discussion on the PPML, it sounds like the current RSA allows ARIN to do such reviews whenever they want to. This ties they hands. I think the current policy in the RSA is over broad, and I'm in favor of tying ARIN's hands when it has done things that are over broad in that way.
MR. CURRAN: Okay, perfectly fair? Microphones remain open.
MR. BICKNELL: Leo Bicknell, ARIN AC, partially addressing two previous commenter's questions, I support this policy, and specifically regarding the 6-months to effective return, I have no sympathy for someone who has so much address space they can't renumber out of it in 6 months to return it because they're not using it, if that makes sense.
MR. SPRUNK: The thought there is that, you know, they -- depend -- you know, to try to keep it so that you're keeping a whole aggregate after the return.
MR. BICKNELL: Sure.
MR. SPRUNK: You know, say you're using the top part and the bottom part of a block, you know, you would need to renumber half into the other half. And so, it's not a matter of -- you know, obviously, if you're not using a block entirely, the part could be returned, and you could do that immediately. But potentially, you may need to renumber out of what you're using to increase the utilization of the part you're going to keep.
MR. BICKNELL: Correct, but the bigger the block, the bigger the amount of potential space that can be returned to the free pool, and that's the bigger benefit to the community.
MR. SPRUNK: Right. So there is the possibility of extensions that ARIN believes are working in good faith.
MR. BICKNELL: Absolutely.
MR. SPRUNK: Yeah.
MR. CURRAN: Okay. We got a far microphone, then rear.
MR. DICKSON: Sort of a question/observation of both 5 and 6 -- oh, sorry, 4 and 5. The last portion of 4 about the portion retained would comprise of single aggregate block, what about the possibility of effectively overlapping blocks where, for instance, with a /16 having a /18 returned to ARIN? It would create the problem of the blocks overlapping, but with the understanding that that portion is returned to ARIN is not to be used effectively, they would not be overlapped other than so allowing the original owner of the large block internally to disaggregate into smaller portions, but to still announce the aggregate and then have ARIN use the smaller block. I'm not sure that question makes sense, but do you understand what I'm talking about.
MR. SPRUNK: Yeah, I think the question is say you have a /16 and you want to return a single /18 and keep the rest of it. I think that gets down to where the wording says, "substantially in compliance" or "substantially not in compliance". I think, you know, returning a quarter of your space probably isn't going to make a big difference when you're talking about a "roughly in compliance". If you only need to return a quarter of your space, it is probably not worth the effort because in a year you're just going to be getting it back anyways. ARIN has better things to do. But the goal there is to -- you know, say you have a 16 and you need to return half of it, we don't want you keeping two of the /18s and returning two /18s, and one -- you're keeping a single /17? That's the intent of that. But there's a little bit of leeway to do what makes sense and not be -- you know, say, well, you have to hit exactly 80 percent. Well, you know, say, what makes sense turns out to be 70 percent, well, that's better than 30 percent you're at before. That's the general intent; it's to leave enough leeway to do what makes sense.
MR. CURRAN: Okay.
MR. DICKSON: I understand that. Just to clarify, my point is, if in achieving a better utilization, it results in effectively de-aggregation of blocks, if you have /16 and you break it into /17 and two /18s, returning one /18, that increases the number of router slots globally by two. Returning just the /18 increases it only by one. Every time you do that, it increases the number of router slots globally by one. If it's going to be something happens on a regular basis, that's concerning.
MR. SPRUNK: I would say, if it's a case of being that close, then I would say just keep to /16. That's -- you know, that's not the level -- you know, returning a quarter of your space probably is not going to make a substantial difference. It's more the question of -- you know, I know for instance organizations that have a dozen /16s and they're only using a /24 today. That's the kind of thing we're going after. It's not the matter of it's a 20 percent difference in the utilization, but the fact you're going from 10 percent utilization to 50.
MR. CURRAN: Given the risk though, would you be for or against the policy proposal?
MR. DICKSON: For.
MR. CURRAN: For? Thank you. Microphones remain open. Ray?
MR. PLZAK: Counsel, given Sam's last statement in assuming no change to the current RSA, it would appear then that the policy statement and the NRPM would be more restrictive than that of what is stated in the RSA, which would take precedents.
MR. RYAN: I'd like to answer that question after reflection as opposed to just giving a horseback opinion on it.
MR. CURRAN: Okay.
MR. RYAN: Let me just reflect, you know, the thought process without the answer. When we sign an agreement, that is, the RSA with someone, there's a promise they make and a promise we make. The way that the community has always operated is that policies, when enacted after the agreement, are incorporated by reference in the agreement. So a change in policy, say, let's say it's a legacy RSA, where we now change the community's policies to permit transfers, that transfer policy would be read into the RSA unless there's promise in the RSA not to read in subsequent policies. So, I think, the generalized thought that I have in reflecting is that anything that's in a policy here that makes a change in the existing policy and is inconsistent with the RSA, poses a legal headache. And I can see people arguing out of both sides of their mouth against ARIN when they go to court, arguing in the first instance, if they like the policy, that the policy controls, or arguing that they've got a contract, and now we pass something that's inconsistent with the contract and which controls. And I think that's why they built courthouses. I prefer, frankly, to try and work these things out so that we don't have this kind of a clear problem. But I need to think through how it works in this particular case.
MR. CURRAN: Do you have a particular question to counsel?
MR. WEILER: I have a particular suggestion for counsel.
MR. CURRAN: Sure.
MR. WEILER: It's seems that the way to avoid these conflicts in the future is to propose the least restrictive RSA you can.
MR. CURRAN: Okay. Wonderful comment. Now, I'd like to say --
MR. RYAN: I don't agree, but I -- could we give you --
MR. CURRAN: No, you -- that's fair and entitled.
SPEAKER: Question for counsel as well?
MR. CURRAN: Well, I'd first like to -- I'd like to comment. I get to comment with my chairman hat on. Clearly, if the community directs us to take a certain approach with respect to revisiting our resources and review process and the RSA is in conflict with that, then the board is ultimately the place where we're going to look at the wishes of the community, we're going to figure out what protection the RSA is giving the organization, and general, we tend our way in towards the community as long as we can do it. It's also true that the board is where the RSA can updated. So if it turns out that there's a conflict, then it needs to be resolved, and it can safely be resolved without endangering the organization, then a role of the RSA is what happens in those occasions. So it's not precluded at all that the policy adopted here won't force an RSA change, if it turns out it can be safely done, the board gets the benefit of in-depth counsel advice though to see how safe that is. That might make things more clear.
MS. NOBILE: I just had one question or comment. There is part of this policy that indicates that only the larger aggregate blocks should be reclaimed if those are the only useful blocks for ARIN to reclaim. And we actually reclaimed blocks of smaller /24s there are polices that actually have us issuing /24s currently. And if -- we would like to continue to reclaim those as we can. So it does seems a bit restrictive on the amount of address space that can be reclaimed I think.
MR. SPRUNK: I don't see a restriction in there. So could you point to --
MS. NOBILE: I could have sworn you said the larger aggregate blocks were useful and that you would want the larger blocks if that is not a restriction that is fine, but --
MR. SPRUNK: Well, the intent in that response was that we not increase the number of blocks being advertised, you know, not to have any negative effect on the routing tables. If, you know, I, for instance an organization has, you know, several large blocks, several small blocks, maybe part of their remediation plan is to return all of the small blocks. And then ARIN could make use of those in some fashion. So if -- the intent -- it isn't only to pull back large blocks the, you know, the intent is to pull back whatever people don't need.
MR. CURRAN: Understood. Owen?
MR. DeLONG: Yes. Again, the policy is intended to be crafted in such a way that it allows staff as much latitude as possible to do what makes sense in the circumstance, and actually encourages, as much as possible, the resource holder and staff to work together to come to an amicable solution to getting the resource holder into compliance. But also empowering staff to take action if the resource holder is not willing to comply.
MR. CURRAN: Okay. Further comments. I am going to close the microphones if I don't see further people up there. Okay.
MR. LEIBRAND: Scott Leibrand, Internap. I would like to if the policy authors agree see a consensus -- short consensus as to this timeframe, in light of the fact that we seem to have consensus for changing from six to twelve months.
MR. CURRAN: Okay.
MR. LEIBRAND: So when we do the show of hands, if the policy proposal authors would like to, I would like them to give a show of hands on whether 12 or 24 months might be better.
MR. CURRAN: Okay. So, first as written are you in favor or against?
MR. LEIBRAND: I am in favor of it with either or 24 months.
MR. CURRAN: Okay. But you would also like to know whether or not it could be rewritten to say 24 months not 12?
MR. LEIBRAND: I would like to know whether the community thinks the 24 months is more appropriate with the 12 month window.
MR. CURRAN: I turn to the proposal authors and I ask are you interested in knowing whether the community would support it at 24 months versus 12?
SPEAKER: (off mike)
MR. SPRUNK: I would like to know if the community is more in support of 24 months, if you can figure out how to phrase that question.
MR. CURRAN: Okay, so we actually can. This policy proposal presuming it has support, which we don't know yet, but presuming it does, could have a blank put in. And the blank would be for the matter of 12 months versus 24 months.
SPEAKER: If we could put the text of the proposal up.
MR. CURRAN: Okay, it is coming. Well, okay if you could put the text of the proposal up do you have it?
SPEAKER: The one that is on here?
MR. CURRAN: Take it and through -- put it up from the policy proposal archive.
SPEAKER: (off mike)
MR. CURRAN: Okay. Okay, so in the policy text there is a section -- section 2C, which reads, "At any other time, without cause unless a prior review has been completed in the preceding 12 months, there has been a suggestion to create a blank there and to allow filling that with the numbers 12 or 24." People who wish to speak on the matter of 12 versus 24, okay, on that sentence, 2C, at any time without cause unless a prior review has been completed in the proceeding blank months, I would some people who would like to see that filled in with 12 and those who would like to see it filled in 24, please take the microphones. If you would like to speak for 12 versus 24, or 24 versus 12, please take the microphones. Yes, Heather.
MS. SCHILLER: Heather Schiller, Verizon Business. And I hope I don't make you angry by saying I am not in favor of either. But I hope you understand why. We are huge and we have so much outer space that we couldn't possibly complete an audit within 24 months. And I know because I am doing it right now.
MR. CURRAN: Okay. I want to be clear. I am talking about the circumstance of this proposal going forward --
MS. SCHILLER: I understand.
MR. CURRAN: Would you prefer a 12 versus a 24?
MS. SCHILLER: Twenty four would be better because we need every bit of time that we could get.
MR. CURRAN: So noted, thank you. Far microphone, 12 versus 24?
MR. WEST: For much the same reason as Verizon, would be more commendable.
MR. CURRAN: Thank you.
MR. WEST: But I wouldn't want to put -- I would have to know it would be 24 before I would support the proposal.
MR. CURRAN: That is good to know. Front microphone.
MR. DeLONG: Owen DeLong, JITTR Networks, Policy coauthor. The statement in question here is not how long you have to complete the audit or review. The statement in question here is how long you have as a minimum time after your last review was completed before ARIN can come at you again and start another review. It is how much free time you have between reviews, minimum. It is not even a maximum free time. It is a minimum free time. If you are Verizon, you probably going to ARIN every six months for more addresses anyway and you wouldn't even get hit by this policy. And I would assume Sprint is probably in the same boat. So I really have trouble understanding their objections.
MR. WOODCOCK: And clearly they are the ones best prepared to handle 5 or 10 multiple simultaneous audits.
MR. CURRAN: Okay. Microphones remain open, would you like to respond to that comment.
MR. WEST: Yeah, what assurances would we have that the --
MR. WEST: Ken West, Sprint. What assurances we have that the review process wouldn't change from how it currently is. Because the proposal clearly states that any and all materials. It is very broadly written.
MR. SPRUNK: My only -- the best response I can give to that is that is what assurance do you have today?
MR. WEST: We are talking about a circumstance where the proposal provides guidelines that are more concrete than the present circumstances.
MR. SPRUNK: Any and all materials is more concrete than present?
MR. WEST: Today it's any and all materials as often as they want.
MR. SPRUNK: And when was the last time that Sprint was audited?
MR. CURRAN: That is a matter of subject to ARIN and Sprint not subject to the floor of the policy. Rear microphone?
MR. SETTLEMYRE: Ally Settlemyre, Microsoft, I just want to second what Heather said, 24 months would be much easier because it would be painful to go through the process of justifying all this space.
MR. CURRAN: Okay. Thank you any one like to speak towards the matter of having this filled in with a 12? We have heard people advocate for 24, I would like to know if anyone would like to advocate for 12 in this policy proposal. Yes, far mike.
MR. DICKSON: Brian Dickson Afilias. I would observe that most of the people commenting against the 12 would not be affected by the 12 or 24 for exactly those reasons that they are getting more space. So I am favor of 12 because it is not overly limiting on ARIN. I think ARIN should have the ability to go and look at things as they see fit.
MR. CURRAN: Would you support the policy proposal at 12, yes you are saying, would you support with a 24?
MR. DICKSON: Yes and yes.
MR. CURRAN: Okay, thank you. Microphones remain open on the topic of 12 versus 24. Leo.
MR. BICKNELL: I support it at 12, and one aspect of why I support it is after we run out of IPv4 space there will probably be an increased interest in recovering unused space, and this policy puts limits on it, so ARIN isn't auditing somebody everyday to see when they finally free it up. And because the 12 months is the space between, I think that is more than appropriate to go back and see if there might be something the community can use. So that is where I see this policy being more useful and I think 12 is a better number for that.
MR. CURRAN: You think 12 is a better number? Would you support the proposal at 24?
MR. BICKNELL: Yes.
MR. CURRAN: Yes but you prefer 12?
MR. BICKNELL: Yes.
MR. CURRAN: Thank you. Microphones remain open on the topic of 12 versus 24. Rob Seastrom?
MR. SEASTROM: I am slightly -- Rob Seastrom -- I am slightly more comfortable with 24 I would be even more comfortable with 36.
MR. CURRAN: Okay. Well, right now we are having the conversation of 24 versus 12 but --
MR. SEASTROM: I am slightly more comfortable with 24.
MR. CURRAN: Okay. If people strongly feel about a number other than 12 or 24, please approach the microphones. Seeing no other speakers I will again put the choices a blank back to 24 and 12. Twenty four and 12, if someone wants to speak in favor of either one please approach the mike. Okay, we are going to have -- we are talking about amending a proposal upon the floor.
MR. BRADNER: John.
MR. CURRAN: Yes.
MR. BRADNER: I don't think process wise we can amend the proposal on the floor. The author may choose to amend it if they want to but they -- we cannot just do a show of hands and say, the proposal is changed.
MR. CURRAN: Actually, I am happy to take you on the parliamentarian point. We did it prior.
MR. BRADNER: I know and they --
MR. CURRAN: And --
MR. BRADNER: The key point there was the author changed the proposal.
MR. CURRAN: I am going to ask, do the authors wish to have the proposals changed to 24?
MR. SPRUNK: If the straw poll shows that 24 has more support then we will amend it.
MR. BRADNER: My point is purely a parliamentarian one, if the authors choose to change their proposal and the authors choose to change their proposals anything else is input to the AC.
MR. CURRAN: Correct, but I am going to ask for a show of hands and if the result of that show of hands supports that, given the author's consent, I will change the proposal as advanced to the AC.
MR. BRADNER: Parliamentarian nit, the authors can change it, you can't.
MR. CURRAN: Right. That is what I said. (Laughter)
MR. CURRAN: I am obtaining the permission of the authors to change it based on the straw poll. Do I have your permission Owen? Do I have your permission?
MR. DeLONG: Yes.
MR. CURRAN: Thank you. Okay we are now going to do a show of hands for purposes of changing the policy proposal. Line 2C reads "At any other time, without cause unless a prior review has been completed in the preceding 12 months," the amendment is changed there to read, "At any other time, without cause unless a prior review has been completed in the preceding 24 months." I am going to ask for a show of hands. All those in favor of amending it we will be making an amendment to change that to be completed in the proceeding 24 months. All those for amending the proposal to read completed in the proceeding 24 months, raise your hand. Nice and high. Okay, all those opposed to amending the policy proposal 2007/14, raise your hand. Okay, thank you. The count will come to me. Okay, on the matter of amending 2007/14 to amend 2C to 24 months, 153 people in the room in favor 27, against 13. With the permissions of the author I amend the proposal to read 24. Do I have your permission? Okay, so note the policy proposal on the floor is 2007/14 as amended article 2C reads "At any other time, without cause unless a prior review has been completed in the preceding 24 months." People who wish to wish to speak for or against this proposal take the microphones. People who wish to speak for or against this proposal take the microphones. Yes.
MR. LEIBRAND: Quick question. Does the review ordinarily conducted in the course of obtaining new IP space count as a review under this proposal or would that not count.
MR. CURRAN: Good question. Staff interpretation. Does the review that occurs in the course of normal business for getting new assignments, for example, would that count as a review under this proposal?
MS. NOBILE: Yes, it would.
MR. CURRAN: There is your clarification. People who wish to speak in favor or against this proposal? Yeah. Go ahead.
MR. HUGHES: Aaron Hughes Cariden. I think that interpretation just justified why it should have stayed at 12 instead of move to 24.
MR. CURRAN: Okay. Interesting, based on that you are thinking people might have a different view on the matter?
MR. HUGHES: Yes.
MR. CURRAN: I am you going to ask the authors. Do you have a different view on the matter?
MR. SPRUNK: I thought that point was clear because that was the intent of the wording in 2A.
MR. CURRAN: Right.
MR. SPRUNK: So I don't see that the vote would change it substantially based on that.
MR. CURRAN: I was going to say, certainly the proposals under the controls of the authors and I think it came up, I don't the form earlier, but you are saying, you might change your vote. Okay, if people feel strongly that it needs to go back to 12 you need to go find a microphone. Okay, with the proposal as amended, with 24 anyone who wishes to speak in favor or against the proposal as amended find a microphone. Okay, any further discussion? Okay, thank you for your presentations. (Applause)
MR. CURRAN: Okay, we are now to discuss the amended policy proposal 2007/14, now is the time when we seek input to give to the AC in their consideration of this amended policy proposal. I am going to ask for everyone in favor of it and then I am going to ask everyone opposed. Everyone in favor of policy proposal 2007/14 as amended, please raise your hand. Nice and high. Nice and high, if you are voting. Thank you. Everyone opposed to 2007/14 as amended, please raise your hand. Nice and high, nice straight hands make for quicker counts between us and lunch. Okay, thank you. We have a count coming to the front. Okay, on the matter of 2007/14 as amended, 153 people in the room, in favor 41, against 12. Thank you very much, this will be provided to the AC for their consideration.
MR. PLZAK: Okay, what we are going to do now and in the remainder of time before lunch is do an open microphone session. We didn't get a chance to do one yesterday and so we are going to try and work one in right now. So please remember that courtesies and rules of discussion as outlined by the chair earlier. If you are not or can't remember them please refer to those in your meeting folder. I will turn it over to the chair, remember this is not a place to discuss policies that have -- proposals that have been discussed or will be discussed, nor is it to discuss things that are to be placed before the members in the members' meeting on Friday. John.
MR. CURRAN: Okay. The floor is open. Open microphone session. I am going to remind people right after this is lunch. Take as long as you want. Front microphone.
MR. WEILER: Thank you for scheduling this today. Sorry for keeping you from lunch. Sam Weiler, Sparta. I have some concerns about the current policy process.
MR. CURRAN: Okay.
MR. WEILER: I think that it is not sufficiently efficient or responsive. And I think, yesterday, when we were talking about the end of life or before, we were hearing things like, we expect to get a global policy in place by 2009, just barely in time. We were also hearing that as we get down to end of life before or the registry is maybe getting -- assignments from ARIN they will only last them for three months or so. I think there is a particular impediment in the policy process that we could remove that would improve this, which is the hard requirement that every policy and every major change -- or every substantive change to a policy come through the physical meeting. I would like to see ARIN -- the policy process changed to give the AC discretion to act on policies and on substantive changes to policies without bringing them through the physical meeting.
MR. CURRAN: Okay. People who wish to speak on this matter remain at a microphone, otherwise please step back a few feet to allow those who do to speak on the matter of changing the policy process. Okay, I recognize Aaron -- no, yeah, go ahead, you want to speak on this, right?
MR. HUGHES: Sure, I am Hughes, Cariden. I would say that the policy process as finally it is - regards to the fact that it is slow at least it is not like IETF for example. Policies with consensus do take time, we do know about these things in advance, and the fact that we don't bring policies up in a timely matter to predict what is going to happen or in preparation for what is already going to happen is our own problem.
MR. CURRAN: Okay, good policies take time, got it. Rear microphone.
MR. HOWARD: Lee Howard, Stanley Associates and ARIN Board of Trustees. Certainly, I think that we are open to modification to the policy proposal evaluation process. But in this particular case I believe that we do need the mechanism of a face-to-face meeting because more people speak up, we get more interaction, there is a chance to have a better interaction of ideas here, and we have already heard an example of one person changing their opinion based on the information and arguments made here on the floor. So I think this part is necessary.
MR. CURRAN: Okay, I am going to take other comments, far microphone.
MR. DARTE: AC I -- not normally averse to assuming more power, but in this instance, I would prefer to see the process open and debated. I could see if it were non-substantive changes, if they were just edits to the NRPM that in our view did not impact the spirit or implementation of a policy that wouldn't bother me any.
MR. CURRAN: Okay more comments on this rear microphone?
MR. NARTEN: Thomas Narten, from IBM. I am sympathetic, I think that there are issues with the way the process works and some efficiencies ought to be explored. But I think it has to be done carefully, obviously, you know, because the other side of the coin is having policies go through that aren't actually well thought out and aren't well supported and that is the other danger. But, yeah.
MR. CURRAN: You support looking at this to see what can be done.
MR. NARTEN: Yes, but we but we need to look at specific changes and think about them carefully.
MR. CURRAN: Okay, far microphone.
MR. LEWIS: Ed Lewis, NeuStar, I think it is important to have the policies go through a public meeting like this, to give an alternate form besides e-mail if you don't want your e-mail contact. And I also think that speeding up the process is not necessarily a good thing to do, a good goal.
MR. CURRAN: Nope. Understood. So everyone who wants to speak on this who have spoken wants -- has everyone -- Scott?
MR. BRADNER: I heard about this the other night and my response was that I was worried about the level of participation on the mailing list. Now, we historically don't have very much participation in the mailing list and we are having discussing discussion in a face-to-face meeting forces some level of attention though not a great deal since e-mail is so attractive. But at least some -- at least during the room when the discussion is happening. And I would worry that we are not getting enough visibility if we don't -- in the face-to-face meeting, but that said like Lee said, there is nothing inviolate about the current process that we should look at it and the comment made that it is not like the idea. Well, actually it was modeled on the idea.
MR. CURRAN: From the -- Woodcock?
MR. WOODCOCK: Yes, I think my feelings on this are very similar to Scott's and Lee's and also Bill Darte's in that I think that one of our principal issues that we always struggle with is degree of participation and there is far better participation in the meetings than there is on the mailing lists. And even in the meetings that is not very good representation of the membership overall. So I think, if on contentious issues, we were to try and decide anything on the mailing list, we would fail. On the other hand, as Bill said, there are little things that often are, you know, simple little issues, the wording that staff has run into that probably don't need to take time at the meeting. But on the other hand when they are brought up at the meeting they are typically handled in just a few minutes anyway.
MR. CURRAN: Okay, I would like to get everyone who hasn't spoken on this matter. Far microphone.
MR. POUNCETT: Matt Pounsett, ARIN Advisory Council, I think it is really important that we have all of our proposals make it through the face-to-face meeting as well as the mailing list. We've had cases in the past where proposals, if the Advisory Council could act on proposals before the face-to-face meeting, we've had proposals that would have been killed early or put through early where we've had a completely different reaction from the community at the face-to-face meeting that has changed. What the outcome for that proposal would have been. And so I don't see it being very prudent to do that except in cases, where as Bill said, we are talking about, you know, very minor changes to the structure and things like that, that don't affect the actual spirit of the policy.
MR. CURRAN: Got it. Everyone who hasn't spoken on this matter go ahead.
MS. ARONSON: Cathy Aronson, ARIN Advisory Council. I wanted to follow on with what Matt just said, we have been having an internal debate within the AC when a policy proposal comes forward to the mailing list and gets really vehement negative publicity, and people are really against it. But whether we should still bring it forward to the next meeting or whether it should get killed before it gets a face-to-face discussion and we have had quite a few lively discussions about that, and I actually kind of wanted to just see what people thought about that. Because it seems like sometimes we get a really different impression in the meeting than we did on the mailing list, but sometimes we don't and, you know, we just go kind of back and forth about it. So.
MR. CURRAN: Okay. So right now on the particular matter of whether or not policy proposals should be acted on without going before the members, are you for or against that?
MR. BRADNER: John. Correction this is not going before the members it is going before the community.
MR. CURRAN: Going before the community, thank you, Scott? Yeah, let us hear further on that.
MR. WEILER: And further corrections not it should it is allowing the AC discretion.
MR. CURRAN: Thank you. On the matter of allowing the AC discretion to move with the policy proposals without it going before the community in a public meeting, if you think that is a good idea or a bad idea.
MS. ARONSON: I would say -- I usually err on the side of bringing it to the meeting because I feel like especially if it something that I personally feel needs the community to discuss whether or not, you know, I agree with the people on the mailing list. You know, maybe the policy isn't the thing that I would prefer to have go forward but I feel the discussion should happen and I am usually in favor of it.
MR. CURRAN: I would like to get everyone's first comments on this matter. If you have not spoken on this matter remain at a microphone otherwise step back. Yes.
MR. BICKNELL: Leo Bicknell, ARIN AC. I have slightly different spin on it because in general I echo Bill's comments about not really wanting more power as an ARIN AC member so that seems dangerous. But my comment differently is there are situations anticipated by our bylaws and rules such that the board could potentially make emergency policy without a meeting should that be necessary. And some of us believe that may occur in the near future. And I wonder if it wouldn't be nice to make the rules such that the AC had a more affirmative role in that process to represent the community. So that would be a path, where a policy possibly could be passed going through the AC not at a meeting but under the guise of an emergency need. And whether that would be the board simply consulting with the AC or whether it is a formal process, I don't know. But I think that maybe the one case where I would consider that an appropriate response.
MR. CURRAN: So on the general topic of allowing the AC the flexibility to move ahead with the proposal without it going before the community at a public meeting you would say yes or no, on the general topic.
MR. BICKNELL: Probably, no.
MR. CURRAN: No. But you think that there is some possibility of looking at that with respect to emergency actions that would benefit us.
MR. BICKNELL: Absolutely.
MR. CURRAN: Okay. Thank you. Any one who has initial comments on this matter who hasn't spoken. Rear microphone.
MR. VEST: Thanks. I think, I actually -- so the question hinges on the independent value -- Tom Vest consultant to RIPE NCC. It seems to hinge on a kind of empirical question, the independent value of the meetings as a mechanism for fostering consensus, providing education and everything else. And that seems to me to be measurable. It's possible to observe through the mailing list who is contributing. It is possible to observe who is actively contributing comments and things like in the list. Now, the receptiveness or the attentiveness, I think, perhaps the organization currently tries to capture some of that through surveys at the meeting. Perhaps there should some kind of semi-regular surveys on the mailing list as well, just to gauge the level of attentiveness. And if you find that the level in the specific set of people who are being both actively contributive and actively attentive in both domains is roughly the same. That seems like that would provide some basis for providing greater flexibility for pursuing the advancing policies.
MR. CURRAN: Okay. On the particular matter of allowing the AC the flexibility to move ahead with a proposal without bringing it before the public -- the community in a public policy meeting, how do you feel, is that good?
MR. VEST: My feeling is if some actual investigation of that question revealed that there was not a lot of difference between the identity and the levels of both active contribution and active attentiveness, if there was very little difference between that, between the meetings and the mailing list, I would support that proposals.
MR. CURRAN: But right now, without that information, you couldn't support the proposals.
MR. VEST: I would support investigating that question.
MR. CURRAN: Right, got it.
MR. VEST: Thanks.
MR. CURRAN: Okay, far microphone.
MR. DICKSON: I think there may -- Brian Dickson with Afilias. I think there may be a question of scope that there is longer lead time involved where there are policies that are across RIR boundaries.
MR. CURRAN: Yeah --
MR. DICKSON: And as such, those particular policy issues, I think, definitely need to have some ability to move forward, although I would be in favor of any policies that require cooperation between RIRs -- move forward initially between RIRs and then get ratified by the RIR communities.
MR. CURRAN: So on the topic of allowing the AC the flexibility to move ahead without bringing a proposal before the community in a public meeting, you would be for that but only in the case of it being those that require cooperation among RIRs.
MR. DICKSON: In fact, I would be in favor of a period.
MR. CURRAN: You'd be in favor of a period, but particularly in the case where cooperation among RIRs is required.
MR. DICKSON: Yes.
MR. CURRAN: Okay. Everyone who hasn't spoken on the matter, Scott, do you have a point of enquiry or order? Go ahead, Scott Bradner.
MR. BRADNER: Hello, a point of information. Yes, it is correct that the board can act in the case of emergency, but it is not a standalone action. It goes back to the community at the next public policy meeting, and AC is involved in all that kind of stuff. So it's not working ex cathedra and then running away.
MR. CURRAN: Okay, people who have not spoken on this matter yet, approach a microphone. If you have spoken, step back from the mic, on this topic. Now, you had a point of information, Woody?
MR. WOODCOCK: So, this is to fight with Leo. Right now, there are two reasons why the board can send something back that's received from the AC. One is fiscal, right, if it's fiscally irresponsible. The other is if the board believes that the process has not been followed, the public policy process. So if this change were made, it would allow the AC to send things to the board, which the board would have no way of sending back if the board believed that the AC was doing something that was unrepresentative of the community. So that is something that you guys might want to think about, whether there is a third reason. If this were done, whether that would be grounds for a third reason for the board to send something back to the AC. That is, process was followed but community input was not sufficiently considered.
MR. CURRAN: Okay, you've spoken on the topic, but you're at the microphone, so you have a point of information or query?
MR. DICKSON: Point of query. Could we get a show of hands in this room, members of the mailing list. People (off mike) mailing list. Just for --
MR. CURRAN: You're asking -- there's about seven of them, can I ask which one?
MR. DICKSON: PPML.
MR. CURRAN: PPML; people in the room who are participant on the PPML mailing list, raise your hand. Again, if you're in the PPML mailing list and you're in the room, raise your hand. If you are on the PPML mailing list, and you're in the room, please raise your hands. We're going to take names of those people who don't and verify this. Please raise your hand if you are on the PPML mailing list. Thank you, does that help your point of inquiry?
MR. DICKSON: Definitely.
MR. CURRAN: Sure. Has everyone spoken once on the matter, anyone who has initial comments on this matter. Okay, you're response, and anyone who'd like to speak a second time on the matter.
MR. WEILER: I certainly appreciate the comment that this poses the danger that we will act something that we shouldn't have, that does not reflect the community's consensus. However, one of the charms of the proposal of generally speeding things up is that let's just fix it. If we think that the AC made a mistake, we can come back to the next policy meeting and hopefully even -- or before, and say, how about doing something different? Okay. And generally, that's the result of speeding things up.
MR. CURRAN: Anyone who'd like to speak a first or second time on this topic? Yes, Tom Narten.
MR. NARTEN: Thomas Narten again. So all this -- I think this is important discussion to have. But I think the phrasing of the question of would you be in favor or opposed to having a policy go through without a public meeting is kind of the wrong question to ask. Because I think, I would have a lot of difficulty with -- and a proposal never having been discussed at a public meeting going through. I think the bigger issue is where we have a discussion, the document gets sent back as it needs revision, an hour back, when another six months before any action takes place.
MR. CURRAN: Let me ask the context. You made the proposal. You're thinking about cases where the topic has been discussed and the AC is necessary to work the proposal. It's not a straw man from scratch you're thinking of, is that correct?
MR. NARTEN: Well, there is a substantive change in response to the discussion during the meeting, which is pretty common.
MR. CURRAN: Response -- specifically, what are you -- when you suggest that giving the AC the flexibility, what are you thinking about, what context or proposals.
MR. NARTEN: I'm thinking about both of those.
MR. CURRAN: You're thinking about both. So specifically the proposal is about both.
MR. NARTEN: However I think it is also -- if the community is not supportive of that change, I do separately think it's useful to allow substantive changes after one public policy meeting.
MR. CURRAN: Okay. That answers your question.
MR. NARTEN: So -- you don't have to cycle through the six month cycle again and again and again.
MR. CURRAN: So, as suggested, it's fairly wide open. You're noting you may support this in the case of being proposals that have been once before the community.
MR. NARTEN: Yeah, I think that's what's more important and more useful.
MR. CURRAN: Okay, people who'd like to speak on this topic, get on the microphone, Geoff Huston.
MR. HUSTON: Geoff Huston, APNIC, I'm neither for or against this policy by virtue of my employment. However, being a regional body, rather than even a national body, recognizing that the ability to attend meetings is not necessarily a universally shared ability. Recognizing -- you really need to involve folk from across your entire region than working hard on things like mailing lists and similar. For that kind of participation is perhaps of more lasting value to your broad constituency rather than focusing on those smaller set of folk who are able to participate by virtue of being able to come to a meeting or being in just the right times and at just the right time. So there's certainly some virtue in considering more than the folk in this room when you try and look at this problem, as we have done in other regions in other regional internet registries.
MR. CURRAN: Right, our present process encourages mailing list participation, and I guess, while you're neither for nor against, you're noting that not relying on this meeting as much may not be a bad idea.
MR. HUSTON: That's correct.
MR. CURRAN: I'm actually going to close the open mikes for purposes of other topics. I see -- raise your hand if you want to introduce a new topic at the open mic. You are the only two new topics that will be -- you are the only three, yes, new topics that will be introduced, because we are actually well past time. I'm also going to close discussion on this topic of allowing the AC flexibility to move a policy proposal without bringing it before the community in a public meeting. So I see three respondents at the mics, go ahead.
MS. SCHILLER: So, the reason -- I'm sorry, Jason Schiller, UUNET/Verizon business. There was one concern about the length of the policy cycle. And I just wanted to suggest that maybe it would be nice if we could reorganize the meeting so that there was enough time for the AC and the author to respond to some of the concerns that came up in the meeting, and quickly revise the policy and put it to another straw poll at the very end of the meeting.
MR. CURRAN: Interesting thought, that's very interesting. Over here.
MR. POUNSETT: Matt Pounsett, Advisory Council. I just wanted to respond to the comment about clawing things back. That when the Advisory Council votes and puts things forward to the board, there are safeguards there to make sure that the Advisory Council hasn't done something bad; things like, you know, petition processes and the board being able to refuse to implement policy. I would posit that if there's no outcry on the mailing list during last call, then it's not -- the AC didn't screw up, the community did. And therefore, we're in -- and then if there is something that needs to be clawed back after that, we're talking about something that's really seriously affecting the community, and there's already president for the board having pulled back that sort of policy.
MR. CURRAN: So in light of the opportunity of last call, you'd be for the suggestion that is being made, because of the protection afforded by last call.
MR. POUNSETT: Yes.
MR. CURRAN: Okay, thank you. Yes.
MR. NARTEN: Thomas Narten again. One last, sort of, observation. It was -- the comment was made earlier that we have a problem on the mailing list of not necessarily getting adequate participation, and I fully understand the challenges of e-mails, lists, and so forth. But one observation is we may be in this kind of a cycle where people know in fact that the real action happens at the face to face meetings, and it makes it -- makes them less inclined to participate on the public mailing list, because you know, obviously, it's not as effective as being at the meeting.
MR. CURRAN: Okay. Bill, the microphones are closed on this topic, and we already have a list of people for new topics. So I'm going to ask why you're at the microphone.
MR. DICKSON: Because I'm feel compelled to respond to Geoff's statement.
MR. CURRAN: Briefly.
MR. DICKSON: I will. The ARIN Advisory Council, looks not just to this meeting, but to the public policy mailing list. And in addition, all of our e-mails are posted on the website, and we actively solicit people's input any time through that mechanism, and we talk to people in the halls and byways all the time, any way.
MR. CURRAN: The point of privilege, representing the AC is recognized, thank you. We're done with this topic. I want to say thank you for raising it. There is a suggestion and consultation process which would be a great place to put this, to make sure that it gets covered and actually gets formally addressed. We now have -- open microphone is only for the three individuals we've recognized and responses to them, in order. Yes.
MR. LEWIS: Okay, I believe the ACSP is open to the public.
MR. CURRAN: Yes.
MR. LEWIS: I just want to put a plug in for consultation ongoing now about lame delegations. I was told there wasn't much activity there. Just want to make you all know that this is open right now through next week.
MR. CURRAN: Thank you. Please note that there is currently a suggestion out there and it needs to have your input. Okay, center microphone, rear.
MR. DIVINS: David Divins, ServerVault. I just wanted to express support for something that was brought up at the Cyber Café's suggestion card about potentially moving away from mailing lists towards a more of e- bulletin type of format, where you can actually do straw polls, and maybe a little bit more modernized format that might be a little more organized and maybe encourage some more participation. Because I think a lot of people see PPML and it's the same eight, nine, ten people responding, and maybe a more organized web forum or something would promote more participation and you can get a better consensus then. Well, we got e-mails that said I was in support of this. You can actually run polls and things like that, just -- you know, it's not 1992, so --
MR. CURRAN: Okay, responses on the suggestion to move towards a more deliberate in-person, I would guess, situation. Yes, Aaron.
MR. HUGHES: Very quickly, I would support something like that as long as the announcements for voting, reviewing, or straw polls was on a separate list, like ARIN does announce that you don't have to weed through PPML noise.
MR. CURRAN: Right.
MR. HUGHES: Proc Mail is appropriate and we've reviewed before meetings but we don't have the time to keep up with it every day.
MR. CURRAN: Understood. Okay, any other on that topic? Closing that topic. Final topic for the open microphone. In the rear, thank you.
MR. SHEARMAN: Gareth Shearman, Telecommunications Canada. We are not for profit. We are a national association of community networks in Canada. Some of these networks began in the early '90s as phoenix. Some have been established more recently to provide wireless services to remote communities. The U.S. Equivalent of our organization is the AFCN, who unfortunately could not be here for this meeting. Some of our members have legacy address space. It has occurred to me that getting each of these organizations to regularize their allocations and move to IPv6 will be difficult. I have an idea that might help. I have been told by people at this meeting that current policy prevents this but that it is worth discussing, which is why I'm bringing it forward. Why not have TC, for example, apply for a block of IPv6 addresses assign portions to our members. As part of this process, we would also regularize our members' existing v4 legacy space. I'm informed that current policy prevents this because we're not in the business of routing addresses to our members. We would very much like to have a customer owned network of light paths or whatever, that would allow us to interconnect with each other, if that is -- isn't the current situation. Is there merit in this suggestion and if so, how should the issue be addressed? Thank you.
MR. CURRAN: Okay, so as I understand the suggestion, the suggestion is for a policy which would allow community based internet resource allocation as opposed to network-based.
MR. SHEARMAN: Yes.
MR. CURRAN: Okay, comments on this. I'm going to say we want to keep it brief, because we are well past our time, anyone who wants to speak on this, find a microphone. And I have one there, and then RS. Go ahead.
MR. DICKSON: My comment would be from a technical perspective this is a bad idea. However, I'm in favor of the ability to group together non-profit entities as a organization for the purposes of allocating multiple numbers.
MR. CURRAN: Okay, good to hear. Anyone who wants to speak on this, RS.
MR. SILVA: Yeah, what Brian said, I'm more or less in agreement with that, that having an organization that -- trade organization that represents the ISPs in question is perhaps more familiar with the requirements for getting addresses is a good thing. But assigning blocks from which there are then sub-delegations made to organizations that are not connected together by a single backbone is bad for aggregation in the core.
MR. CURRAN: Okay, approach the microphones if you wish to speak on this, I'm closing the mics shortly. Bill.
MR. MANNING: I'm actually in favor of this idea as a concept. We have used it historically. We seem to have lost that in a lot of the current policies, and does support these folks' use of IP in their communications. And so I would love to have a continued discussion about how this would work in today's environment.
MR. CURRAN: Microphones are closed, I recognize back-rear microphone.
MR. DUL: Andrew Dul, Perkins Coie, I think this is a good idea that needs further discussion.
MR. CURRAN: Okay, Bill.
MR. WOODCOCK: As a practical matter, you should look at policy 4.3.5, disconnected networks, which will probably get you what you want if you're not trying to make a point of it. If this is a policy matter, what you're talking about is interposing a separate organization between ARIN and the ultimate members that's like an NIR or an LIR or something, and that has caused a lot of problems in other regions in the past. And this region has been very skeptical of that in the past, with a lot of discussion.
MR. CURRAN: Okay, rear microphone.
MS. SCHILLER: Jason Schiller, UUNET/Verizon Business. It's not clear to me whether the network you described is going to be a standalone island or part of the global internet. But if it is going to be part of the global internet, it's important to understand that you can either have addressing follow topology, or you can have topology following addressing, or you can just deaggregate everything and our routers would fall-over. So there's technical implications here. Right now, we don't have routers that could support /128s throughout the entire routing space, so we do need to aggregate. And unfortunately, the way that we're doing this today is by having providers provide transit to their customers and aggregate their numbers, which is making the addressing following the topology.
MR. CURRAN: Are you also at the microphone to speak on this matter?
MS. DAILEY: My name is Dharma Dailey, I'm from the Ethos Group, and I'm not representing the association for community networks in the U.S., and I'm not representing Acorn Active Media either, which has put forth an application to do something I guess, like what you're saying is problematic and we understand that that community network and community understands that this is a technical challenge as well as a policy challenge. And we would appreciate it if there's people here that want to continue those discussions and please help us, because we do have -- we do have, within, you know, the U.S. and Canada, two organizations that are interested in perhaps doing a consortium or something like that. And anyone that's interested in helping us figure out what's appropriate for these kind of networks would be greatly appreciated, thanks.
MR. CURRAN: I was going to ask, anyone who wish to follow up on this?
MR. BRADNER: I've got my hand up here.
MR. CURRAN: Yes.
MR. BRADNER: This is a -- this is not a new request. I've heard this a number of times over the years. Whether it's a organization which is getting a block of addresses or splitting it out to members or whether it's an organization that's facilitating discussions and facilitating getting assignments, there's nuances to it. I think it's a important concept that individual small community networks on their own are unlikely to be able to navigate and something needs to be done. I don't know what it is, but I would like to continue the discussion.
MR. CURRAN: All right. Folks who are interested in this should seek the speakers to continue with the discussion and see is there's a way to introduce this into the process. That ends our open microphone session for today, thank you everyone. I'll turn this back over to Ray to send us our charts to lunch.
MR. PLZAK: Okay, remember, take your valuables with you. The general session room is not locked. Help desks are open. By the way, if you leave now, you won't know when you're supposed to come back. Raffles, drawings, sponsors -- (Applause)
MR. PLZAK: You -- okay, the public policy meeting will not resume at 1:30 as it says on the magic little clock, sorry, Erica, it will resume one hour from now, which would be 1:45. See you at 1:45 properly. We still have got a lot to cover. We've done a lot this morning, and I thank you very much for your tetherness. (Whereupon, at 12:46 p.m., a luncheon recess was taken.)
RIPE NCC Update
MR. PLZAK: Okay. Everyone please come in. We have a sparse audience. All right, good afternoon. Welcome back from lunch. And the first item on the agenda after lunch is the RIR report from the RIPE NCC. Axel, would you please come up?
MR. PAWLIK: Good afternoon. Thanks to those of you who did come back from lunch or coming back from lunch. A quick update from the RIPE NCC. No, this is not my car and I didn't take the photo either. I'm not that old. However, that is the canal in front of my office and bad things can happen. And since bad things can happen, we thought we better be prepared as an organization to take care of that, of course, all in the interest of our members of the greater community. So quite some years ago we set up an emergency plan as every self-respecting organization has. Now, these are the emergency exits and you are supposed to not run down the stairs and all that. And that is implemented in quite well. However, we thought we might do some more things. After all, there might be an earthquake in Amsterdam. But that's unlikely, maybe more like flooding. And the house might be lost and then what to do. So we developed a business continuation plan basically with the idea to get back up. And do come in, folks, do come in. You shouldn't have had that much dessert. Come on in. Sit down. All right. We did draw up this continuation plan ourselves. We tossed it to some consultants to make sure that we didn't overlook something that now everybody should know. And we did have a workshop in terms of what would we do if we do this for real in September. That was quite fun. Basically, a disastrous day at the RIPE NCC. We all survived and we brought up our services really quickly. As I said, this is seen as a member benefit and this shouldn't be the end. We are looking forward to having some more cooperation among the RIRs on this topic. I mean basically we are very nicely situated on very different continents. And in case of flooding in Amsterdam, I'm quite sure that there will be no flooding in Brisbane any time soon. So we are looking forward to doing that. You might have heard earlier that we have done quite some exciting changes at the RIPE NCC in terms of organization or reorganization and shifting people and text around a bit. We have quite a number of new key staff looking after some of our departments. Two of them, I've brought here for the first time. That's Andrew and Greg and they are -- maybe you can show yourselves quickly. Andrew, Greg is having dessert or is hiding behind the tree somewhere. All right. They tell me they are quite impressed with the way the ARIN meetings are run. So we'll probably copy some of your things again. Now, having done some (off mike) gazing over the last year or so basically, we are looking outwards again and towards our members and looking at services that we should be improving and bring up new services as well. And there's quite a number of them on the slide. We are facing interesting times, as you know. And we thought it might be a very good idea if the management of RIPE NCC would think about this a little bit longer. We did quite some retreats basically to look at options for the RIPE NCC, how do we want to position ourselves, what should be our positions on things like IPv4 exhaustion and the like. We did look at that. We also thought it might be quite helpful to be on the same -- basically, lined up with our executive board nicely. We put those five people in and did a workshop on, basically, vision, what do we think the RIPE NCC is and what services we should be doing, of course, focus on the exhaustion of IPv4 coming up sooner or later. We have been asked several times why -- in the light of other RIRs' boards stating their opinion, why doesn't the RIPE NCC does the same thing or the RIPE NCC board. And we said our board doesn't have a position at all in or a function at all in the policy development process. And we don't feel we should be doing this. We are trusting this to the community. And next week we have to get some discussion on this and get some community statement out of the RIPE meeting. All right, ongoing process. What we see the RIPE NCC as being is a network coordination center that also does tasks that we see these days as regional Internet registries. But there are more things and that's also important that we do these -- the community likes that and that's what we are doing. Some examples on this slide again. We also think that we have to prepare ourselves for the transfer of numbering resources as you've discussed that yesterday. We see it as essential that we are positioning ourselves that we are ready to deal with it once it becomes active. Certification in the RIPE region. As you know, the RIPE NCC's activity are plan-driven. Basically, everything that we do has been approved by our members. Before we start major new activities like certification, we felt it is necessary to have some community involvement there. We set up a task force, member task force to guide us and look at our activities there as they are unfolding. We have at -- quite a number of meeting there. We have reports, have had reports, and will continue to have reports at the RIPE meetings. And we hope we'll deploy something there in 2008. Of course, only if that is supported by the members. However, today, I don't have any real doubt that there will be support for this. In terms of regional outreach and membership outreach, we currently have 5,200 and a few members. And we see incredible sustained growth in Russia. And well, that's great. So seeing that Russia is growing very, very quickly, we continue to go there. We've been in Moscow again earlier this month. It was a great meeting with 160 people, I think, roughly there. We don't know their language. They have some difficulties with our language. But we love each other and we have, of course, also interpreters there. So that's a very good activity. Also, we'll be going again to the Middle East region for similar reasons. There is a distinct community there. We don't see many of them coming to regular RIPE meetings. So at least we have to update them on the developments. Membership survey. We'll do one probably early next year. We are currently preparing and thinking about this, how to improve this. MENOG 1, having gone to Dubai for a RIPE NCC regional meeting, for the first time, people asked us to set up a regional operators group. And we said, "No, that's yours to do really." And they've done so. And we've seen MENOG 1 happening earlier this year in Bahrain. MENOG 2 will be happening also later this year, next month actually in Qatar. And that will be adjacent to the next regional meeting of the RIPE NCC in the region. Enhanced cooperation. We don't quite know what this means. We have currently set up a -- or we are setting up a task force within RIPE to define what this is and to guide us on our way on the path to a further, better enhanced cooperation. Basically, it's talking to governments and regulators. We have been doing quite a number of roundtables for these guys in Amsterdam. The latest one was in September, the second one this year, as this is a very interesting year in terms of IPv4 exhaustion. And everybody is very interested in that and in our opinion. So we explained ourselves. Good. Our external relations group has been stuffed up a bit. We want to further develop the roundtable format, and also go out and basically ramp up our activities in the area there. Of course, we are all looking forward to going to Rios. The last RIPE meeting in Tallin was quite well attended. Some of you had been there. The network was DDOSed we know -- all know that. Old news by now. It was workable though. We and all our members adopted our financial report for the last year and the annual report. And we had some board elections. Nothing changed in the composition of our board. Nigel and Janos were both reelected. We felt, looking at how the meeting went and what we wanted to discuss and didn't quite have the time, that we do need definitely more time for this policy discussions. So for this time, next week actually, we have planned the -- a topical session on IPv4 exhaustion on the Tuesday afternoon. And also we have two slots for the address policy working group also. One on the Wednesday afternoon that is basically a plenary meeting and one on the Thursday morning. And you notice there is ample opportunity to have some beers in the evening with us and discuss those things. And, yes, there were too many nightclubs in the hotel. The next RIPE meetings. Well, there's one next week and, of course, you are all invited to come. And it is totally possible for you to do this because we are doing this ourselves. I'm leaving here tomorrow, do my laundry over the weekend. And we'll be doing the RIPE meeting then. Then we will have one in May next year. We thought it would be Cologne. However, we hear that the hotel won't be quite refurbished at the time. So we are currently frantically looking for other places in Germany to go. And at the end of next year, finally, we do go with a full RIPE meeting to the Middle East, to Dubai. And well, we will see how many people come there from the local community and also from our more regular standard community. It'd be an interesting meeting certainly. And again you're welcome to attend all those meetings. If you have any questions, I'll dig up some answers. I'll try hard. Thank you.
MR. CURRAN: Thank you. (Applause)
MR. PLZAK: Axel, is it true that you're having a prize in the Dubai meeting that someone will get to play tennis with Roger Federer up on top of one of those buildings?
MR. PAWLIK: (Off mike)
2007-25: IPv6 Policy Housekeeping
MR. PLZAK: Okay. Policy proposal 2007-25, IPv6 policy housekeeping. Can -- do people here a feedback hum here? Can we -- audio guys, can you kind of take care of that please?
SPEAKER: Yeah, that's what we're doing down here.
MR. PLZAK: Okay. Oh, it's at my feet as we speak. All right, this policy was introduced on the PPML in August of this year and the AC-designated formal proposal in September. This is the first meeting it's discussed at. No revisions to this. ARIN staff understands this proposal would make the following changes to the IPv6 section of the NRPM, removes the prefix size from the initial IPv6 allocation criteria, moves a modified version of 6.5.3 to a new location, 18.104.22.168, establishes criteria for direct assignments larger than a /48, 0.94 HD ratio, and makes reserve space from the /44s available for other use. Shepherds are Lea and Stacy. Prior to formal posting, there were 14 posts by seven people with four in favor and one against. After formal designation, three posts by two people, one for, none against. Comment, as you see it. Counsel see no -- in October sees no legal liability. Staff in October. Change I. The statement be, a "known ISP" is still contained in this policy. This term is ambiguous and open to interpretation and should be defined. It should be noted that there is no authoritative definition for either ISP or LIR. Change J. The section number 6.5.3 would be retired instead of renumbering all the subsequent sections. NRPM change, modifications to sections as they're listed there. In terms of implementation, minimum. Staff says we can do it in 30 to 90 days afterwards. Really to -- have to update guidelines, staff training has to be done, and we would have to make some minor text changes to the template. And having said that, I would then ask the author, Leo Bicknell, to come up.
MR. BICKNELL: You're allowed a little collective sigh.
SPEAKER: Puerto Rico again?
MR. BICKNELL: It's not Albuquerque. (Laughter)
SPEAKER: Or Toronto in February.
MR. BICKNELL: So yeah. So we have this IPv6 policy housekeeping. And those of you who followed on PPML, this was originally posted as a much larger change than what we ended up with. And I wanted to take a very brief period of time to kind of discuss that. So the IPv6 policy is a disaster. And the deeper you look at it, the worse it is. The original thing posted 15 different changes. And as many people have pointed out, what was originally a global policy is now significantly different in all five of the RIRs for different reasons. So it's not interim anymore. It doesn't match anybody's format perfectly. It's been hacked up in many locations by a bunch of policy proposals. Another interesting thing that I saw happen on the list when I posted the first version is what I like to call the head in the sand. We posted a bunch of things on what would happen if you came back for more space. And the response was, "Well, that's going to be so far in the future; we don't need to worry about that." But you guys need to keep records and stuff. So when ARIN says 25 years from now when you come back for allocation number 2, "This is what we'd like to see," hopefully you have it and don't have to recreate 20 or years of records, right. Plus, of course, this is poised to explode. And so the reason I want to take this time to do a little rant and to say this up here is the AC board and staff really are looking at this. And we're all struggling with this generic problem. Like I said, I posted 15 individual changes here. Some of them are not being presented here because the AC and the board and other people feel they're not policy changes, feel they are simple editorial cleanup to the manual and should be handled separately. We need community feedback on these sorts of issues. How do you want us to handle it? Would you rather have 50 separate policy proposals, each of which changes "a" to "an" and "the" to "the" and all these other things or would you rather have one big policy proposal? Would you not like to see them at all in the policy process? We need your feedback on the right way to fix this. So with the little rant over, let's get to what's left in the policy. We have 2007-25 as it was submitted. And just to go to a little bit of the history again. Originally, it was 15 changes. We paired that down to items that we felt were actual policy changes. So that's what you see here. And also, I just want to tell you from a history of how we got here. There is a board member who I will not name who did an awful lot of the editing work and came to the AC and said, "This isn't something a board member should be proposing and the AC should review this before it goes somewhere." So that's kind of how it fell into my lap. And I applaud that board member and he owes me at least three or four or 50 beers now. But I just want to let you know that, you know, this is an area they stay awake at night thinking about. So we identified four things as potentially policy changes. And I want to emphasize here, the goal was not to change policy. In some of these cases, we think ARIN staff is already implementing things this way and so we're just writing it down. And in other cases, there are things that haven't occurred yet and there is no policy for. So there is just this great vagueness. And one thing I do want to point out from a keeping-track-of-things point of view, I retained all the original item numbers, which is why we have some weird lettering here, just so there would be no confusion with the original proposal that I put forth. So looking at these individually, we have Change I. And the problem here is very simple. We had a policy proposal passed and implemented, 2005-8. You can go find it in the archive. And among other things, it allowed /64s, /56s, and /48s to end-sites. This was the policy proposal several people wanted so that -- you know, 48s are wasteful, whether you believe that or not, and ISPs wanted to be able to allocate smaller things. That policy did say that several areas might need to be changed. This one seemed to be overlooked in that this section said that you had to get your first assignment, make 200 /48 assignments. And I believe the question has come up before. So now is that 200 /56s good enough? Do we really care about the 200 sites? Or if you're allocating /56s, do you have to allocate enough of them that you have 200 /48 equivalents? And we've kind of taken the assumption here that the important thing in this policy was that you have 200 sites. So what we actually do is remove the 48 here and change it to just be end-site assignments. So we don't care if you're making /56s or /64s. What we care about is that you're making 200 of them. Staff had some comments. Staff said they're concerned about the "existing, known ISP" phrase. Quite frankly, I am too, but it's there now. I couldn't figure out how to fix it in this policy. So I left it there. And you know, really -- there had been a couple of debates on that and no one seems to be able to agree on the language. We can agree on a couple of basics, but we just can't get it right. So it's a valid complaint from the staff. I don't know how to fix it at this juncture. Change J. This is the existing policy in 6.5.3. And I would submit that the first start of this isn't policy. It's just kind of idle rambling. And so the piece that's policy to me is this piece in yellow. I think that's kind of the important piece that comes out of this section. And what we chose to do as kind of the right way to fix this is to take that text verbatim as it exists, move it to section 22.214.171.124, which is a more appropriate place because 6.5.4 in general deals with assignments and this is an assignment thing, and just remove this 6.5.3 that's kind of half-knot policy and floating out there by itself. So just a editorial change, I think. Staff comments is they'd retire 6.5.3 rather than renumbering everything after it and I don't care. As long as it's gone, that's good by me, right. So if that's how you guys want to do it, sounds like a great plan. Change K, 126.96.36.199, initial assignment size. 6.5.8, in general, deals with IPv6 PI space. And the issue here -- two issues, the first is there's no criteria for an allocation bigger than a /48. So if you, for whatever reason, need to give somebody a /47, a 46, a /12, whatever it is you're giving out, there is absolutely no criteria anywhere in the manual that says what rules you must meet to do that. The second problem here is that we have this reservation space, which is much like, I believe, staff does today. I'm sure when they give out assignments to some ISPs, and I don't know what the rules are, that they assign an adjacent block so later you can grow into it. And that's a great thing. We really like that from aggregation. However, we also all know that there are ISPs who come and get space. And we may reserve oodles more space for them and then the next year they go bankrupt. And there is never going to be another request from them. And so in v4, there is just kind of this thing where we let staff do the right thing. And in v6, the policy seems to suggest that that /44 is reserved until the absolute end of time. So I have proposed two minor changes here. To address the first one, if you want to assign something bigger than a /48 to your downstream customer, let's use the 0.94 HD ratio, seems to be what we use everywhere else. At least then you and staff have a criteria to go by. And the second is to just add this language that the reservation may be assigned to other organizations later at ARIN's discretion. Give the staff the ability to go ahead and assign other pieces of that /44 somewhere down the road if they deem that's really the best use of it. Change L. We have a subsequent assignment size policy and this is in the provider-independent addressing space, PI space, again for v6. And the situation here is kind of similar. You go as a PI user and get your very first v6 block and you use it up, whether that takes you three months to use it up or 35 years, you know, depending on what you believe. And so you come back for your second one. Well, there's no criteria as to when you would ever get a second one. It just says it must be justified. I'd love to know what that means. So again, very simple modification here. HD ratio seems to be what we want to use everywhere else and 0.94 seems to be the number. So that seemed like an appropriate way to address the problem. If you're a PI holder and you actually use an HD ratio of 0.94 of your block, you can come back and get more. So that's the four changes. I just wanted to say from a PPML perspective, I kind of counted one for and one against the pervious, a little different total than the staff got. And two for and zero against in the revised one. As an AC member, we want your feedback. Please stand up at the mic or say something. Please post to PPML if you don't want to stand up and speak in public. We need to know what you want us to do. That's it.
MR. CURRAN: Okay. Microphones are open. Cathy, back microphone.
MS. ARONSON: Hi, Cathy Aronson again. I'm in favor of the proposal. And I just wanted to say, having been one of the first people to get a block of the cable /8 where the assumption was that once you got a /14, you're never really going to go back and get more address space. And then, you know, six months later, there was no policy for us to get more address space. I think it's a fine thing to have a policy because we're sparsely allocating based on the fact that people will come back and get more blocks. And you know, it may not happen in our lifetime, but then it might. So we should be ready.
MR. CURRAN: Okay. Far microphone.
MR. DICKSON: It depends on whether other people have short comments or long. I've got a long comment. So I'll let somebody else go.
MR. CURRAN: Everyone's allowed to speak once. Try to keep it to three minutes. Go.
MR. DICKSON. Okay. For the section I, 200, I'm opposed to specific number, 200. I think that there easily could be situations where the number could be very small but still qualify as an ISP. I think that the known ISP situation could be better defined by simply saying, currently recipient of a PA block.
MR. BICKNELL: I will agree with you that there are additional shortcomings in all four of these policies. The only thing I am attempting to do here is remove things that are actively conflicting in the manual or ambiguous in the manual. And I say that and I think it's important because if we really want to change any of these four sections, they need to be standalone proposals. Otherwise, we're going to get mired down in the debate. So all I attempted to do here was remove where the policy manual was self-conflicting or completely ambiguous so you couldn't tell what it meant.
MR. CURRAN: Right. To that end, if you want to make a change to the policy intent itself, then I'd recommend writing a policy proposal that says, "I don't think this is the way to say it with 200. This is how it should be done." This is envisioned to be a -- not a change of the current policy other than clarifications.
MR. DICKSON: Okay. Then in that case, I would have to say that as much as 0.94 HD ratio might appear to be a non-policy change. I think it's a substantial policy change. I'm in favor of not requiring any specific usage within a PA or PI block. I do believe that there are some other areas of the NRPM where the recommendations of end user assignments of /64, or 56, or 48 may be inappropriate for the longevity of IPv6. And most of these changes appear to be only valid in consistency -- in being consistent with that particular set of recommendations. If we abandon that set of recommendations and say anything that you want to assign needs to be SWIPed and we don't recommend very large allocations, then the 0.94 requirement probably becomes moot if not actually a bad thing to put in the policy.
MR. CURRAN: Okay, a point of information. Leslie, with respect to policy 2007-25, policy housekeeping, it has been pointed out that there is the addition of the HD ratio in section 188.8.131.52 and 184.108.40.206. Do the addition of these HD ratios affect the implementation of policy today? By adding these statements will how current policy assignments are being done be changed?
MS. NOBILE: Yes, it would. Currently there is no criteria and we've had to develop it ourselves as we go along. So this would actually give us something more concrete. So it would change existing implementation. Is that --
MR. CURRAN: Okay. So it's going to give us something more concrete which matches what we're currently doing or which is more aggressive or less aggressive?
MS. NOBILE: It could be more aggressive.
MR. CURRAN: Okay.
MS. NOBILE: I think --
MR. CURRAN: That's a answer. Okay, that helps address the concern that you had in terms of just making sure the audience knows how non-impacting these changes are. Front microphone.
MR. DeLONG: Owen DeLong, JITTR networks. First, Leo, thanks for putting so much time and work into this, it's been badly needed for some time and I think it's a good policy, I support the policy as written. I think the minor changes that it does make, and I view the.94 Host-Density ratio as a minor change not because I think it is non-substantive, but because I think that it is in line with the intent of the authors of the original proposal, and that the lack of a criteria was an oversight originally and that it is most consistent with the other places where this was not overlooked in the implementation, thank you.
MR. CURRAN: Okay, good to have. Back microphone.
MR. WEILER: Sam Weiler, Sparta. I have no objection to the proposal as written, I will leave it for others who care about the specifics of the HD ratio to argue for the specifics. And I'm very sympathetic to the need to make little cleanups like this, preferably efficiently as one might've guessed from my earlier issue at the open mic. However, I think this all points to some problems in disconnect between policy proposals and the Number Resource Policy Manual. Looking at the Number Resource Policy Manual here in my left hand if I were looking at a book of legal code -- legal codes, there would be a lot of cross references to the actual law -- to the actual bills that pass through Congress implementing them. And I'm disappointed that this does not have a list of citations to the policies that implemented them. So we could go back and say what did we intend when we enacted 6583, what policy is that from and what the heck were we thinking. I would like to see those cross references.
MR. CURRAN: Okay, so --
MR. WEILER: That's the general thing.
MR. CURRAN: -- I believe, you're for the proposal, but you further note that if the Network Resource Policy Manual had the cross references to the policy proposals, it would be easier to determine whether or not the -- it was in the policy as written?
MR. WEILER: It would be easier to determine what we were thinking, and in fact whether there's something in here that was never brought through the public policy process, it's a good crosscheck. I have tried to raise that through the ACSP and it seemed to be misheard.
MR. CURRAN: Okay. I will just point out that the policy manual is a huge step forward from when we were say five years ago, but obviously, it can be better. Okay. All right, thank you. Far microphone.
MR. NARTEN: Yeah, Thomas Narten here. So -- I wanted to -- I support this policy, and I will have to say I'm a little bit surprised to hear that the suggestion to the.94 ratio is actually maybe a change in what we're doing or what was intended, because I think the assumption all along was that we would use the HD-Ratio across the board unless there was a good reason not to, and so I agree that we need to do this.
MR. CURRAN: Okay. Far microphone.
MR. BURDEN: Ken Burden, Hewlett-Packard. As a very large enterprise, telling me I can have one /48 misassigned.94 percent usage and then I get another /48 it's problematic when you design an address plan for a large corporation like Hewlett-Packard. Therefore I have a problem with the.94 requirement. I can't design an architecture address plan that way.
MR. BICKNELL: I don't think that's accurate and Leslie may be able to respond to you, but I believe if you went to ARIN with a plan that said at a.94 ratio, I need a /44 to do my plan, they would give you a /44.
MR. BURDEN: Okay --
MR. BICKNELL: -- if that's passed.
MR. BURDEN: Okay. That needs to be clarified here, because that's not clear. So we can hopefully like some other folks said, "avoid in the future what did we really mean."
MR. BICKNELL: Right. I would suggest it's the current policy that's unclear. The current policy says, "You must justify it, period."
MR. BURDEN: Okay, that --
MR. BICKNELL: It gives you no rules. Because if you came in and just read this. If I gave this to someone else in my organization they would not come to that conclusion.
MR. CURRAN: So given that this is a step at least stating criteria, would you be for the proposal as written?
MR. BURDEN: If I could show justification that I needed more than /48 -- meaning the.94 -- the.94 I'd have to think about more to see how practical that is, because there's some routing considerations and the rest of my team I don't want to have run past, but maybe.
MR. CURRAN: Okay. Maybe. Thank you. Cathy abandoned the --
SPEAKER: Bye --
MR. CURRAN: Bye Cathy. Over here.
MR. DICKSON: Brian Dickson, Afilias. I'll address one specific point, and then I'll comment on the.94 separately. A specific point I would suggest that under section J, where it says all /56 and larger assignments, I would prefer to see Modulo's requirement for -- privacy requirements that any assignment be registered, simply because we don't know if future policy changes may require subsequent greater level of tracking of allocations, and rather than be reactive at that point being proactive at the beginning, saying let's just register everything that's been assigned, it doesn't even necessarily have to appear at a visible WHOIS as long it's being registered, I think that that will go a long way towards longevity of maintaining records on what's getting used in IPv6.
MR. CURRAN: Comments or thoughts?
MR. BICKNELL: Again, I -- this was simply copied from the current proposal if you remember J came from 6.5.3, which says this today. And I threw away the part that's in my mind not policy and random rambling that shouldn't be in a policy manual and kept exactly what was left, and put it in the right place in the policy manual. So I'm not going to take a position on whether or not the /56 should be changed, because I do have an opinion, but that's not relevant to what I'm doing right here. And again, I think that would be a great follow-on proposal.
MR. DICKSON: Yeah, I see that -- if you can go back to the previous slide.
MR. BICKNELL: That's what's in the manual today.
MR. DICKSON: I would suggest that the /56 concept is antiquated, but removing the "all /56 and larger" -- sorry, the "/56 and larger component," if it says, "all assignments to end-sites," that would be -- consistent with the spirit and palatable.
MR. CURRAN: So you oppose this policy as is, but would approve it -- would agree with it if this was changed so it read --
MR. DICKSON: "All assignments to end-sites."
SPEAKER: That's (off mike) /56 and larger.
MR. CURRAN: Okay. And I guess, I'll ask the author. Is that a change you wish to support or not?
MR. BICKNELL: I would be amenable to that change if it's what the room wanted.
MR. CURRAN: Okay. If anyone thinks that's a bad change, first everyone step back from the mic for a moment. If anyone thinks that's a bad change I'd like to know.
MR. LEIBRAND: Scott Leibrand, Internap, whether or not that's a good change --
MR. CURRAN: Yeah.
MR. LEIBRAND: -- it's not housekeeping. This -- we're trying to be non-controversial here, move things around, clean things up. If you want to change policy such that every last home user getting a /56 has to be in WHOIS or has to be tracked some other way, that's a substantive enough change with enough privacy implications and discussion that it should not be part of what we're discussing here right now.
MR. CURRAN: The change proposed you believe would move this from a policy which makes housekeeping changes to a substantial policy of -- change of policy?
MR. LEIBRAND: I agree.
MR. CURRAN: Okay. Other people want to speak on this matter? Yes, Matt? Oh, sorry, Stephen.
MR. SPRUNK: Yeah. Stephen Sprunk, Polycom. I disagree with the specific change that was just proposed. I would -- was up here already to say that I support this proposal in general, because it's just basically editorial or clarifying intent. I think we can disagree on whether that intent was correct. And -- but that is not the purpose of this proposal. And yes, as Scott said, those need to be individual proposals. If we want to change the.94, then we need a proposal for that, but that is what I had understood the intent was if -- even if it wasn't written down before. You know, if we want to debate intent that's one thing, but I think this discussion, I think is supposed to be limited just to making editorial or clarification changes not actually changing the intent.
MR. CURRAN: Right. And so along those lines with the proposal as written, you support it?
MR. SPRUNK: Yes.
MR. CURRAN: Including the, "all /56 and larger"?
MR. SPRUNK: Yes.
MR. CURRAN: Okay. Back of the room.
MR. LEWIS: I've to apologize for missing part of the presentation here. I walked in when Leo asked when -- where should these changes come from. Well, first of all, I am -- I'm for the policy, especially as it's just clarifying. But the question I have we asked the staff if they think there's more clarifications needed that would fall under this same topic, maybe not this proposal, but the same topic, because I think the reason why I'm asking -- I think the staff probably gives the best idea of what would be a non-substantial change to wording -- it is their interpretation.
MR. BICKNELL: We -- I have had some discussions with staff not many, and you can go back to the original version, there's a proposal on the mailing list with 15 changes. The AC had a lot of hemming and hawing as to what was and wasn't policy; I'm sure staff has their own opinion. The reality of it is today, we have no process to make a non-policy change to the NRPM. So even if somebody figures out that we simply left a period off the end of the sentence, there's no way to edit that document without writing a policy for it, and that maybe the deeper issue.
MR. LEWIS: Okay, I'll just leave it at that.
MR. CURRAN: Okay, thank you. Far microphone.
MR. NARTEN: So -- Thomas Narten here again. I would say -- again, I support this as is, I would be very hesitant to modify the /56 for all the reasons that were said before, and also I think it's actually -- in this case we -- sort of bad policymaking to make that kind of a change, you know, on the fly, in a meeting, and then walk out and realize, "Wait a minute, we didn't really think through that" -- "that through very carefully."
MR. CURRAN: Understood. Okay, rear microphone.
MS. SCHILLER: Can I comment on the -- what he just said --
MR. CURRAN: Yep.
MS. SCHILLER: -- and that is that if you choose to make this change, there are other places in the NRPM that say that you need to SWIP /56 and larger that you would also have to change.
MR. CURRAN: Right.
MS. SCHILLER: -- that aren't being addressed here.
MR. CURRAN: Okay.
MS. SCHILLER: That's all.
MR. CURRAN: Good point. Far out. You still at the mic, Thomas, no, okay. Far microphone.
MR. POUNCETT: Matt Pounsett, Advisory Council. Yeah, just to support what a couple of other people have already said. I am in favor of this proposal as it's written now. Removing the /56 reference here would cause me to have to think very carefully about whether I was still going to support it, because I think it's a -- that's a bigger change than just housekeeping.
MR. CURRAN: Okay. All right. Other comments on the proposal. Microphones are open, anyone would like to speak a second time? You at the microphone?
MR. DICKSON: Oh, sorry. Yeah, I wanted to address the.94 issue.
MR. CURRAN: Sure.
MR. DICKSON: It's difficult to do without a white board unfortunately. Effectively, the issue is hierarchical aggregation; something I've addressed in other forums. When you do hierarchical aggregation, it is essentially almost a -- an assumption built in that it is going to be inefficient, but it is inefficient only in terms of the total number of end assignments. It is much, much more efficient in terms of the internal ability to hold a routing table with a very large number of prefixes. If you've a hierarchy of two or three levels of aggregation, the density may go down a long way, it may go down to a.5 or.3. But it may allow you to hold three or four orders of magnitude and more prefixes in your infrastructure than would otherwise be the case. So having a requirement for.94 is a serious contraindication, a serious impediment to anybody who knows what they're doing about allocating addresses and aggregating them internally.
MR. CURRAN: Okay --
MR. DICKSON: Is that confusing, too technical?
MR. CURRAN: Not at all, but my question is without this -- without -- with the inclusion of.94, you -- as written, you would be against the policy proposal.
MR. DICKSON: And I would advocate other people to be against it as well.
MR. CURRAN: Okay, understood.
MR. BICKNELL: If I may comment.
MR. CURRAN: Fine.
MR. BICKNELL: I'm going to guess that Geoff is going to answer his question far better than I ever could, so could we hear from Geoff?
MR. CURRAN: Geoff.
MR. HUSTON: Geoff Huston, APNIC. The reason why we're using a logarithmic ratio and the reason why the whole thing is HD is all about accounting for the fact there are multiple levels of hierarchy inside large networks. The entire decision about HD-Ratio.94 was made by this group and other regional groups in the precise knowledge that this formulation allowed large networks to have 5, 6, 7, or even 8 levels of hierarchy, depending on their size. So the criticism that is being directed at this, that HD-Ratio.94 only require -- or applies to flat or virtually flat networks is indeed incorrect. Now, here I am simply making a judgment of mathematics, thank you.
MR. CURRAN: Okay. So --
MR. HUSTON: Far better than I --
MR. CURRAN: -- rear microphone. Further comments on the proposal?
MS. SCHILLER: Can you put the different -- the slide that said the 200 end-sites back?
MR. BICKNELL: Yes.
MS. SCHILLER: So I have a question, and I just --
MR. BICKNELL: Two hundred -- that was the first one, wasn't that?
MS. SCHILLER: -- can't remember why we went this way.
MR. BICKNELL: Okay.
MS. SCHILLER: The one where it shows the change.
MR. BICKNELL: There you go. Existing text on the top, proposed text on the bottom.
MS. SCHILLER: So can you remind me why we wanted to move toward a change from 200 assignments to 200 end-site assignments --
MR. BICKNELL: Yes, so the reason here -- if you go read, there's policy proposal 2005-8, which was already implemented, I believe, a year ago, without looking. And what that policy proposal specifically did is allow ISPs to allocate things other than a /48. So prior to that the expectation of all the policy was when you allocate to your customer, it's a /48, no bigger, no smaller ever.
MS. SCHILLER: I'm with you on that part.
MR. BICKNELL: Right. So this policy specifically said, "you know what, if you want to get all your DSL customers /56s, good for you." And the problem is, people then came back and they actually stood up in the Puerto Rico meeting and said, "So I'm a DSL provider, and I have 500 /56 customers, can I get a v6 prefix under this?" And staff hemmed and hawed a little bit, and people in the room hemmed and hawed a little bit and said, "Well, you got more than 200 things, but if you do your /56s and add them up, it's only like three /48s worth of space, so that doesn't really count." So is it the sites that matter or is it the 200 times /48 total addresses that matter. And from talking to people between Puerto Rico and now, more people seem to support the 200 site requirement than the 200 /48 equivalent requirement. So that's why I've proposed it that way.
MS. SCHILLER: Okay, it's nit picky, but my concern is for organizations who don't really have an end- site, but want to make further ISP assignments to their customers, so like a organization that would want to make tier two assignments. And this is -- I think what I'm trying to say is that is it lenient enough that ARIN's staff would recognize that -- to also include something for -- not just end-sites, but when you're making assignments for ISPs, it --
MR. BICKNELL: I think that --
MS. SCHILLER: I'm surprised that Jordi's not up here saying like, "This is too strict, it doesn't include if you're making a assignments for" --
MR. BICKNELL: If I could rephrase your question for probably Leslie --
MR. CURRAN: All right.
MR. BICKNELL: If a ISP came in today and said, "We have made 201 /64 assignments to customers, would the conflict between 2005-8 and this text -- would you accept that or not today?
MS. NOBILE: So it wouldn't say 200 /48 assignments, they made 200 /64 assignments you're saying --
MR. BICKNELL: Right, because --
MS. NOBILE: No, we wouldn't accept it, we are literally reading that as /48 assignments, yes.
MR. BICKNELL: Okay.
SPEAKER: Oh, yes.
MR. BICKNELL: So this would represent a change?
MS. SCHILLER: But if -- and -- but if you changed it to this new text where it says end-site assignments, and I said, "Well, I'm not going to assign, I don't have 200 end-site customers, all my customers are ISPs"?
MR. CURRAN: Would you interpret the -- if the proposed --
MS. SCHILLER: That's what I --
MR. CURRAN: -- text was in effect Leslie, would you interpret the assignment of 201 blocks to ISP customers as end-sites?
MS. NOBILE: No. If it said, "end-site assignments," I would assume it would be end-user site assignments. And it says "assignments," generally, we refer to reallocations to ISPs as "allocation," so that clearly has end-site plus assignment, which to me would be an end user organization.
MR. BICKNELL: And I was going to say now I see where you're getting. End-site was specifically chosen, because the term "end-site," is actually defined in the NRPM.
MS. SCHILLER: I understand that, I'm just concerned that it leaves out a large chunk.
MR. CURRAN: Given that -- whoa, whoa, whoa, whoa, you don't get to get away. Given that Heather, knowing that it's end-site as defined by the manual, are you for or against this proposal?
MS. SCHILLER: I'm against it, but I have to say it, I wish I caught it earlier.
MR. CURRAN: Okay.
MS. SCHILLER: Sorry.
MR. CURRAN: Fine. Okay. Far microphone.
MR. NARTEN: Thomas Narten here. So let me maybe answer Heather's request or comment. Looking back at this, I think that -- as one of the authors of the proposal that changed /48 to /56, you know, in the previous round, I believe, it was an oversight not to change this wording. I think the intention was -- everywhere where there's a /48 it should be a /56 and this is an oversight. So I hear what Heather is saying and I think there is a -- an issue there that is worth exploring and understanding and see if a fix is needed, but I think this is the wrong time to have that discussion and to block this change on that, because the issue is also there with /48 versus /56s.
MR. CURRAN: Mr. Thomas, I want to ask -- because I -- are you saying this should proceed and then you should put a policy change on top of it, or this should not proceed?
MR. NARTEN: It should proceed in the -- in a separate policy proposed if appropriate.
MR. CURRAN: Thank you. Okay, back microphone.
MS. AZINGER: I need a clarification because of a comment that was made by another person. So -- oh, sorry, I'm Marla Azinger, I work for Frontier Communications. So I got confused, because I didn't think this changed the effect of whether or not a SWIP had been done for like /56s or /64s. And then someone made the comment that this would change that, so what is the actual effect of this -- would you no longer require SWIPs for /64s and /56s?
MR. CURRAN: Well, so -- that's a question to Leslie. If the proposed text was implemented, would it affect the need for SWIPs for these customers, is that what you're asking?
MS. AZINGER: Yes.
MR. CURRAN: Point of information to staff. If the proposed text for 220.127.116.11.d was changed to the existing known ISP in the ARIN region, or have a plan for making at least 200 end-site assignments to other organizations, does that affect whether you'd have to SWIP these?
SPEAKER: Is that about --
SPEAKER: I don't think it's about that --
MS. AZINGER: It's not this, sorry, it's not this text. I'm sorry, I jumped a subject, it's -- and I don't know which one it came from, so I confess that --
SPEAKER: Are you --
MS. AZINGER: -- but it was one of the --
SPEAKER: Are you on this one probably? Whoops --
MS. AZINGER: I think it was on the last one, that one.
MR. CURRAN: Here you go. So 6.5.3. If that was added does it affect whether or not SWIPs would --
MR. BICKNELL: No, in this one what happens is the text in white gets thrown away and the text in yellow simply gets moved to a new section.
MS. AZINGER: So the answer is?
MR. BICKNELL: The text in yellow is what's there now, and it does not change in any way shape or form.
MS. AZINGER: So SWIPs will still be required?
MR. BICKNELL: I'm not going to say that, because I don't know if they're required today, but it shouldn't change --
MS. AZINGER: Okay, that's what I wanted the answer to.
MR. BICKNELL: -- whatever it is today.
MR. CURRAN: I'm being told, yes --
MS. AZINGER: Yes --
MR. CURRAN: -- wouldn't change it.
MS. AZINGER: Thank you.
MR. CURRAN: Okay. Wow. Okay. Owen.
MR. DeLONG: Getting back to the subject before --
MR. CURRAN: Name.
MR. DeLONG: Oh, Owen DeLong, JITTR Networks, sorry.
MR. CURRAN: Thank you.
MR. DeLONG: When you call me by name, it's hard to remember I need to tell people my name.
MR. CURRAN: I didn't mean -- I didn't introduce you thoroughly.
MR. DeLONG: Yes, understood. Getting back to the -- was it 18.104.22.168.d -- subject, I think that perhaps we could do what we've done with some other proposals, and if Leo is willing we could consider changing 200 end-site assignments to 200 delegations, and that way it would cover both end-sites and ISP allocations and it would still preserve the intent being a relatively minor amendment.
MR. CURRAN: Do you consider that a good change?
MR. BICKNELL: I am somewhat more reticent to make that change, because staff has already made the comment that this is more permissive than their current interpretation, and that to me would be even more permissive than this. So I'm worried that that drifts us even further away.
MS. ARONSON: But -- plus, we haven't defined "delegation."
MR. CURRAN: Right, it's -- it is not one of assignment or allocation yet. Okay, anything else Owen?
MR. DeLONG: Nope, I thought delegation was the term we used to describe assignment and/or allocation.
MR. CURRAN: I haven't looked in the policy manual, but I don't believe it's in there right now. Yes, far mic, Matt.
MR. POUNCETT: Matt Pounsett, Advisory Council. I think Heather's issue is actually already handled by 22.214.171.124.c, which says, "An organization must plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space." It seems to me that it's talking about LIR to LIR assignments, unless I'm completely misreading it. And if I'm right, then that would mean that this is sort of additional text to deal with end-sites whereas c is already --
MR. CURRAN: A particular response. Heather, do you wish to respond?
MS. SCHILLER: There's a big and at the bottom that says, "And the 200 sites," and that's the part that's going to change."
SPEAKER: Right, okay.
MR. CURRAN: Okay. I'd recommend taking this one offline together, okay. Center microphone, Jason.
MR. SCHILLER: Jason Schiller, UUNET, Verizon Business. Following Owen's lead, rather than using the term "delegation," why not "200 assignments or allocations"?
MR. CURRAN: Okay. Would you support that, that's more specific at least in what it's doing?
MR. BICKNELL: I still have the same concern --
MR. CURRAN: -- you had before --
MR. BICKNELL: -- that we have moved from here to here with this one and we're going to move on over so --
MR. CURRAN: Right.
MR. BICKNELL: -- unless the room voices really strong support for that --
MR. CURRAN: Passed by the author, okay. Far microphone.
MR. LEIBRAND: Scott Leibrand, Internap. If we're concerned about making too many changes, which I am -- I share that concern. Well, why not make fewer changes and do something along the lines of the existing text replacing /48 with /56. So the -- my proposed text would be have a plan for making at least 200 /56 assignments to other organizations within five years.
SPEAKER: So --
MR. CURRAN: Quick response?
MR. BICKNELL: I would be more amenable to that amendment, my first question to you would be, 2005-8 also allows /64s so is /56 really the number you want to use?
MR. LEIBRAND: Or remove the prefix size entirely, but use the text otherwise.
MR. CURRAN: And that's what --
MR. BICKNELL: Well, that's -- what I did is remove it entirely.
MR. CURRAN: -- he did was remove the prefix size entirely. Okay?
SPEAKER: -- out of --
MR. LEIBRAND: Well, you -- the problem is you removed prefix size --
MR. CURRAN: I know.
MR. LEIBRAND: -- and replaced it with end-site.
MR. CURRAN: Correct.
MR. BICKNELL: Which is a term defined in the NRPM so --
MR. LEIBRAND: It's a term defined in the NRPM to mean organizations that are -- that would receive assignments not allocations --
MR. BICKNELL: Correct --
MR. LEIBRAND: -- non LIRs, whereas the existing text as I read it just says that you have to give out 200 /48 assignments, but they don't necessarily have to be to end-sites.
MR. BICKNELL: An assignment is to an end-site an allocation is to a downstream LIR.
MR. LEIBRAND: Right.
MR. BICKNELL: So an assignment by definition goes to an end-site, that's also defined in the NRPM, I believe.
MR. CURRAN: As written, would you support this proposal?
MR. LEIBRAND: I do support the proposal as a whole, I am only trying to suggest minor improvements to this, but as a whole, I support the proposal.
MR. CURRAN: Okay, center microphone, rear. RS.
MR. SEASTROM: Rob Seastrom, ARIN AC and Bob Clue Trust. I am in favor of this proposal. I have one comment to make however, and I am -- I realize and acknowledge that I'm at considerable risk of being accused of being over pedantic here. However, at the risk of being accused of trying to set up ARIN's own version of RFC 2019, I notice there is inconsistent use of the terms, "larger and smaller" versus longer prefix and shorter prefix in the NRPM, and I see those terms being bandied about in this proposal as well. And I am in favor of the terms, "longer prefix and shorter prefix," because I believe that they are more exact and less likely to lead to confusion.
MR. CURRAN: Okay, I'm going to ask a question. As written, would you support this policy proposal?
MR. SEASTROM: I absolutely support policy proposal, however, I had that wordsmithing feedback --
MR. CURRAN: All right. Given that there's inconsistency in this proposal, and in the policy manual itself?
MR. SEASTROM: I am in favor of taking on and fixing that at a later date.
MR. CURRAN: I'm looking forward to that wordsmithing policy proposal.
MR. SEASTROM: It'll just be a big policy proposal with a bunch of strike and replace within it.
MR. CURRAN: And it will be editorial just like this one. Should go through very quickly, thank you.
MR. SEASTROM: Thank you.
MR. CURRAN: Lea.
MR. ROBERTS: Lea Roberts, Stanford University in the ARIN Advisory Council. I just like to comment on the 200 /48 assignments. I mean, basically that's -- sort of says "end-sites," because that was the assumed prefix length that would be assigned to end-sites. I don't disagree that it needs to be, you know, changed and made better, but I don't think that this proposed change really makes any substantive difference other than making it clearer in the light of /56s. So I support this proposal.
MR. CURRAN: Okay. Is -- I got three people over there right behind a microphone. You guys got to move out of the line of my view, okay. Cathy.
MS. ARONSON: Cathy Aronson again. I just wanted to second what RS said, I think that the prefix lengthening is a bit -- is a real -- is -- just needs to be fixed, so I guess, I'll be helping him and I still support the proposal.
MR. CURRAN: Okay, thank you. One closing comment Leo.
MR. BICKNELL: Yeah, I just wanted to make one quick closing comment. And this kind of goes back to my rant at the beginning. Please go back and read the original list of 15 changes on the mailing list. Again, we're struggling with which ones are and aren't substantive changes, which ones are and aren't controversial. And this was picked out because we thought a few people might have some issues with it. I think we picked well. But we really do need your feedback so we can appropriately order these in the future, because there's going to be more. It sounds like RS just found a new one that we're going to have to take on.
MR. CURRAN: Okay, thank you very much. (Applause)
MR. CURRAN: Good afternoon. Now is that point of time in the program where we seek a show of hands from the community so the Advisory Council can have input for their job on the matter of Policy Proposal 2007-25. I'm going to ask for a show of hands for all in favor, and then all opposed. So if everyone is ready, all those in favor of advancing Policy Proposal 2007-25, please raise your hand. Nice and high. We count a little slower after lunch; you've got to keep them up longer. Thank you. All those opposed to advancing Policy Proposal 2007-25 raise your hand. Nice and high. Okay, the count is advancing this way. Ray will sing the next song from one of his greatest hits. Okay, on the matter of Policy Proposal 2007-25, there is 125 people in the room, those in favor of advancing, 49; those opposed, 1. Thank you very much.
2006-7: Changes to IPv6 initial allocation criteria
MR. PLZAK: Okay, Policy Proposal of 2006-7; changes to IPv6 initial allocation criteria. This was first introduced in October of '06, and was designated a formal proposal then. Its first discussion was during ARIN XIX; community consensus was to revise the proposal. It has not been revised, and this is the next meeting for it to be discussed. (off mike) criteria for the initial allocation of IPv6 address space specifically in addition to the common criteria of an ISP is not known nor -- known, nor can it provide a plan, it can instead attempt to justify intend to announce address space within 1 year. The shepherds are Lea and Rob. Three posts, three people. One for, none against; those are the comments. Counsel sees nothing. Staff comments; the statement being "known ISP" is still contained in the policy, this term is ambiguous, and is the same as the comment in the previous proposal. The ARIN staff is concerned about the confusion that may occur if text is inserted as the author indicated, letter "d" already has an "or". Staff suggested an alternative replacement. How can staff verify that an organization is new to providing Internet services? What happens at the end of 1 year if the v6 bock in not announced? What if the IPv6 address space is used on a private network and can't be seen from the public internet? And the change may would be -- change in the manuals as indicated. A minimal impact to implement, requires some guidelines and change in staff training. And so Jordi?
MR. MARTINEZ: I have no slides because I was not really intending to present again the proposal. In part it is my fault because I have not revised it, but also I didn't have -- the -- in the mailing list didn't occur at any additional discussion to this proposal. And I was thinking also that for example the previous proposal somehow may impact in the resource for this one. So more than asking for support for the proposal or not, I will be interested in really understanding if the people has the same opinion as I have regarding the possibility of new ISPs, which means basically not known in the region, willing to provide service and not having a plan, and that means not willing to lie about having 200 customers. So that will be the real question, and the real basis for moving forward with a new revision of this proposal or withdrawing it. That's my question actually.
MR. CURRAN: Okay, members at the microphone on the need for this policy, and how to address new networks in the region who may not have a plan for 200 sites, and wish to be -- but true to their applications to ARIN. I see Owen.
MR. DELONG: Owen DeLong, JITTR Networks. I'm pretty liberal when it comes to address policy, I think most people would agree, and I just don't see a need for this. Frankly if you are intending to be an ISP, and you are intending to have fewer than 200 downstream customers, you probably can use provider-assigned v6 space. I could probably be convinced otherwise, but I don't see anybody starting up a meaningful ISP going forward without at least having some plan to have 200 or more customers. Whether they actually achieve that plan or not, as I read the policy, is irrelevant in any time frame. The requirement is that you have a plan to do so at the time the space was issued, and if you still have some form of plan to get there, I would consider you still to be in compliance. I don't think you should have to lie about that. And I don't think you should lie about that. But if you don't have a plan to get at least to that far, I don't really necessarily see that renumbering if you change upstreams is such a huge drag that you need provider-independent space and the slot in the routing table for it.
MR. CURRAN: Okay.
MR. MARTINEZ: But you don't have support for multihoming?
MR. DELONG: I believe the PI end site multihoming policy takes care of that.
MR. CURRAN: Okay, back microphone.
MR. DIVINS: Dave Divins, Server Vault. I think there is a need for a new ISP requirement to get so that people don't have to lie about plans. As far as -- you know, the number of 200, or being seen in a global routing table, I think if a lot of private networks that need guaranteed uniqueness and things like that that if you have the right 100 customers, you might never need to grow beyond that as far as to be a profitable business. So I think there is a need for something like this, and I think it's a pretty low risk, yeah, a change that might help kind of promote some growth in this.
MR. CURRAN: Okay.
MR. MARTINEZ: If I can make one comment I just remind -- this has been removed already in three out five regions, I think that's an important consideration.
MR. CURRAN: Has been removed?
MR. MARTINEZ: In three out of five regions.
MR. CURRAN: When you say it's been removed you mean this Policy Proposal or something similar has been discussed?
MR. MARTINEZ: The 200 -- the need for a plan for 200.
MR. CURRAN: Ah, the need for a plan for 200, that constraint has been removed?
MR. MARTINEZ: Yes.
MR. CURRAN: Okay and that's good to know. Far microphone?
MR. LEIBRAND: Scott Leibrand, Internap. I caught a comment that you said that without PI space, without an allocation as an LIR you can't multihome?
MR. MARTINEZ: No, what they -- I mean is if you go for the existing PI policy, because you need to multihome, what happens is that you get a /48 or a /44, but maybe you'll have 200 customers but you still want to allocate the /48s to your customers, so maybe you don't have enough of space. I'm not really sure if that will be sufficient, I'm not really sure right now. I will need to go to the Number Resource Manual to see if you will be able, for example, to get other numbers, /32 or whatever is necessary to cover all those customers which is /48.
MR. LEIBRAND: Okay, well, that's not what I was talking about because you can't get a /48 under PI policy if you are a LIR. That's for end sites.
MR. MARTINE: Yeah.
MR. LEIBRAND: If you are a LIR, you either need to have a plan to be big enough to get a /32 or you need to get PA space from your upstream. So I think what's been argued, and I would agree with it, is if you are not planning to get bigger than 200 customers, well, you really should be getting PA space from your upstream until such time as you decide to grow. And are you arguing in that case that you would not be able to multihome?
MR. MARTINEZ: If you have a single upstream that's okay, but what happen if you have several upstream?
MR. LEIBRAND: I get /whatever -- /40s from each.
MR. CURRAN: Okay, so to wrap this one up, given the Policy Proposal, do you support it or not?
MR. LEIBRAND: I don't think that this Policy Proposal is necessary at this time. If we ever receive someone who gets denied space because of this issue then I think at that time we should revisit but I don't see any for doing this now.
MR. CURRAN: Okay, rear microphone, center room.
MR. LEWIS: I had a question, Jordi. The question about new ISP has come up before. And you said this time "new to this region." And I was just wondering if you meant that if as -- an ISP working somewhere else in the world is new to the ARIN region is that what you meant by new to this region or is or just start from scratchy?
MR. MARTINEZ: That may be a case. It may be both cases actually, maybe both situations.
MR. CURRAN: Is that clarified?
MR. LEWIS: Yeah, that's the question I wanted to ask.
MR. CURRAN: Do you support the Policy Proposal?
MR. LEWIS: Given it's something revised as last time I didn't support it and I don't support it now. So --
MR. CURRAN: So no?
MR. LEWIS: Yeah, still no, yeah.
MR. CURRAN: No is good. I just want to hear yes or no. Far microphone?
MR. NARTEN: Thomas Narten here, I guess I'm opposed to this, and the problem is I don't really and fundamentally understand why it is needed, and I think it sets the bar too low. Because all it really says is you have the intention to announce it, and you are good to go, and that's a pretty low bar for getting a /32.
MR. CURRAN: Okay, center microphone?
MR. BICKNELL: Leo Bicknell, IFC, ARIN AC. I'm against the proposal but I specifically wanted to make a comment on what you just said. Hopefully although it's not a done deal yet, based on the previous proposal, if you need it bigger than a /48 under the PI proposal, now you can get the via the.94 ratio which I realize is now 10 minutes old maybe if it -- gets thrust the way through, but that problem may have actually been solved.
MR. CURRAN: Yeah, thank you. Okay, far microphone.
MR. SPRUNK: Stephen Sprunk, Polycom. I guess I don't see the case where this change would matter happening. It basically, you know, it's only covering the case where you are not an existing ISP, and you don't have a plan for 200 customers. And you know, you don't intend to do IPv4 which would, you know, allow you to get to the point of doing, you know, you become a known ISP. I don't see a case today where someone could create a credible ISP without doing IPv4. I think maybe in 3 or 4 years we may need a policy like this. But again I think the community even in our v4 policy, you know, you have to start out with PA space and then grow to the point where "you deserve a routing slot in the DFZ" and the metric that this region has set is, you know, 200 customers. You can argue, you know, what -- if that should be 200. I think we could entertain a debate whether it should maybe be 100 or 50. I think setting it as zero is wrong. I think -- you know, so I do not support this proposal, John, but you know, I think that, you know, the proposal, if you are going to keep pursuing this thing as we modify it to maybe change what that bar is, not try to get rid of it.
MR. CURRAN: Okay.
MR. MARTINEZ: I think we have a similar comment in the previous meeting, and I believe I made the question to Leslie, what happens if a new ISP asks for IPv4 space also, and then ask for IPv6. And I'm not sure what was the response to that but I believe in that case it will not qualify because it's just still a new ISP but if he is asking for IPv4 space, but amateur. That's right, yeah?
MR. SPRUNK: Yeah.
MR. CURRAN: Okay, all right, thank you.
MR. MARTINEZ: So in that case we'll not be able to get the space.
MR. SPRUNK: But again the -- you know, the policy also for v4 is, you know, you need to be -- you need to have a track record with, you know, with PA space to get PI space. And that's the exact same thing we are doing with v6. You know, if we don't have a policy in v4 that says, you can get space with no track record, then I don't think we should have that policy in v6. I think, you know, maybe readjust the bar, and that could be a worthwhile discussion, but saying there is no bar at all -- I can't support that at all.
MR. CURRAN: Okay, far right microphone.
MR. DICKSON: I'd like to address the question of 200 end customers as an ISP -- Brian Dickson with Afilias but previously with Teleglobe. I would like to point out that Teleglobe between 19 -- mid 90s to 2000, went from very small to being a tier one ISP or -- in the DFZ, had no upstream providers, had on the order of 15 percent of the DFZ announced by its customers but internally had fewer than 10 customers. It was an ISP, it was tier one, but it never got a significant number of PA end assignments that it gave out. So I think there are counter examples for the assumption that everyone is making that you can't be an ISP and not have at least 200 customers, or even a 100 or 50. That argument is demonstrably false. And that's the reason that I'm saying I don't think 200 should be in this proposal or in a lot of other places in the NRPM.
MR. CURRAN: Well, okay, this proposal adds a fifth option which effectively says you don't need to meet the number 200. So are you for this proposal?
MR. DICKSON: Could you put the proposal up again, sorry -- while, I'm at the mic, I don't have it in front of me.
MR. CURRAN: Proposal text? We're working on it now.
MR. DICKSON: Sorry.
MR. CURRAN: As it reads, it says, "Add a new line item to section" -- "item E to section 126.96.36.199 of the NRPM." The new line item would read, "or be an organization new to providing internet services, and can justify the intent to announce the requested IPv6 address space within one year through records such as contracts, inventory, or other applicable documentation." This doesn't change the prior item, it gives another way to meet the requirement. And since it's "or" it's another way in lieu of having to meet the 200 requirement.
MR. DICKSON: For it, sorry.
MR. CURRAN: So you'd be for the proposal, thank you. Okay, center microphone, back.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I have a point of information. Have we had requests for IPv6 PI space that's greater than /48 and have we granted any?
MR. CURRAN: Ah, Leslie.
MS. NOBILE: Yes, we've had quite a few requests for larger than /48s, and yes we have issued them. Up to a /40 I believe is the largest PI block we've issued.
MR. CURRAN: Okay, good information. Far microphone?
MR. LEIBRAND: Scott Leibrand, Internap. People are talking like 200 customers is the only way to get this block but this is an "or" proposition, we are adding a fifth line item, and another "or." One of those line items is "be a known ISP." If I go and get PA space and setup business and run for six months, I'm probably a known ISP, or maybe it takes a bit longer, but it's not like v6 is unavailable to these customers. It's just they have to have a track record, and that track record doesn't require 200 customers, but it requires existing for some period of time as determined by ARIN staff.
MR. CURRAN: Jordi, would you like to respond it?
MR. PALET: Yeah, I think the problem, and Leslie is already telling me is that there is not a definition of what is a new ISP? So the staff has no way to evaluate that somehow, right?
MR. CURRAN: Leslie?
MS. NOBILE: Is it okay if I comment. Yeah, we have had no direction on that. So what we determined was a known ISP in the ARIN region is someone who has been a subscriber member for at least one year, and has customers that we can see have been reassigned.
MR. CURRAN: That's what the staff's working assumption has been using for that.
MR. LEIBRAND: So I would argue that if I don't have a plan for 200 customers, I can live with PI space for a year.
MR. CURRAN: Okay, any other comments on this proposal. Jordi thank you.
MR. PALET: Yeah, thanks.
MR. CURRAN: Okay, first to provide the AC guy who isn't doing their job, I'm going to call for a vote on whether we should advance Policy Proposal 2006-7. And I'm going to ask everyone in favor for advancing it, and everyone opposed, okay? So on the matter of Policy Proposal --
MS. ARONSON: I'd just like you to refer to it as a show of hands, please?
MR. CURRAN: Thank you, then I'll ask for a show of hands on polls -- on advancing Policy Proposal 2006-7. Everyone in favor of advancing Policy Proposal 2006-7 please raise your hand? Nice and high. Okay, thank you. Everyone opposed to advancing Policy Proposal 2006-7 please raise your hand? Okay, thank you. On the matter of advancing Policy Proposal 2006-7, total number of people in the room 125, in favor 9, against 39. I need to seek concurrence with my vice-chair. This Policy Proposal has come before the body twice in substantially the same form, and has not obtained sufficient consensus to be advanced. Scott, should I entertain a show of hands on abandonment of this proposal?
MR. BRADNER: I would say yes, the recommendation last time was for revision. Revision wasn't -- didn't happen, so I would say at least this time to do a show of hands on that.
MR. CURRAN: On the matter of Policy Proposal 2006-7, I'm going to ask for a show of hands of all those in favor of abandoning this Policy Proposal. This will remove it from the policy process. I'm going to ask everyone in favor of abandonment, and then everyone -- sorry, Scott?
MR. BRADNER: No, it will not remove it from the policy process.
MR. CURRAN: Correct.
MR. BRADNER: It will give advice to the AC --
MR. CURRAN: Right.
MR. BRADNER: -- who may decide to do so.
MR. CURRAN: You are correct. The illustrious AC is the one that gets to call the decisions, based on the shows of hands that you give them. So on the matter of the abandonment of Policy Proposal 2006-7, please raise your hand if you are in favor of abandonment? Nice and high. Some of you look like you are cleaning your screens; I need it a little higher please. Okay, thank you. All those opposed to the abandonment of Policy Proposal 2006-7, raise your hand? Okay, on the matter of the abandonment of Policy Proposal 2006-7, number of people in the room 125, in favor of abandonment 47, opposed 0. This information will be provided to the AC for their considerations.
NRO NC Report
MR. PLZAK: Sandy George, could you do your presentation now? Okay, going to reorder the agenda because of the nearness to the break. Have the NRO-NC report which would occur first after the break, and instead, we will move the discussion of 2007-24 to the first item of business after the break. Leo, is that acceptable to you? Okay.
MR. GEORGE: Hello, I'm Sandy George, and I'm a native New Mexican. So, welcome -- welcome to New Mexico. (Applause)
MR. GEORGE: Okay. I think everybody pretty much knows this stuff. The NRO NC and the NRO AC, or the ASO AC is 15 members from each RAR. Two elected, one appointed. We move right on. In terms -- the MOU with ICANN, the NRO, the NRO MC, fulfills the responsibilities of the ASO AC. These are all the current members from the five regions. From the ARIN region, there's myself. And I was on the ICANN NomCom for the last two years. Marty Hannigan was on the nominating committee for internal in the AC to pick a board member for ICANN. And Louis Lee was a co-chair on the AC this year. And if you want to be an AC member like Jason -- get elected, get a nomination. You can self nominate, agree to run in the election, or you can -- once every three years you can get appointed by the Board, nominated and selected by the Board. The AC communicates with e-mail operated by the secretariat. This year it's the APNIC. We have face-to-face meetings at least twice a year. We met in Sao Paulo, and Puerto Rico, and then we are going to meet at the ICANN meeting in Los Angeles. We have teleconferences once a month. What do we do? We appoint seats nine and ten of the ICANN Board of Directors. We objectively process RIR- related global policies to find operating procedures for processing these policies, offer guidance to the ICANN board, certify the policies submitted, do process comply with RIR process development policies, and we appoint a representative to the ICANN nominating committee. The process is open and transparent. We have monthly meetings. We have to have a quorum to do any voting. We bash the agenda vote on whether anything that's going on. Meeting minutes are published. There's ICANN and RIR observers there to keep us honest. All procedures are public. And there's our website. We got some new faces. AFRINIC elected Vincent Nagundi who replaced Ali Badiel in January. And Aaron elected Jason to replace me. In the last 6 months we appointed Raimundo Beca to the Board of Directors. Hart McGlazer was appointed to the NomCom for next year. We've been following the potential global policies, and we've organized some outreach workshops in Lisbon and San Juan. In the next six months we are going to meet in Los Angeles. We have our face-to-face meeting there, an ASO Workshop. We are keeping an eye on the two polices that are starting to be processed, and there will be new members like Jason who'll probably come to that ICANN meeting. And thanks to APNIC, they were secretariat for this year. Therese handled all our travel for us, and we really appreciate that. And thanks to the NRO for backing us up, and the PPML for all the discussion on these policies. And, any questions?
MR. CURRAN: Okay. Microphones are open.
MS. ARONSON: I'd like everyone a round of applause for Sandy for his terms on the -- (Applause)
MR. MANNING: So, Sandy, I have a question for you. Red or green?
MR. GEORGE: Green.
MR. MANNING: Okay. (Applause)
MR. CURRAN: Okay. Any other questions for Sandy? Thank you.
MR. PLZAK: Is things ready for the break out back? No, okay. Leo Vegoda. You want to come up and do your presentation now?
MR. VEGODA: Yeah.
IANA Activities Report
MR. PLZAK: Okay. We will now get the IANA report -- activities report by Leo. Pretty soon Leo Bicknell will have the rest of the afternoon for his last proposal. (Laughter)
MR. VEGODA: Hello everyone. I'm Leo Vegoda from ICANN, and that is a picture of our office in Marina Del Rey, which is where I don't work. (Laughter)
MR. VEGODA: I work in our Brussels office, just moved there a couple of months ago. So, this is what I'm talking about today, our wonderful new website, recent number allocations, IPv6, DNS and the new IPv4 registry format. So, this is -- or will be our new website. (off mike).iana.org at the moment. And it looks quite nice. And what we've tried to do is take all the stuff that we have on the old website, make it a little bit easier to find, better to look around. The one thing that is delaying the rollout at the moment, or was, when I last checked, was IDNs. The thing is, as you may have seen on blog.icann.org sometimes web browsers don't display IDNs properly. So what we need to do is we are going to write a little bit of software that will go and take the IDN and turn it into a little picture that we can go and put on our website, so that when people do the WHOIS lookup, they can go and see a little picture of how it ought to be displayed. And that I think was the main reason that it's been delayed a little bit. Obviously, as we approach the ICANN meeting, the urgency increases. So, I'm sure it will be deployed fairly soon. Allocations to RIRs: And you'll notice that the slide is wrong. I almost purposely made it wrong. The main reason the slide is wrong is because it doesn't include the 2 /8s that were allocated to LACNIC a couple of weeks ago. The /8s allocated to LACNIC, they were allocated during the AFRINIC meeting in Durban, if I remember correctly. Other than that, 5 /8s to APNIC in January, and 4 to the RIPE NCC, in 2 -- lots of 2. I'm sure we are making a few more /8s allocations over the next couple of months before the end of the year. Additional to this is 196/8, which was in use by AFRINIC for some time -- in use by them since they've been AFRINIC, but also in use by networks in Africa in the past. 196 has been marked as AFRINIC. Previously it was listed as Various Registries. So, what we've done there is we've just sort of updated our registry to reflect reality. Allocations returned: Well, 46 was returned by BBN, 14 /8s to be returned. We've got one IP address outstanding in that /8, and we are in contact with the organization we believe is the organization that that was assigned to -- sort of. And we are really hoping to get this one back because once it's back, we'll update RFC 3330, along with a couple of other minor little updates, and will mark this as available for allocation to an RIR. So, at some point in the future, maybe, ISP's in this part of the world will be using addresses from 14/8. I've listed 49 and 50 here, not because they were returned this year, but because we changed the status from "returns" to "IANA reserved." I actually think Leslie and Ray negotiated the return of those /8s years go. I can't remember exactly which year. But we sort of updated it this year. And I think because people tend to count the IANA reserve blocks, that's why I've listed them here. So, I've got some breaking news. IPv6 is important. And it must be important, because during the open policy hour, I got an urgent request to go and do some DNS work in IP6 to ARPA so that someone could have some reverse DNS. And the fact that they said that it was urgent, and the request was not exactly -- well it looked like it was rushed. That indicates to me that there are people who have things breaking because there isn't IPv6 reverse DNS. So, although it was obviously a little bit of a shame that they needed to get me out of the open policy hour, it's nice to know that there is some urgent IPv6 networking stuff going on. Also, IPv6 is only used by the politer kind of people or even the smarter kind of people. During the AFRINIC meeting, I was updating the e-mails that we use when we reply to people who complained that they are getting spam's by RFC 1918 -- well, spam by e-mail that comes from RFC 1918 space, or stuff like that. And I realized that none of our e-mails had anything about IPv6 in them, that nothing about, you know, column, column one or ULA space or -- I was like, whoa, maybe I should go and put this in there. So, I thought I should check whether we actually had any abuse complaints ever about any IPv6 addresses, and it turns out we haven't, not one. So, we know that IPv6 is actually used, and it seems to be auto configured on your new Vista install and all sorts of things like that, that the people who are using that are smart enough to recognize that when they see IPv6 traffic, they don't need to complain about it, unlike the people who use our C1918 space, who aren't quite that smart. So, DNS services -- we are actually in the final stages of installing some infrastructure to run some new DNS services. We are going to be running in-addr.arpa, and there's some -- well, we've going to basically be running everything in ARPA apart from the ways that we delegate. And everything that we run, and whether it's ARPA or the INT zone, which is one that we run, it's all going to be DNSSEC signed. Now, if I go to the next slide, yeah. DNSSEC: The deployment is continuing. If you go and have a look at the presentation in that link, Richard Lamb gave a presentation at the last IEPG, and it's got the information about how we are doing the DNSSEC, or if you are going to be at the right meeting in Amsterdam next week, I believe he's giving a slightly updated presentation at the plenary there. And finally, as I put, we've been working on updating the IPv4 registry throughout this year. We want to remove the Various Registries bit. That really just means we don't know -- which isn't really ideal. We'd like to go and put some proper listings in there. We want to point to WHOIS server. We want to make sure that any of the assignments that, if it's a first stop, at least there's a referral to somewhere else, so that when you have an operational issue, and you go and look at the top of the tree, at the IANA registry, you've got a referral to somewhere else where you can actually get the specific points of contact information that you need. So, what we want to make sure that when you need operational information, we are helping you get that operational information. So, any questions?
MR. CURRAN: You can guide them.
MR. VEGODA: Geoff.
MR. HUSTON: Geoff Huston, APNIC. I applaud your move in Various such that the increase in Various then, if you will refer to someway with relevant and up to date WHOIS information regarding the contact block, this seems thoroughly worthy. What are you going to do about the legacy /8s in the cloud class A space? And I think there are few more like 133/8, where at this point there is no relevant WHOIS information anywhere, as far as I can tell. Do you have any proposals as to what you are doing there?
MR. VEGODA: Well, talking with the RIRs about this, we wanted to make sure that there are points as to relevant WHOIS surface.
MR. HUSTON: So you're saying the Legacy/8s in the old A-space would move into RIR administration? I'm trying to understand your statement?
MR. VEGODA: I can see that David is getting out, and as he is senior to me I think I should defer to David, and let him answer. (Laughter)
MR. CURRAN: Mr. Conrad?
MR. CONRAD: Mr. Curran and Mr. Huston and Mr. -- I'm sorry. So, right now we are actually discussing internally how to revise the IPB for registry to reflect the Legacy assignments that have been made in the past. No decision has been made, or can be announced by IANA staff at this point in time.
MR. VEGODA: Now that's so far --
SPEAKER: That's a good answer. (Laughter)
MR. COSTERS: So, Mark Kosters, ARIN, could you go back a couple of slides on the in-addr.arpa thing?
MR. VEGODA: I can try. This one?
MR. COSTERSS: Yeah, so will be DNSSEC signed?
MR. VEGODA: Uh-huh.
MR. COSTERS: I'm curious how -- have you been actually looking at other people's deployments and things that DNSSEC is actually been breaking.
MR. VEGODA: I haven't --
MR. COSTERS: Okay.
MR. VEGODA: -- Richard Lamb is doing our DNSSEC stuff. David? (Laughter)
MR. COSTERS: DNSSEC break something. (Laughter)
MR. CONRAD: We have been definitely deeply involved in discussions with the -- particularly the folks in Sweden who have deployed DNSSEC in the top of the domain. We've also been in discussions with a large number of others. And we are trying to take into account the implications of deploying the DNSSEC. However, the IAB has explicitly directed us to deploy DNSSEC within the ADDR zones that we administer, and until we hear otherwise from the IAB, some say they are the administrative contact for the zone. That is what we shall do.
MR. COSTERS: Okay. I guess it -- in addr.arpa, there's a pretty significant zone, and I would for one hate to see something create some operational problems often doing certain experiment.
MR. VEGODA: You know, the RIPE NCC is been signing their reverse zones for -- well, I can't remember how many years, but I don't remember anyone making any complaints to the DNS working group list the right -- on the right list about making significant problems. I don't know if any of the RIPE NCC people have had -- there's like a couple of them here. Have you had, complaints about DNSSEC breaking reverse look ups? Shall we take silence as agreement with me? (Laughter)
MR. CURRAN: Some want to talk about things that are breaking, please approach the mic?
MR. COSTERS: Obviously, I've been following this from not only interest for many, many years and I've given my life to DNSSEC, but also seen with, see when was actually happening with.SE. And SE is more equivalent to.com which I've gave many years to as well. So it's -- this is a different sort of scenario in that SE, and some of things that SE is hitting or hit in addr.arpa much worse.
MR. CONRAD: I suspect such discussion should probably be raised within the DNS-OP working group. We, you know, if -- as I said, the IABS Directorate has to sign this (off mike) responsible for and if there is some issues that need to be addressed then or of DNSSEC, shock, break something, then perhaps we need to raise -- IANA will need to raise that with the IAB.
MR. CURRAN: Good point, any other comments? Thank you.
MR. VEGODA: Thank you. (Applause)
MR. PLZAK: Thank you, Leo. Well, gee -- through skilled agenda management, we arrived precisely at the time for the break. So I think I've got -- got a run-through the usual slides, CyberCafé, you guys -- last chance to win a little one, so that if are a loser, you can qualify for the big one. (Laughter)
MR. PLZAK: Help Desks are there. Hey, the Advisory Council was been talking about this desk, and they think it's a neat idea, if you haven't been by to see them, please do so. And refreshments are available in the foyer. We will see you in precisely 15 minutes. (Recess)
2007-24: IPv6 Assignment Guidelines
MR. PLZAK: Let's get started. We're on Policy Proposal 2007-24: IPv6 Assignment Guidelines. Huh? Yeah, go ahead. Hello? AC and Board members, I think there are a few of you who are absent, duly noted by the Chair. Okay, there are speakers out there. So -- wow, but they're not working. Anyway, Policy Proposal 2007-24: IPv6 Assignment Guidelines. Was introduced in August of 2007, and designated a formal proposal in September 2007. This is its first discussion. "ARIN staff understands that this proposal would replace 188.8.131.52. Instead of the assignment size being a decision of the LIR or ISP, the actual prefix to be assigned would be based on a subnet count." The AC shepherds are Ron and Stacy. "Prior to being a formal proposal there were about 94 posts by 30 people, with some in favor and some against earlier versions." Since this proposal is a -- excuse me -- designation as a formal proposal, there were 6 posts by 4 people, one for, none against, exemplar comment shown. Counsel finds no legal liability. Staff comments: "Currently there have been 54 IPv6 reassignments, reallocations larger than /48 made by ISPs to the customers. The staff is expected to review each and every one larger than /48. This could significantly increase workload and turnaround times. "If staff is expected to review all reassignments larger than /48, should this be done at the time the reassignment is made, or at the time the organization is requesting additional IPv6 space from ARIN?" Manual changes shown: In implementation assessment -- moderate impact 3 to 6 months after the Board ratifies it. Some requirements -- we have to update the guidelines, we'll need to train staff, there'll be some text changes to the templates. The biggie is "Sustaining this activity could require the need for additional staff and associated costs." So, I believe Leo, you're back up. (Pause) (Discussion off the record)
MR. BICKNELL: I am Leo Bicknell again. This one is also co-authored by Ed Lewis of Neustar, who gave me some wonderful feedback after the first iteration of this policy. Kindly go through the current issues here -- this again has some fallout from proposal 2005-8. Gee, we got that one wrong, didn't we? It was actually a good proposal, we just missed a few things. It allowed /64, 56s and 48s -- lot of the discussion we had earlier, and I put in a quote from it. That proposal specifically said many references to /48 will need to be replaced by (off mike) assignment. I think we were here earlier. And there's no criteria for ARIN to review if a site needs more than a /48, but the current policy requires ARIN to do a review. So if you all can read this -- probably not -- please open your packet. I would like to hear some paper rustling. This is section 184.108.40.206 -- because you're never going to read it on the screen. I tried to figure out how to format the slides so you could read it and it's just not possible. It's a very long section, it's a very rambling section, it has in it a lot of stuff that's not policy, that is recommendations, that's superfluous text, that's some Iliads and sonnets about who knows what. But please make sure you have the paper in front of you, so you know what we're talking about. So, specifically let's talk about the new text, what I want to replace all of that it. And this is where Ed gave me a lot of support in helping to kind of craft a better bit of text here, so I'll just read it. "Assignments by an LIR, /48 or smaller, will not be reviewed by ARIN. Assignments greater than /48 -- and I realize RS's language thing here, so I will reread that as, assignments shorter than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment lowering the overall utilization of the LIR. And I'm going to come back to a couple of details on that, because I think, you know, Ed kind of set me straight on some of the language, but I think we managed to confuse the staff again because we got the staff assessment and as Ray already pointed out, there are two principal concerns that need to be addressed. So, let's look at staff concern number one. The existing text is up on the screen. This should match what's in your packet, I hope. The yellow emphasis is my own. The existing text has that request for multiple or additional /48s will be processed and reviewed at the RIR/NIR level. We don't have NIRs so that's the RIR level. My interpretation of this text is, if you want to assign a block larger than a /48 to your downstream, you have to run to ARIN and get explicit permission first, and staff must review every single one of them. Other people have some different interpretations -- that is mine -- and thereafter (off mike) according to staff, 58 assignments, SWIPs larger than /48, and I got them to dig up a couple of numbers for me, if you care, there's what they are. So, I kind of asked the question, what criteria was used? Where they reviewed at the time of allocation, or will they be reviewed when the ISP returns for more space? And staff, feel free to correct me if I'm wrong, but the answer I got was, where these were used to justify the initial allocation -- so where they were in someone's original plan, they were reviewed. But if somebody simply submitted a SWIP template later, saying, hey, I allocated a /40 and SWIP template went in and no one reviewed it. So, my take here is what's actually being written in the text today is not being done. Staff concern number 2 -- oh, so the point of that, actually if I can backup just half a second, my point of that is the concern that staff raised was that they would have to review all of these. And my contention is, they really should be reviewing them all now, based on the text. So, you know, I think what you'll find is as we go a little further here is, this is going to be an improvement, but that's how I address staff concern number one. So staff concern number two, I think does necessitate a little change and I may get some advice here from the chair. This is the text as proposed that is on the website and has gone out and staff's concern was basically that this is going to require them to review all of these. Which again, I would actually submit is what the current text requires and I think that is wrong. So there's this wonderful little word in the middle there, "will". And I think that is the cause of the problem and so I'm actually suggesting that that little word be changed to the little word "can", so it is permissive. And this is because if you go look on the mailing list, the intention here was basically to mirror IPv4 policy. In v4, as we're all familiar, you come back to ARIN and you ask for more space and they may ask you for some details in your current block, depending on how good your documentation is and whether it's Tuesday or not, they may ask you for every single last one of them. They may ask you for two or three and say that's good enough. They have some discretion in the matter and they seem to do a real good job at that. Now the intention in IPv6 was to provide the same level of discretion. When you come back and ask for a new IPv6 block, they may ask you for all of them, they may ask you for a smattering, whatever they feel is appropriate. They have the ability to do the review. So, let's look at the goals of this policy. The first one is, today, there is no real official way to justify a block larger than a /48. So if you are an ISP and you really think your downstream customer needs a /40 the policy just says, well, justify that and gives you no guidelines or anything else again. So, this provides a mechanism where you can do that again with an HD ratio of.94 because it's believed that was the intended standard all along. We can kind of have that debate again if we need to. We -- this policy also clarifies that staff should check those not in real time, but rather spot check them at appropriate times. So, in essence the /48 boundary would be treated very much like the /29 boundary in IPv4, right? If you're allocated /29 and you come back to ARIN and there's a SWIP end for it in for at (off mike) -- you're allocated to 29 and you SWIPed it. They don't go, well, for that 29 we're going to need a network map and post counts, and your firstborn child and whatever else they ask for it. But if it's bigger than that, they may ask you those questions. So, this clarifies where ISPs are going to need to keep detailed records and where submitting a SWIP and saying, you know, the I assigned space to Leo is good enough. This provides some clarity of what I believe is the policy today, as staff implements it, but some ISPs have raised questions and that is, that ARIN will not second guess allocations longer than the /48 boundary as was essentially designed from the original IPv6 policy. So, if you've assigned a /48 to your customers, ARIN isn't going to come back years from now and go, you know what, that customer really could have done with a /56. And we think that's in line with the IPv6 policy. Again, provides that you may need to keep detailed records for larger blocks and remove vague guidelines from the NRPM. On PPML, there was one post in support after the revision. I really hope that means that we did a really good job of the revision and made every one happy. However I have a feeling in a minute the mics are going to be flooded, so probably wasn't the case, so once again I would ask that you please step up to the mic, or post on PPML so that the AC has your input. So, there is the updated proposal and that's where I'll defer to the chair if we need to discuss the update or not.
MR. CURRAN: Okay, so as the Policy Proposal author, you have the right to change the proposal, but we also have to respect the (off mike) because we have a set of public comments and we have a set of membership here, who has been looking at a different text all this time. So, I actually need to hear from anyone who objects to this change of the proposal before we talk about anything else. If you object to this change from "will" to "can" for this proposal, please step to the mics. If you don't, step back from the mics. Okay, right rear, first, go ahead.
MS. ARONSON: Can you just go back? There was a slide that said something about longer than a /48.
MR. BICKNELL: Yeah, I have a feeling I greatly offended RS here.
MS. ARONSON: No, but -- no, it -- yeah, it --
MR. BICKNELL: That one?
MS. ARONSON: That one. It said, can't second guess allocations or prefixes longer than a /48. That doesn't include a /48, but your comment did.
MR. BICKNELL: You're correct. That is a poor use of English on my part. It should be --
MR. CURRAN: /48 or longer.
MR. BICKNELL: Yeah, /48 or longer.
MS. ARONSON: Okay, okay. Just checking.
MR. CURRAN: Okay, clarification. Okay, on the topic of changing the policy from "will" to "can", all I'm seeking comments on. Center-rear microphone?
MR. DUL: Andrew Dul, Perkins Coie. In the IPv6 land, I would expect ARIN to review every reassignment of /47 or smaller.
MR. CURRAN: The (off mike) do you object to that?
MR. BICKNELL: Front microphone, Thomas.
MR. NARTEN: Yeah, Thomas Narten here. I object to that and the reason for that is, if you change that from "will", which means you're supposed to be doing it now, to "can" which means you could if chose to, but if you didn't, nothing bad would happen, in effect we would stop doing so.
MR. CURRAN: Okay.
MR. NARTEN: And the purpose of the original wording which we could revisit was that we don't have experience with larger than /48 and we'd like to have a sort of a central place where they are reviewed and get some feedback and then once we have that we should may be consider changing the policy of doing things differently.
MR. CURRAN: Okay, so -- yeah, go ahead.
MR. BICKNELL: I'd like to make two comments on that. One is the permissive language is in the v4 policy today and I believe the experience of everyone in this room is, ARIN at least asked you a question or two, in your review, so I don't think there's really any danger that they are going to completely ignore this. The second thing that I would say -- and I don't have a lot of details on this, we may need staff or someone else to provide them -- there have been allocations larger than this so, while may be not of a lot of experience, we finally have some. The predominant number of those allocations, as has been explained to me, is -- I believe it's the Internet2 group -- I don't even know if it's a nonprofit or what it is, received a /32 and has been SWIPing /40s to universities, rather than those universities come and get their own /32 from ARIN. Now whether or not you just consider that a good thing that's -- that's an example of what's being done here. They are rolling up under Internet2 and sort of getting their own individual space. So those are the kind of things we have some operational experience with.
MR. CURRAN: Okay, so if you're speaking about this topic of the change from "will" to "can", please remain at the microphones. Step back otherwise, and I'll understand. Center rear, yes.
MR. SCHULTZ: Rich Schultz, Tellme networks. I would suggest that you use the word "may" instead of "can", because "can" can be a little ambiguous in whether it's just the ability to do it, versus the authority to do it. (Applause)
MR. CURRAN: Okay, so you're against this change?
MR. SCHULTZ: If it's the use of "can" instead of "may," yes, I am.
MR. CURRAN: Okay, I want to be very clear. Rear microphone, yes.
MR. SCHILLER: Jason Schiller, UUNET, Verizon Business. I need some clarity on what this text actually means. Is this an appropriate time to ask for clarity? Because it's germane to the change of "can".
MR. BICKNELL: I'm sorry?
MR. SCHILLER: I need some clarity on what this text means. Is this an appropriate time to ask that?
MR. CURRAN: Sure.
MR. SCHILLER: Okay, so, the way I read the current policy and I think the way Leo reads the current policy, the requirement is, if I want to assign larger than a /48 to one of my customers, I have to get ARIN approval. The way I read the text in the packet, which is different and I think the text on the screen also has the same problem -- the way I read it, basically what happens is, I can assign any size block I want to my customer until I come back to get more IP space in which case ARIN will assess whether or not on meeting my HD ratio, I need more space. Is that correct?
MR. BICKNELL: I think that's a bit of a twisting of it, and this is where Ed and I went back and forth on language. So, technically, today, in IPv4, if we go back to what people are familiar with, if ARIN were to give you a /16 and you were to give a customer that needed one IP address a /18 out of it, completely unjustified, ARIN wouldn't ask any questions about that, until you returned for your next block. And in this case we're attempting to duplicate that situation. Whether that's good, bad, or indifferent, I'm not really sure. I feel it's what people are used to so that seems like the appropriate time, and in particular I think staff provided me some ammunition I didn't know I had. I think having to ask "Mother, may I?" to ARIN first is a huge burden on ISP and ARIN, and it sounds like it's such a large burden that ARIN's ignoring that requirement. So, that may be the ultimate justification for that.
MR. CURRAN: So, let's -- I want to be clear. Leslie, at present have we had circumstances where these were to have been reviewed, and might not have been reviewed?
MS. NOBILE: We do not currently review any reassignments of IPv6. We automatically allow them to be processed through, so that may be a requirement in the policy, but it's not something we have applied to date.
MR. CURRAN: Okay.
MR. SCHILLER: Point of information.
MR. CURRAN: Recognized, wherever you are.
MR. BICKNELL: Jason, again.
MR. SCHILLER: Yeah, Jason, again --
MR. CURRAN: Okay, I'm sorry.
MR. SCHILLER: Is the reason why they are not being reviewed because there are no clear guidelines or some other reason?
MS. NOBILE: There are no clear guidelines and in fact, I don't believe any of the RIRs are actually reviewing reassignments and that is the reason; no guidelines.
MR. CURRAN: Okay, thank you. So, does that clarify your question?
MR. SCHILLER: Yes.
MR. CURRAN: Are you for or against the change from "will" to "can"?
MR. SCHILLER: I prefer "will", but I think I'm going to be against the policy anyway, and it doesn't matter.
MR. CURRAN: You would support the policy either way but --
MR. SCHILLER: I would not support the policy either way.
MR. CURRAN: -- but you would prefer -- you would not support the policy either way. Okay, that answers the question.
MR. SCHILLER: But I would prefer "will" over "can". (Laughter)
MR. CURRAN: In case it passes, despite your lack of support, you prefer to see "will"?
MR. SCHILLER: Correct.
MR. CURRAN: Thank you. Oh, and front microphone?
MR. DELONG: Owen Delong, JITTR Networks. I like sticking with "will" for the time being. I don't support the change to "can". Briefly, I do support the policy either way, but I would prefer "will" and I would prefer that we had criteria by which Leslie could review these and her staff.
MR. CURRAN: Okay.
MR. DELONG: And that we be reviewing them.
MR. CURRAN: Good to hear. Anybody else want to speak in favor of the change? To change this to "can" from "will"? (Laughter)
MR. CURRAN: Anyone else? Okay, there's not a lot of community consensus on the change, it's your call.
MR. BICKNELL: I am happy to go back. Let me see if I have a slide with that on it.
MR. CURRAN: There we go. So we -- maintaining the Policy Proposal I believe as written in --
SPEAKER: As in the packet.
MR. CURRAN: -- as in the packet, I'd like to now discuss the actual proposal. Okay, people who want to discuss this Policy Proposal please approach the microphones. Front center.
MR. DICKSON: Brian Dickson with Afilias. I have concern about the implicit policy where we list /48 or smaller. I believe that will encourage the proliferation of assignments of /48 size for the same reason that class C's were being given out with every T1 in the early days of the Internet. I don't believe this is a particularly wise long-term decision. If we burn through lots of /48s, we'll end up in a very similar situation of having more and more ISPs coming back to get additional assignments and I don't think that is good for the long term growth of the DFZ. I would prefer to see a range in the /48 to /64 of -- may be reviewed and /64 or smaller not be reviewed.
MR. BICKNELL: For what it's worth the text -- and Leslie can tell me if her interpretation is different. My belief is that one sentence, that /48 and smaller will not be reviewed, is exactly the same as the current policy's interpretation, except the current policy is about six paragraphs long, but that is how ARIN interprets the current policy.
MR. DICKSON: And I'm proposing that -- or suggesting that making a change to the policy, since we're discussing a policy change, along those lines is warranted.
MR. BICKNELL: That's fine. This was viewed more as cleanup than policy change, but --
MR. CURRAN: Okay. Microphones remain open. Center rear.
MR. SCHILLER: Jason Schiller, UUNET, Verizon Business. So the concern that I was alluding to earlier is that in the current policy if you want to give an assignment larger than a /48, you have to get the ARIN approval. Now, I understand that's not being done because they don't have clear guidelines; yes, let's please give them clear guidelines. My concern is that for a small ISP a /32 might be a lot of space, so much space that they might not ever come back for another assignment, in which case there is -- ARIN really has no oversight to prevent people from giving out huge chunks of address space to customers. So that's my concern and that's why I think I'm leaning towards against this change.
MR. CURRAN: Okay. People who want to speak about this Policy Proposal approach the mics. Front microphone.
MR. LEIBRAND: Scott Leibrand, Internap. I support the Policy Proposal. With regards to Jason's concern, I'm not quite sure why it's a problem to give out your IP space if you're never going to come back for more. I think the reason that we have this review policy is to ensure that someone doesn't burn through all their IP space and go back and get more and burn through all that and go back and get more. If they are being completely wasteful -- I mean, /48 is huge, but if they're being wasteful, we don't want them to be able to keep getting more space from the RIRs. So I'm not sure why it would be a concern that an ISP with a /32 gives out 200 /40s or whatever. So I support the policy as is and would love to hear more clarification as to why others object to it.
MR. BICKNELL: For what it's worth, my comment to you and Jason both would be I actually agree with Jason that that is a potential problem. I simply feel it is orthogonal with this policy. I think at this time it's more important that large ISPs like Internet2 who are making legitimate assignments of /40 have a solid policy to fall back on and know what records they will be expected to produce to ARIN when they need more. And that Jason has produced a legitimate problem that should be fixed orthogonal of this in a separate policy. That's just my personal view.
MR. CURRAN: Okay. Are you still at the microphone? Okay. Thomas.
MR. NARTEN: Thomas Narten. So I have actually two things I'd like to raise. One is I understand the desire at some level to keep things simple for example and not have ISPs need to go back to ARIN regularly and tell it they really need more space. But I think that we also by doing that we are running the risk of setting up the proverbial train wreck, in the sense of if you have an ISP that's giving out space and doesn't talk to ARIN for 3, 4, 5, 6, 7, 8, years and then goes back for more space, and their internal records are a mess, what they've done is a mess because there have been no sort of paying attention to the details of what they are doing and making sure they're really doing appropriate things. Now, one position might be like, well, that's their tough luck, they'll pay for it. But on the other hand, that's not really what I consider good stewardship of the address space, okay? The second point that I actually wanted to raise is -- we haven't really talked about this at all, is I think I generally support this text here. I see where it's going and it's really another example of use the HD ratio which is consistent with what the overall theme is. But your -- you also propose I believe to pull out an entire section of text, which is like five paragraphs long and I don't understand why that text is problematic or needs to be removed.
MR. BICKNELL: So where this originally came from and the reason we reviewed it is several AC members and a board member at least and a couple other people read it, and their reaction to that text was all the same. There is no policy here; there is nothing ARIN staff can implement. So that's why it seems like it shouldn't be in the policy manual. It's very nice text, but it's like putting the text of Alice in Wonderland in the thing. It doesn't make it useful from a policy perspective.
MR. NARTEN: And one response I have to that is the reason that text is there is to provide context. And one of the problems that we have here generally is that if you just want the policy to be succinct and narrow, there's no place to put the context in the additional text that, you know, fills the blank for the people that don't get it right off the bat. So for example there is text in there that makes sort of a suggestion that if you are an LIR, you know, give a /64 for this case, or maybe a /56 in this case, or a /48 in this case. However, it is your decision. That's the policy essentially, it's your decision. But without that kind of guidance, there is -- other people feel more -- you know, less comfortable in the sense that there is no guidance to the LIR at all on what to do.
MR. BICKNELL: Well, and I think that goes into your first point on the record keeping. Today, the ISP has absolutely zero guidance on record keeping. I think actually that creates a bigger train wreck 5 or 7 years from now. Today we don't tell them what records they need to keep, we don't tell them what questions we're going to ask them, and things like that don't even get them a firm guidance on how ARIN's going to look at what they've done, whereas this policy clearly sets a line in the sand saying on this side of the line we're going to ask for X and on the other side of the line we're going to ask for Y. So it's much easier for the ISP to keep the proper records and to have them 5 or 7 years from now.
MR. CURRAN: You are -- are you -- does that answer you, Thomas? Okay. As written, would you support the Policy Proposal?
MR. NARTEN: No.
MR. CURRAN: Okay. Thank you. One --
MR. BRADNER: John, I want to follow up on --
MR. CURRAN: Go ahead, Scott.
MR. BRADNER: Scott Bradner, Board. The Board has recognized that there is a problem in the policy -- the policies that are listed of lack of context, as Thomas was just referring to, and has asked the staff to develop a annotated version, as it might say, to bring in some of that context, both of the policy and the policy process to try and make it clearer what's trying to be done here and why, rather than just the pithy little "This is the policy." So thank you, Thomas. That is a recognized issue.
MR. CURRAN: Right, and following up on an earlier matter of the same point, there are cross- references in the online version if you go online and get it, but you've got to find the cross reference and then read the Policy Proposal to get that context. So we're trying to figure out how to put that all together so the cross references and the contexts are with the Policy Proposal, the actual approved policy manual. Okay, front, yes.
MR. CHENDI: Sonny from APNIC. I just want to clarify Leslie's comment. We do have a second opinion in our region, we do verify greater than /48 assignments made to customers by the LIRs, and if they don't submit, we review that when they come for additional resources. Thank you.
MR. CURRAN: Okay, good information. Back rear microphone.
MR. DUL: Andrew Dul, Perkins Coie. I was talking with Jason trying to figure out why he was against this policy. I think he wants assignments reviewed that are shorter than /48 or /47 and shorter. So I propose that you add after the 0.94 HD ratio policy, the phrase "at the time of reassignment" to clear up the confusion of when the review would be done.
MR. BICKNELL: There was a reason we didn't add that text, and this came up on the mailing list. I believe Scott actually asked when should this be done and while my intention is that normally this would be done at the time of renewal, that's the most likely time, I did not want to put that text in and make it so ARIN staff could not also do it at the time of audit, from our previous discussion. So you know, I'm not quite sure what you do with the language there.
MR. DUL: Add the word "initially." "Initially at the time of reassignment."
MR. CURRAN: Okay. Center rear.
MS. SCHILLER: Not that I mind, but he was there first.
MR. CURRAN: Oh, I'm sorry, it didn't ring. Front right microphone.
MR. DICKSON: Brian Dickson from Afilias. I just wanted to reemphasize the concern over the context. I think the -- just to reemphasize that the policy manual, while it is giving direction to ARIN staff, it is very important that the wider community, who are the customers, the members, have that full context in terms of the intent and that one of the intents of the IPv6 policy, if not stated, should be stated to minimize the likelihood of anybody having to come back to get more address space. So internal conservation in terms of members assigning space to their customers should be done with the intent of net ever needing to go back or rarely needing to go back to get additional address space.
MR. BICKNELL: As a point of history if you want to look it up on the website, the first version of this policy before it was assigned the formal numbers, so you'll have to find it by name, I proposed using a.25 HD ratio for assignments from /48 to /64 so that there would be some requirement and it would be -- in mind a.25 HD ratio is an amazingly liberal one. For those of you who can't do logarithms in your head, that requires 16 subnets in use, day one, to justify all 65,000 subnets. And so that's a very liberal bar. And if you saw from the staff assessment page where they may have the exact number, I believe there were 60, and it may be approaching 80 comments that flooded in with people immediately saying absolutely no way, you must change it back to a /48 only. We will not accept the HD ratio on this, this is the worst idea ever, which is why we ended up with this text again.
MR. CURRAN: Okay. Center rear microphone. Heather.
MS. SCHILLER: Heather Schiller, UUNET, Verizon Business. I am in favor of this policy. However, I would like to say that I don't think that it gives enough help to ARIN staff for why they are not currently reviewing /48 and larger assignments. So it tells them how to handle the address space if someone assigned something larger, which is great, because it's a step in the right direction, but it doesn't tell them -- it doesn't -- it tells them that they should be reviewing it but it doesn't give them the guidelines for what they should be reviewing on. And so that's just maybe a point of -- something that we should work on further.
MR. CURRAN: Okay. Other people who want to speak in favor or are opposed to this Policy Proposal as written. Marla.
MS. AZINGER: Marla Azinger, Frontier Communications. I'm about to lose the mic, sorry. I don't know if this is hot or not, sorry. I'm sitting on the fence because I kind of feel like we know we have a problem where the staff -- ARIN staff doesn't have guidance as to what they are supposed to be reviewing. However, the original intent of it was so that we monitor what we're doing right now because it's a new way of addressing. Hex blows people's minds, and we don't know how people are actually going to responsibly or irresponsibly manage it. So that intent was so that we could monitor that. So that's why I kind of question how we're going about this. The other problem being the /48 named in there because there are other people in the group that don't think that would be a correct size and that maybe you want to look at even more specific subnet sizes and how they are justifying them, be it when they go back for more or beforehand. I had one more point, sorry. I know I lost it, sorry, I didn't -- I had another down, but I had another one. So I guess I'm leaning more towards not supporting that right now because I think we're kind of going about it the wrong way.
MR. CURRAN: So you would say you are against the Policy Proposal?
MS. AZINGER: Yes, I guess I would.
MR. CURRAN: Okay, very good. Okay, at the mics -- are there two people there? Just trying to check. And Thomas, are you at the mic or are you back? I can't tell sometimes. Okay, go Thomas.
MR. NARTEN: Yeah, just a follow-up again on the point that Marla also raised. The original -- one of the original motivations for this text was to gain experience on what's actually happening. And Leo said we do have experience. Now, the missing point -- the pieces missing here is what is that experience, can we -- where do we actually learn from that experience that what we're doing is right, you know, provide guidance to ARIN staff, and if appropriate at some point, loosen the restrictions saying we now know enough about what we're doing to tell the LIRs, here is what we should be doing in this context and here is what ARIN will do when you come back to justify, you know, future allocations.
MR. BICKNELL: I think there is a two-part problem, so the part one of the problem that I think rather urgently needs to be addressed is that yes, we are gaining experience with these larger allocations, but they are being made with no rule. So in fact it's quite possible that -- some people in this room seem to want to change the rules that, you know, I don't know what they use to justify a /40 today, I don't know if they just assumed the.94 HD ratio was a good measure or if they sat around over beers and said, hey, 40 sounds real good. But I suspect those are being made without any knowledge that that's going to be a good size in the future. And on the education front the question that I would ask -- and I would ask this whether this Policy Proposal passes or not, is how are we supposed to get that information back to the community, because clearly ARIN staff has SWIPs in their database. It kind of sounds like to me those probably came in from automated templates that were never even reviewed by a person. So how do we take that and learn something from it and get it back to the community so they then can make policy? I'm not seeing a path there myself.
MR. CURRAN: That's a good question. Okay. Far right microphone.
MR. LEIBRAND: Scott Leibrand, Internap. Inquiry, I seem to get the impression from the authors that this is intended to be -- when this is supposed to be viewed, it's intended to be vague to allow ARIN discretion. First up, is that correct, and if so, what does ARIN staff -- what's ARIN's staff's interpretation of when they might actually do these reviews, at the time of SWIPs in middle, at the time of review at the time of renewal?
MR. BICKNELL: I would use the word "permissive" instead of "vague." But --
MR. LEIBRAND: Okay. So let me ask the question, point of inquiry, if this language is adopted, Leslie, which says that assignments greater than /48 will be reviewed to see if additional space -- the additional space is warranted according to the.94 HD ratio policy, when would staff do that review?
MS. NOBILE: It looks like at the time of reassignment, that's what it appears to be to us. That's why we asked for clarification in the staff comments.
MR. CURRAN: Okay.
MS. NOBILE: It looks like that.
MR. CURRAN: That would be how it is interpreted if it moves forward.
SPEAKER: Subsequent --
MR. CURRAN: Leslie, do you want -- someone just said something and I didn't hear it.
SPEAKER: I don't know --
MS. TAYLOR: Subsequent assignments, right, not reassignment?
MS. TAYLOR: For additional assignments?
SPEAKER: No, that's not what she --
MS. TAYLOR: Initial. The policy appears to be for all initial reassignments, is that correct, that's what you're purporting here, right?
MR. BICKNELL: If I'm understanding Stacy correct and I'm not a 100 percent sure I am, I think yes, all of the above. If you have no v6 space and you come to ARIN with a plan and your plan includes blocks that are shorter than a /48, this would apply. If you apply for a second IPv6 block, you come back more and have already made assignments for allocation shorter than a /48. This would apply. If ARIN gets an e-mail that you are fraudulently assigning IP space and decides that you really need an audit because you've been a bad, bad girl, then this would apply.
MS. TAYLOR: Yes.
MR. LEIBRAND: But what I just heard Leslie say -- this is Scott again, is that it would be done at the time of reassignment, which is to say the time at which you submit the SWIP template.
MS. NOBILE: Exactly. I have to admit that I'm very confused by what this actually means right now. The currently policy says -- just let me -- hear me out. The current policy says the RIR is not concerned with reassignment size from an ISP to their customer, the initial. It says on a subsequent we should be monitoring anything larger than a /48. So a subsequent reassignment to a customer. We're not doing either, I have to admit, but --
MR. BICKNELL: That's -- I've got to go back here myself and I don't know if I can read it in the small text. We'll see.
MR. CURRAN: Authors are conferring. Well -- yeah. Right, so my interpretation of the existing text on the left, and maybe somebody with a packet who can read it in full size can do a better job than me, is that for a -- in fact I think I can read the text here. Note there, when a single site -- when a single end site requires an additional /48 address block, and that to me is vague. I would interpret that as -- if you're assigning them two off the bat, a /47 or if you are assigning them a second one, you gave them one and 6 months later gave them another, but I admit that's vague. It must request the assignment with documentation or materials that fully justify the request, no requirement other than justified, request for multiple -- oh, here we go, request for multiple or additional /48s will be processed and reviewed at the RIR level. So multiple or additional. So to me a /47 is multiple /48s right, it's two of them, at least that's my reading of the policy.
MR. LEIBRAND: So my point of inquiry is not quite settled, but I think we're getting close. So it sounds like the policy authors' intent is that this could be reviewed at time of initial allocation, at time of reassignment of /47 or greater, at time of request for additional allocation, another /32, any of the above, and ARIN staff is saying that they would at least do it at the time of /47 or larger reassignment. Is that accurate?
MR. CURRAN: I believe that's correct.
SPEAKER: Believe so, yes.
MR. BICKNELL: And I would phrase our intention -- and I'll speak for Ed here, I think our intention was to make this work as much as possible like the /29 boundary in IPv4 as we could. Our goal is to kind of duplicate that operational experience.
MS. AZINGER: I think that's the problem.
MR. CURRAN: Okay, one by one, does that clarify your point, and given that, are you in favor or opposed to the proposal?
MR. LEIBRAND: I am still in favor of the proposal. The /29 boundary, as I understand it, is never -- if I SWIP something to a customer, ARIN never second- guesses until I go back for more space. So I think we're doing a little bit different than that in that since we are doing -- we are so new in this, ARIN will at least look at the /40 reassignments and sanity check them and if they think it's wonky they'll go to you and say what are you doing. But that's not a requirement in the policy. It might be an operational procedure.
MR. BICKNELL: I think Leslie has added one that it may occur at the time of SWIP in IPv6. I would say the /29 in v4 also applies to that initial assignment if you came to them having no space with an initial plan and it listed /29s, again you're not going to have to provide a network diagram, blah, blah, blah for your /29s. So it's not just a subsequent request, it's an initial one as well, but point taken.
MR. CURRAN: Okay. So does that answer your question? Yes. Rear -- center rear.
MS. AZINGER: Marla Azinger, Frontier Communications. I think that's where the confusion comes in and that's really what I consider the problem. We have a current text and you're changing the complete intent, and the intent was so we could monitor what was going on and already we have discovered and the ARIN staff may have not had to get involved, but there are companies that started assigning by /48s and realized what the hell are we doing, that's a complete waste, and they can manage their space a lot better. So they already started renumbering and just more specific subnets. The intent was to help people monitor -- and yeah, we'd probably change this policy going on down the road once we -- we know everybody kind of has an idea of what's going on. And yes, I know some people have experience, but overall, and especially, in the North American region, we don't -- we do not have as much experience as Europe or any other RIR. So if the intent -- if people here don't like the intent of us trying to help manage the space correctly, then yeah, you probably want to vote for this because this changes the complete intent.
MR. CURRAN: Okay. Microphones still open. Far right.
MR. DICKSON: Brian Dickson with Afilias. Actually to follow up on the previous comment, I think that cuts to the quick on the issue, which is are we merely providing rules to be enforced or are we providing guidance and feedback to the community? And given the relative early stages of what we are doing, I think there may be a couple of different ways we want to approach this. So I'm getting way off topic in terms of this. Based on my understanding I would not be in favor of the proposal as written. I would like to express the reasoning behind that if you give me a minute. I would say that what we want to be doing is monitoring the actual assignments that are being done regardless of length, which means that we should be allowing and encouraging all assignments to end sites, not end users, module of the actual privacy concerns. And to have a group of knowledgeable people monitoring those actual assignments to be able to provide assistance to those who may not realize that they are going against the intent of effective use of the space. You can go with the argument of somebody who is clearly clueful like Randy, giving away out of his /32 a /34. If he knows what he is doing that makes sense. But if you have some new ISP who's just gotten his IPv6 space, a /32, and starts giving out /48s, while it's allowable under the policy, I think it would be highly beneficial to the community as a whole to communicate with that party and encourage them to choose a slightly different policy for allocations.
MR. CURRAN: Okay. That's the type of thing that you should make a Policy Proposal out of and send in.
MR. BICKNELL: And I will point out this does not change the fact that ISPs still will have to enter their assignments in SWIP, and so if the community would like to download them and bulk WHOIS and e-mail them that you should be giving out /56s instead of /48, this doesn't change that.
MR. DICKSON: I would like to see explicit text added into this, to that -- a point of question --
MR. CURRAN: Sure.
MR. DICKSON: For -- this may not be the first time I've had a suggestion. At what point should suggestions be directly addressed as a formal proposal to the author which should get a straw poll?
MR. CURRAN: You come find the author at anytime you want and he can amend this proposal, or if you want to submit an additional Policy Proposal, you put it into the process. The AC knows how to combine them if they need to.
MR. DICKSON: Okay, so from the floor I would like to suggest the change to the text on the "/48s or smaller" to be to "/64s or smaller."
MR. CURRAN: Do you want that change?
MR. BICKNELL: No, I'm not interested in that change. The motivation for this policy was cleanup, as it was in the first one, and my intent here was not to change any policy but just to clarify it. So anything that makes a significant change I'm certainly not interested in.
MR. CURRAN: You need to submit a Policy Proposal if you want that to happen.
MR. DICKSON: Okay. A second question then regarding the text of the proposal. The original text was for additional assignments or reassignments of /40 or longer. I would like to see the word "additional" applied to those assignments. So additional assignments, /48 or smaller.
MR. CURRAN: So that's the first sentence, the first word.
MR. DICKSON: Second sentence, first word. Well, both of those.
MR. BICKNELL: Yeah, the additional policy is for additional /48s and let me ask it this way, is the phraseology additional "/48" and the phraseology "prefixes of length /48 and shorter" the same thing or not?
MR. DICKSON: They are not. /47 and shorter would be the similar but any assignment, any initial assignment of any size, I would under the previous or the existing text be permitted with a required review. That's what I believe should be the case and that only additional assignments should require review.
MR. CURRAN: Your call. Do you want that change?
MR. BICKNELL: No.
MR. CURRAN: Okay.
MR. BICKNELL: I'm not quite sure I fully get it, but --
MR. CURRAN: Understood. All right, people who want to speak?
SPEAKER: (Off mike)
MR. CURRAN: That's something that would be best discussed between you and him outside the policy --
MR. BICKNELL: I have some inklings that -- for the general reason before, this is supposed to be cleanup. I'm not --
MR. CURRAN: Again --
MR. BICKNELL: -- even if I understood it, so --
MR. CURRAN: There are people who have seen this Policy Proposal who are outside the community, who are busy participating remotely or have already put PPML comments in it. So if it's a substantial change, it's something that unless the author wants it, it's something you're going to have to take up individually. Center rear.
MS. SCHILLER: Heather Schiller, UUNET, Verizon Business. I draw -- liken this policy to the one in v4 that requires that assignments that are /19 or /18 or larger to be reviewed and approved by ARIN, okay. So if you want to assign a /47 or larger, it's the same as assigning a /19 or an /18 where you have to get approval -- or review by ARIN. The policy text for v4 doesn't outline any set of guidelines for ARIN staff about how to do that review. And so I don't know whether in v4 they are doing those reviews or not, but what I would ask if the goal is to clarify -- really what I want to know is why isn't ARIN staff doing this now and they are saying that they are not doing it because they don't have guidelines. They don't have guidelines in v4 either. And I'm still in favor of this change because it at least tells ARIN staff how to handle address space when someone assigns larger than a /48.
MR. BICKNELL: Before we --
MR. CURRAN: Go ahead.
MR. BICKNELL: Before we have staff respond, that's an excellent point. I had completely forgotten about that at the podium. In v4, we had this /19 and larger wall and the /29 and larger wall and in essence what this policy does in v6 is bring them both together so there is no middle space with the /48. So that may help clarify to people in the room what's actually happening here. And then I think your question to staff is an excellent one.
MR. CURRAN: Right. So here is the question. Right now I believe I understand Leslie, this is considered not enough guidance to staff, okay? Independent of this Policy Proposal, okay, if we want to have a discussion in the open mic about you would like to have this enforced to the best of the ability, we can do that. But I want to try to focus on this Policy Proposal as written. Does this improve --
MR. BICKNELL: Well, the question I got was half that and half they are required to do this in v4 with no guidance, or they're doing it there as well, and I think that may be germane, if I may.
MR. CURRAN: Leslie, we need to know the practice with respect to IPv4.
MS. NOBILE: There is a section of NRPM called 4.3.3, it's called utilization rate, and it talks about 25 percent immediate utilization and 50 percent utilization rate within 1 year. That is what we are asking. How -- why -- how are you making your customer reassignments and that is what we are holding them to, 4.3.3. That is something --
MR. CURRAN: So that's being applied -- does that -- Heather?
MS. SCHILLER: No.
MR. CURRAN: No?
MS. SCHILLER: I'm referring to 220.127.116.11, ARIN approval of reassignments and reallocations and it -- .1 is /18s and .2 is /19s.
MR. CURRAN: Is 18.104.22.168 being -- has ARIN had any of these and are they being performed by ARIN?
MS. NOBILE: Yes, we review -- our software automatically stops reassignments larger than /18 or /19 depending on whether they are large or extra large ISP -- or medium or smaller, sorry. Yes, our software catches it and then we do question them and what we are looking at is 25 percent, 50 percent utilization.
MR. CURRAN: And then even though it's not written into 22.214.171.124, they are applying that other section?
MS. NOBILE: Correct. From 4.3.3, yes.
MR. CURRAN: Does that answer the question of what's being done, Heather?
MS. SCHILLER: It does answer the question of what's being done.
MR. CURRAN: So are you for or against this change to the policy?
MS. SCHILLER: I am still for it because it does -- it does tell ARIN staff how to handle the utilization when folks assign something larger than a /47 and I would reinforce to the community that this policy, the beginning part, it doesn't change at all, is -- keeps in line with existing v4 policy of having a bar by which -- above that ARIN staff reviews it.
MR. CURRAN: Okay. Front microphone?
MR. DICKSON: I'm getting into some text here that is specifically being replaced, so the original text, I don't know, it was too small to be seen on the screen.
SPEAKER: I have a feeling it is but I'll pull it up here.
MR. CURRAN: What section?
MR. DICKSON: 126.96.36.199, I believe.
MR. CURRAN: 188.8.131.52.
MR. DICKSON: Yes.
MR. CURRAN: Assignment, address space size.
MR. DICKSON: Yes. It specifically talks about minimum value of /64. That text is gone in the proposed, changed -- I think that's a fairly significant change, it's a change in policy that doesn't say what size needs to be SWIPed In fact, it removes all requirements other than /48 for swipping, implicitly or explicitly.
MR. BICKNELL: I believe if you want to assign a /128 to your customer that's your own business, and I believe that all assignments to customers could be -- should be swipped and I believe that's in a different section although I don't have my manual up here, so I would have to find out. Yes, and Ed makes an excellent point. These are guidelines, and the staff has said before that because they are guidelines, they cannot enforce them.
MR. CURRAN: Correct. The section begins, these -- the following guidelines may be useful but are only guidelines.
MR. BICKNELL: So staff has said if people break these, there is nothing they can do about it.
MR. DICKSON: 6.5.4 says LIRs must make IPv6 assignments in accordance with the following provisions. That text has not changed in your proposal.
MR. CURRAN: But the /64 that follows in 184.108.40.206 says "The following guidelines may be useful but they are only guidelines."
MR. DICKSON: That's the master paragraph.
SPEAKER: There is a /64 reference about that.
MR. DICKSON: Sure. So all the guidelines have gone out the window?
MR. BICKNELL: Yes, because the staff has explicitly told us on more than one occasion that they ignored the guidelines. They might as well not be there, they do nothing with them, will never hold anybody --
MR. DICKSON: My point is the guidelines exist not for the staff but for the people who are making the applications. Staff need to review them against the guidelines, but those guidelines need to exist.
MR. CURRAN: Okay, point of information. Go ahead, Leslie.
MS. NOBILE: Yes. Staff has not said that they don't use those guidelines. We use them quite often when we are reviewing requests for initial allocations, when we are looking at the size of reassignments to your 200 customers we actually ask about how you intend to reassign space, and we do use those guidelines, and we will question someone for very small -- you know, DSL customer, whatever, cable customer -- I mean a -- whatever, dial-up customer, if they are assigning /48s to those customers, we will say the guidelines clearly say this, why would you do this? We absolutely use those.
MR. CURRAN: They use it as part of the dialogue with the ISP.
MR. BICKNELL: If they did it anyway, so there would be use for enforcement.
MR. DICKSON: Point of clarification then --
SPEAKER: Can I --
MR. CURRAN: Sorry, now, one speaker at a time. Center rear microphone, yes, Cathy.
MS. ARONSON: Can I just say, as the co-author of the first document to remove the guidelines you revoked, for this very reason we withdrew our Policy Proposal to remove the guidelines because they were the only guidance that the ARIN staff had in order to assist people in doing the right thing. So removing -- you know, I mean, until we have an operational -- I call it NPOG, that's a separate companion document that says the guidelines are here and this is how you do it operationally. It's hard to remove these things from this document because they use them.
MR. CURRAN: Correct. Okay, are you proposing this particular change to the Policy Proposal?
MR. DICKSON: Pardon?
MR. CURRAN: Yes, are you suggesting a policy change to this proposal?
MR. DICKSON: Not at this point.
MR. CURRAN: Then in which case --
MR. DICKSON: I had one question further to the ARIN staff, which was, is the --
MR. CURRAN: I'm sorry, regarding this -- excuse me, regarding this Policy Proposal.
MR. DICKSON: Regarding this Policy Proposal.
MR. CURRAN: Yes, what's your point of information?
MR. DICKSON: Is the removal of the current text on recommendations in 220.127.116.11 going to be problematic for reviewing submissions?
MR. CURRAN: Does the change suggested in this Policy Proposal -- will it make it problematic to do reviews?
MS. NOBILE: Yes, it will.
MR. CURRAN: Okay.
MS. NOBILE: That is all we have right now. Yes.
MR. CURRAN: Okay. Speakers on the policy -- do you want to respond?
MR. BICKNELL: I'm actually curious about that because while I understand that people may want additional criteria from a review perspective, I would expect to make it easier, because anything /48 or longer you just go okay about, you don't have to worry about the details. So I'm confused.
MR. CURRAN: Let Leslie respond.
MS. NOBILE: I'll clarify, I'm sorry. As I stated, we use those guidelines when we are reviewing initial requests for IPv6 allocations. That's when we use it. We don't use it at reassignment -- because we are not reviewing reassignments at this point, we don't use it then. We use it initially, up front to review.
MR. BICKNELL: Okay.
MR. CURRAN: Is that clarified? Okay, other people who wish to speak for or against this Policy Proposal? I recognize someone at the mic. Go ahead.
MR. LEIBRAND: Scott Leibrand, Internap. Following up on Brian's point, this text that's up there says that all LIRs must make assignments in accordance with the following provision, the exact size of the assignment is the local decision using a minimum value of /64. It's unintended, I don't think it matters, but this policy does change -- this does change policy in the way that would allow -- if it we were technically possible, ISPs to announce or to assign customers /80s, /128s or whatever. And that's not currently allowed now, never mind guidelines, which -- based on ARIN staff comments I think maybe we should keep, but other than that I still support the Policy Proposal.
MR. CURRAN: You note that but you support the policy, okay. Aaron, back.
MR. HUGHES: Aaron. I'm in support of the policy as written, but what it also suggests perhaps a poll at the end to find that if we leave the guidelines in and/or change the word "will" to "may" and send it on to the AC for evaluation, perhaps we could come up with something that's good for both ARIN staff, the AC community and the ARIN community.
MR. CURRAN: One more time, I'm very sorry.
MR. HUGHES: If we push this forward, it sounds like it removes the guidelines, so I don't want to see people voting it down because the ARIN staff are going to lose their guidelines. I think we should pass this to the AC to add the guidelines back in and not delay this another 6 months and not give anybody any guidance.
MR. CURRAN: Okay. Comments? Far.
MR. DICKSON: A very minor comment that I am actually in favor of the intent of the proposal, just not the implementation, the actual text.
MR. CURRAN: Okay.
MR. DICKSON: And to further voice the recommendations, I would like to see extension beyond /64 of what's allowed to be reassigned.
MR. CURRAN: Okay.
MR. DICKSON: And a strong recommendation of the specific of the /80, /96.
MR. CURRAN: Well, far left side, Thomas.
MR. NARTEN: Yeah, just to summarize, I mean, I'm split on this because I think the proposed text is reasonable, I don't have any issues with the proposed text. My issue really is with yanking out 18.104.22.168 in its entirety and just making it go away and I think that's -- it's useful to leave it in. I don't want to see it go. So there is really two things that are going on here, and one I'm okay with and one I'm not.
MR. CURRAN: In summary, Thomas, because of those two things you are --
MR. NARTEN: Still opposed.
MR. CURRAN: Still opposed to the proposal, thank you. Leo?
MR. BICKNELL: I had hoped, and this was just the way it worked, that we would be further along with the NPOG as we're calling it by now, the operational guidelines, and that this text would have already made it in there, so that was kind of a working assumption that I had so that it would not be completely lost. If I can borrow your sheet for a second. I would not be opposed to a friendly amendment of adding back to this text the line that starts with "The following guidelines may be useful but they are only guidelines" and the three bullet points following that in the existing text. If that would make people happy I would be happy to add it back into this text.
MR. CURRAN: With the addition of that, Thomas, the following guidelines may be useful on the three succeeding bullets, address your concern, and would that make you in favor of the proposal.
MR. NARTEN: Not for me. I would like to see that section stay in its entirety and have the revised wordings simply replace in 22.214.171.124, which is where the revised text comes from anyway.
MR. BICKNELL: I'd welcome other comments on it. I see some nits in there that people have commented on.
MR. CURRAN: But his suggestion of retaining 126.96.36.199 in its entirety, you don't consider compatible with your proposal?
MR. BICKNELL: Yeah, I'm initially not sure about that because that would retain the minimum of the /64 and we just heard a comment that people want freedom to go smaller if they feel that's a good idea. So I'm not sure retaining absolutely everything in there is a good idea.
MR. CURRAN: Okay. So we are on the Policy Proposal as written -- on the topic of the Policy Proposals as written. Further discussion of the microphones. Closing the microphones. Thank you, very much. (Applause)
MR. CURRAN: Fun. Okay. The AC's probably got lots of guidance but we're actually going to help with the show of hands, because we have a Policy Proposal here. And when I don't ask for shows of hands they sometimes object later that they don't know what they heard. So, I'm going to make sure we, at least, have a call here. I'm going to ask everyone in favor of Policy Proposal 2007-24 as written, and I'm going to ask everyone in favor, and then I'm going to ask everyone opposed. Okay? All those in favor of Policy Proposal 2007-24, please raise your hand. Nice and high. It's the last one of the day; you can really put it all in there. But, still one hand. Just one. Thank you. All those opposed to Policy Proposal 2007-24, please raise your hand. This should be a different group than the prior set of hands that were up. (Laughter)
MR. CURRAN: There should be no intersection. Well, it's that? Thank you. Thank you. On the matter of Policy Proposal 2007-24, total number of people in the room, 114. Those in favor, 14. Those against 19. The show of hands will be provided to the AC for their consideration tonight. Thank you.
IPv6 Support Among Commercial Firewalls
MR. PLZAK: Okay. Now, we have a report from Dave Piscitello. This concerns a survey conducted about support for IPv6. In other words, existence, I guess, of support in commercial firewalls. One of the questions that keeps on getting asked, and assertions are made, that applications and other things are not ready for IPv6, and that's what this survey is about. Dave.
MR. PISCITELLO: Hi there. I'm actually not going to talk about addressing. So, it's unusual that I even be here. My name is Dave Piscitello. I am currently a fellow to ICANN Security and Stability Advisory Committee. I'm unusual in that capacity, because I'm the only full time paid employee at ICANN, who is staffed on that committee. The rest of the committee are all volunteers. At the last ICANN meeting in July, in San Juan, Ray introduced the problem that you're all facing in the rapid depletion of IPv4 addresses, and the need for us to implement IPv6. One of the things that came to mind to me having spent a fair number of years as a consultant doing profit evaluations and firewall testing, and you know, other security appliance testing including IPsec, is that I actually couldn't remember any product that I touched in the last three or four years that was able to process and do any sort of security policy enforcement using quasi addresses or using IPv6 in any form. So, I decided that I would start (off mike) project, and I would go through some of the products that I had at hand. I started looking at them, no support. I started asking some questions. I was surprised at how little I could find. What I, at that point, did was I went to the -- where is the -- what do I point here? So I decided to go through and try to make this a little bit more formal product -- project with the SSAC, and so the purpose of this study, once it became formal, was to try to understand what sort of IPv6 transports support security service available -- availability there was among commercial firewall products. It's important for you to understand this was a survey only, and there was no product testing. It's also important to recognize that we didn't include personal firewall software, and in the categorization that we looked at, we did not really include what I consider the commodity broadband access devices. These would be broadband or DSL routers that you would get that might include something like a static packet filtering, but didn't have any other features that we would normally ascribe to a firewall. So the four major questions that I wanted to address were, how broadly is IP version 6 transport supported? Is support for transport and security services available for all market segments? The market segments we consider were essentially small office, home office, small and medium business, and then large enterprise service provider. What I allowed companies to do when they were spying through the survey was identify themselves what products they had for each of those markets. I did not attempt to draw a line and say, under 200 users, over 5,000 users, you know, massively large international service provider. So a lot of the feedback is vendor biased in terms of where they place their products, and quite honestly many of the vendors placed their products in every single one of the categories. So in some cases, it -- you know, it really didn't matter. Now, what kind of security services are commonly used in Internet firewalls and what are available when IPv6 transporter are used? This was the crux of the question that in my mind was -- if I wanted to take a firewall today and I wanted it for IPv6, could I actually deploy a security policy that would be similar to the one that I'm deploying when I'm using a firewall and I'm using IPv4 transport. Okay, so I began by saying how many firewalls am I going to do? And I tried to figure out how many I could actually identify and then started googling, started asking and seeking advice from, you know, commercial lists of firewalls from different resource sites. There are lots of firewall mailing lists. There are lots of firewall research sites on the internet, I used those. I contacted the ICSA Laboratories, I asked them for their certification list, and I essentially built the list of approximately 60 products. Now, it turns out that there are many more than 60 products, but this was a list that I started with and it was the list that actually yielded probably the best results. How did I choose the -- what I considered commonly available services? Again, what I did was I started looking through all these firewall products, looking for the common services that they supported, and instead of trying to be extremely granular in this survey, I tried to be just the opposite. Tried to be as generous as possible to see what kind of support I could extract with, maybe 10 or 12 criteria. So the features that I considered important were IPv6 transport. Under transport, there were two features I wanted to consider. One was can a firewall forward native IPv6 traffic from an internal interface or a trusted interface through to an external interface. The second part was, can the firewall actually, participate in some -- some routing or neighbor discovery behavior. In traffic filtering I looked at the three fairly, you know, tried and true methods of packet, you know, per packet and multi-packet policy enforcement, stateful inspection, static packet filtering and application level inspection. I didn't want to distinguish between proxy, I didn't want to distinguish between other sorts of deep packet inspection technologies, I just wanted to understand why the people felt that they could do more than inspect simply IP level traffic, but could inspect traffic above the IP layer. It also included features that you find more commonly now in a lot of SNB and large enterprise and service provider firewalls that provide some form of intrusion detection or intrusion prevention and DDOS protection. The additional features I was concerned about just trying to map across were NAT, the ability to tunnel 4 to 6 and 6 to 4 and then there was a set of features that seemed to pop up often enough, but I wanted to see how, you know, how popular they were, not only in the v4 space, but in the v6 space as well. As I said, this was a survey. It began by contacting vendors, and in order to contact vendors I used a multiplicity of vectors. I contacted technical support, I contacted sales, marketing, I used general inquiry e- mail addresses. So I basically spanned the survey to as many different places and companies that I might be able to get a positive response or a pulse. I also didn't want to rely entirely on, you know, on sort of the marketing sector of a company to get this kind of information because quite honestly, some of these products would, you know, would not even surface on the typical small sheet that somebody out at an 800 info line or a general inquiry line might have, so I tried to get as many technical staff identified from my own colleagues in the firewall space and from ICSA laboratories and other sources. I also used third party corroboration, where I had some questions about what vendor replied. I asked, you know, on firewall lists, are you -- is anyone using this firewall, if you're using it, could you look up in the administrative guide or in the UI and tell me whether this actually exists. I conducted some discussions privately, some discussions on a firewall list to get some more information. Finally, when I was really curious as to whether or not something was being, you know, accurately conveyed to me, I hunted down user documentation, you know, administration guides, text specs, whatever I could find to sort of corroborate what was being presented to me. Ultimately, out of the 60 products that I surveyed, I ended up with 42 results. Now, those 42 results in some cases, you will see multiple numbers, so things will add up to more than 42, and that's because the product actually satisfied more than one space. So let's go through some of the numbers. This report is online at the ICANN SSAC website. It's available for download. I'd love to hear some comments and feedback 404 from you. I'm going to go through it fast here because I know you all have an open mic opportunity, and I sense from this community that open mic is a very popular thing. So you know, overall -- one of the nice things about IPv6 transport is that everyone does support, you know, all firewalls surveyed support IPv4, which is real nice. Only 31 percent support IPv6. The breakdown was SOHO at 32 percent, SMB at 34, and LE/SP at 30 percent, so it's pretty even, about one and three. IPv6 routing, this is where you start to see some disparities between a lot of the different kinds of products. Sixty percent of the firewalls participate as peers or perform a neighbor discovery in IPv4, only 24 percent in IPv6. The breakdown is still a bit consistent, but now you start to see that the SOHO firewall has kind of dropped or lagged behind the SMB and the LE/SP firewalls. Of the three types of, you know, policy enforcement on packet or multi-packet filtering techniques, static packet filtering is the simplest and most long-lived in the industry. Ninety-five percent of the firewall survey provided, I was surprised, it wasn't 100 percent because I was sitting there thinking, well, if you don't provide static packet filtering, you know, where did you go from there. However, this is what was returned and I couldn't find any evidence that what was returned was wrong in those two products. Twenty-nine percent provides static packet filtering went to IPv6 issues. That's only 12 of 42. The breakdown again is pretty consistent, one and three. Stateful traffic inspection, again, what was very interesting to me was 90 percent of firewalls surveyed offered stateful inspection. This is fairly significant and fairly high, when you know, IPv4's is used. Only 24 percent do so when IPv6 is used. Again, you got a pretty even breakdown, you're down closer to the one and four and one and five range when you started to move up in more sophisticated levels of policy enforcement on IPv6. Application level inspection, again, we're moving up the stack, getting more sophisticated in product capabilities. We're talking here about having SNTP proxies that do significant analysis of, you know, SNTP traffic, provide any spam features, talking about being able to parse DNS out of proxy and look for traffic anomaly -- or patterns and anomalies in the headers and in the -- and the information that's conveyed. Http proxies and not only proxies, but also being -- using deep packet inspection or stateful inspection on application header and payload. Eighty-one percent when IPv4s used, only 17 percent, overall, when IPv6 is used. One of the things that I discovered after asking this question that I realized I probably had articulated it incorrectly is that the question sort of covers a broad (off mike) of features. If you ask this question to some vendors, they will believe that they're providing application level inspection when they provide a web blocking technique or Net Nanny kind of technique for a small office product. If you're asking a large enterprise SP firewall vendor, he's thinking that he's protecting a web application behind a firewall from cross side scripting, input forms validation or other forms of attacks. So you've got this broad swath of different features that were essentially responded to with a yes or no question. Even if I discount that, the numbers are startlingly low. Intrusion, detection and prevention in products, three out of four companies identified some form of intrusion, detection, and prevention, meaning, they have some set of signatures or some other behavior that allows them to distinguish malicious traffic. A lot of this is recognizing port scanning and automatically blocking the source of the port scanner blocking the address block from the source -- from the port scan, but 75 percent is -- it was pretty consistent with what I had seen in evaluating products over the years. Only 14 percent, one in seven, provide that same level of service in their responses when IPv6 is used. This number is skewed quite, you know, quite dramatically by the SOHO market where you wouldn't expect to see this level of sophistication in the product, but the other two numbers are not quite as, you know, as robust as one might hope. DDOS protection, fairly consistent numbers along with IPS. What I conclude here was that there were a few things that people could do very simply in a SOHO product, so they were able to do it to provide some basic forms of DDOS protection, but overall we're still in the one and five range. Tunneling capabilities, there are two graphs here side by side. There is tunneling 4 to 6 and tunneling 6 to 4. There are more products that are able to tunnel six in IPv4 tunnels, fewer products one in seven able to tunnel IPv4 and IPv6 transport. I then step back and I said, okay, the firewall market has 60 products that I'd measured. Most people probably in this room are familiar enough with the fact that firewall market is dominated by maybe five companies. If you go and you do -- look at some of the statistics of the top five companies, they probably hold in excess of 95 percent of the market share. We can all debate that over a beer. Based on, on our speculation within SSAC, we chose what we thought were the top, you know, the market leaders in the firewall space. We took their products, which turned out to be approximately 13 products and we went back and we recalculated the numbers. Even when we recalculated the numbers, we still see that we're only around a 50 -- maybe 60 percent space in terms of being able to support IPv6. If you look at the -- that's in the transport. If you then look at the more sophisticated traffic inspection and advanced security features, we're still lagging -- that down in the lower right-hand side on your, you know, in your view, application layer inspection is still down in the 32 -- below 40 percent for all products among the market leaders. Some additional observations when I was looking at some of the these products and some of the surveys returned is that generally if the product supported IPv6 transport and traffic inspection -- I'm sorry, IP transport and traffic inspection, the product also was able to log IP level events and was able to support IPsec, which meant that if you did find a product that could support IPv6, the chances were you were going to be able to do some significant level of monitoring and you would be able to provide secure tunnels at the IP level. I also found that in attempting to compose some graphs for some of the advanced services that I mentioned or the additional features I mentioned, that very few products are supporting DHCPv6 or RADIUS or flow monitoring what IPv6 has used. Another problem with trying to compose figures and statistics on this one is that I've got inconsistent reporting in these features. Some companies reported back saying, well, we don't know what you mean by flow monitoring. When I explained it to them, I didn't get an answer back. So -- I could have put a no, but I was generous. I thought that it would be useful to also share some of the vendor comments that I received in deliberating with the vendors. Some of the vendors were asking me why I was asking the questions. After explaining why, they were comfortable enough to review some information. The deeper into the technical community I got, the more willing they were to share, and be collegial about where they were in product development. Some people asked me if I would sign an NDA before I spoke with them. I said no, and then they went ahead and told me any way. One of the great things about the security community is observing in real time the security community being socially engineered. So, IPv6 support in procs that have it is not as fully featured as IPv4. For example, if a vendor supports IPsec or IP security, maybe they support fewer Internet Key Exchange, pure authentication options or maybe they only support manual keying. A lot of the user interfaces are not as robust. For example, you can use the command line interface to configure IPv6 on a couple of products. They don't have it implemented in their GUI. IDS and -- and Vita support is not as robust, talked to a number of companies where the signature sets and further inspection engines were fewer and not as expensive as the sets for IPv4. Similarly, the number and kinds of DOS attacks that they can detect and block are fewer when IPv6 transport's used. Commonly, when I ask why no support, they responded no one's asking. This is not a big surprise, but it's something that we have to pay attention to. So our conclusions are essentially the support for IPv6 transport security service is available for all market segments. However, the availability of advanced security features is lagging in several of those markets. And firewall products that support IPv6 transport will typically provide some form of traffic inspection, event logging and IPsec version 6. This is not a particularly strong set of conclusions until you get to the next page. One of the things that we're concerned about is that IPv6 transport is not broadly supported by commercial firewalls, one in three on average is pretty low. And even when you go to the market leaders, you're still around the 50 percent mark, which is still reasonably low. When I asked a lot of these vendors, well, do you have this on your timeline, many of them said, typical -- how many of you have dealt with vendors, every time you ask them something, it's always in their next quarter or it's in two quarters away. I didn't get a lot of those which is telling in itself. I got a well -- third quarter away, first quarter '09. And so that -- it was another telling indicator that this is not high on their priority list, that other security concerns for applications that are much more in demand like VoIP and increase the ability to detect and thwart attacks on applications are taking precedent over deploying a new transport. I think that's the last one, the next one is for -- that's for ICSA Labs, okay. So that's it in a nutshell. The report's only about 20 pages long. It has a little -- more statistical analysis. The things that I'm concerned about, that I think this community has to pay attention to as well, is that we could assign all these addresses we want, but if people can't secure the networks, they're not going to migrate from 4 to 6. Thank you for the opportunity.
MR. CURRAN: Thank you. (Applause)
MR. CURRAN: Any questions for -- I'm sure David will be around quite a bit, but if anyone wants to ask any questions right now, real quick, the mics are open.
MR. PALET: Jordi Palet. I think there is a terminology problem in your presentation, because you mention about 6 to 4, which is a transition technology, and actually you mean 6 in 4, and I think that's really confusing. So I will suggest that when you do the presentation next time or you can update these lines, I'm sure you are referring to IPv6 encapsulated in IPv4.
MR. PISCITELLO: Right.
MR. PALET: Which is 6 in 4, but not 6 to 4 --
MR. PISCITELLO: No, the survey actually --
MR. PALET: It's totally different, and this thing will be 4 in 6 or IPv4 encapsulated in IPv6. In addition to that, I host a web page, which is IPv6-2-standard. And I did a quick search right now, and I think I have listed something like about double of number of firewall vendors that support IPv6. So probably trying to do the survey which -- I don't know which vendors you contacted, but the vendors that you can find in that web page, that also support IPv6 will provide a better results -- a better view.
MR. PISCITELLO: Okay, so you -- you mentioned two things; 6 in 4, 6 to 4, very, very legitimate comments, I can correct that, yeah.
MR. PALET: 6 to 4 is a protocol, it don't means -- it used 6 in 4 encapsulation, but it's a totally different thing.
MR. PISCITELLO: Sure, and I understand that. And the second one is that -- I'd certainly want to touch base with you offline, so you --
MR. PALET: IPv6-2-standard, you search for "firewall," and I get something like 20-something vendors that support IPv6 and firewalls, and this is information that I am keeping updated every day almost.
MR. PISCITELLO: So what -- we'll have to talk offline about that, because that certainly wasn't what I came up with.
MR. PALET: Yeah, right.
MR. CURRAN: Okay, thank you, anything else? One more.
MS. SCHILLER: Thank you very much for this presentation. Where are the slides, because I just looked for it and I can't find them and they're not linked on the ARIN agenda.
MR. PISCITELLO: I'm sorry.
SPEAKER: Where are the slides online?
MR. PISCITELLO: The slides -- I brought them today. So the slides will go up on the Wiki by the end of the day.
MS. SCHILLER: Okay, thank you.
MR. PISCITELLO: Sure.
MR. CURRAN: Okay, any other people asking questions, to David -- no, thank you David.
MR. PISCITELLO: Thank you. (Applause)
MR. PLZAK: Okay, time for an open mike, same rules as earlier, John.
MR. CURRAN: Thanks. Okay, we're almost done for the day. The only thing between us and adjournment for the day is the open mic session. Microphones are open. If you like to raise any issue, now would be the time. Okay.
MR. SEASTROM: Motion to adjourn. (Laughter)
MR. CURRAN: I actually see someone else in line but very close, RS. Jason, yes.
MS. SCHILLER: Jason Schiller, UUNET/Verizon Business. I just wanted to ask the chair, if we could do a quick straw poll about something that came up earlier with regard to language in the NRPM, bigger, smaller, longer, shorter, more specific, less specific. What is the most preferred, most well understood term?
MR. CURRAN: Oh, with regards to terminology, longer, bigger, shorter --
MS. SCHILLER: More specific.
MR. CURRAN: Okay, so -- I first want to say there is an active discussion going on with the board and staff right now about the network resource policy manual and things that could be done to improve it. And one of it would be to standardize this terminology. Once the terminology is standard and consistent, then it's very simple for the community to say, thank you very much, but you used the wrong pair of terms. So right now, I don't think it's really important to get that pair of terms down as long as we have two that are used consistently. Okay?
MS. SCHILLER: Okay.
MR. CURRAN: Thank you. Owen.
MR. DeLONG: Owen DeLong, JTTR. Hello, am in on? Owen DeLong JTTR Networks, and I like longer prefix, shorter prefix as the best terminology, and I second Rob's motion.
MR. CURRAN: Okay.
MS. SCHILLER: Thank you.
MR. CURRAN: Out of order for the motion, since we've -- actually, to be fair, an adjournment motion is always in order. But we're not finished with the business of the day, so I'm going to ask the group's indulgence, because there are people with the microphones. I am however, closing the microphones. So if you have a topic and you're not there, you need to move in the next 10 seconds. Cathy.
MS. ARONSON: Cathy Aronson. We talked earlier -- I don't want to belabor this, but I really would like feedback. We talked earlier about how Policy Proposal, showing up on the mailing list and becoming a policy without coming to a public policy meeting. But we didn't fully discuss my topic, which was folks' thoughts on a Policy Proposal coming to the mailing list, getting wholeheartedly negative feedback, and then getting rejected by the AC before it comes to an open forum in person, and I would really like people to give us their thoughts on that.
MR. CURRAN: So the topic is DO you believe this is a good practice or a bad one?
MS. ARONSON: As I said earlier, I tend to err on the side of bringing it to the community and bringing the discussion, but sometimes, you know, it's just, you know, wholeheartedly rejected and we're in a dilemma as a group about what the community feels we should do at that point. Do they feel that it's a waste of their time to bring it in front of them if, you know, if there is so much negative feedback, or whether we should bring it any way, because the discussing will be valuable and we'd like to hear your thoughts.
MR. CURRAN: Okay, the internet resource policy evaluation process allows a Policy Proposal to effectively be abandoned before it makes it before the group. It also provides for a petition process to ensure that it makes it to a public policy meeting. So Cathy's raised the question, is this the right way to do it, should the AC not abandon these proposals? Potentially, should all proposals come before the group, and want to hold discussion to the topic of that. So if you're not speaking on the matter of early abandonment of proposals, step back from the microphone. Okay, in order, yes, from center.
MR. WEILER: Sam Weiler, SPARTA. I would be in support of that, as with my earlier suggestion about giving the AC --
MR. CURRAN: Just a bit clear, because I would be in support of that, that seems a little independent, I just want to --
MR. WEILER: I would be support -- in support of changing the internet resource policy evaluation process to allow the AC to drop a proposal without taking it to a physical meeting, but after accepting it as a formal proposal into the process.
MR. CURRAN: But -- Cathy clarify, because it's --
MS. ARONSON: Point of clarification. I'm talking about it comes upon the mailing list. When we go and deliberate, and we decide whether it becomes a formal Policy Proposal and gets a number. Usually what happens is it comes out, it gets posted to PPML. Everybody does their flames, we have a meeting. We discuss whether to give it a formal Policy Proposal number or not, and then it comes to the meeting. There are several of them that we've had heavy deliberations about whether they should even come to the meeting and be given a formal Policy Proposal number because of the lack of support on PPML.
MR. CURRAN: Right, it's possible that it won't be brought forth, and you're saying you want to allow that, actually the current process allows that.
MR. WEILER: It already allows it.
MR. CURRAN: It already allows it, the question is, is that a good thing?
MS. ARONSON: It's just that the AC is somewhat divided on this, and I was just wondering if we could get your feedback?
MR. CURRAN: It's presently allowed, do you think that's a good thing.
MR. WEILER: Thank you for the clarification, yes, I do.
MR. CURRAN: Okay.
MR. WEILER: Here's on of the reasons why. In the --
MR. CURRAN: Briefly.
MR. WEILER: In the responses to my earlier points, some of the folks raised the question of how do we make the mailing list more responsive? One of the answers is to make the meeting less authoritative. Making it very clear that we can take action based just on what's on the mailing list, it helps to make that point.
MR. CURRAN: Good. On this point, Aaron.
MR. HUGHES: We've elected our AC, and I've put my faith and trust in them, and I would ask that they review, maybe say the last year's worth of data, and say, have we ever had one that we strongly objected in the list that has actually passed in the meeting. And if that is the case, then I would reject this, but if we've never seen one come to the meeting and pass, that was strongly rejected on the list ahead of time, then I think that's perfectly fine and we should do it.
MR. CURRAN: Understood, that's kind of hard to get data on, but understood. Microphones are closed for any other topics for people who aren't standing there -- if you're -- if you want to comment on this that's fine, and if you're in the microphone queues for something else, that's fine, but no new topics. On this point, yes.
MR. LEWIS: Ed Lewis. I like it the way it is right now. We've had two petitions, one was successful, one's not successful, so I think that's pretty good ration.
MR. CURRAN: Okay, Thomas.
MR. NARTEN: Yeah, so I think the principle here should be that we don't need to bring something forward to a full meeting if there's no support for it other than from the sponsors. And if no one in the AC is really willing to step up for it, and no one on the mailing list is going to step up for it, I think you know, we shouldn't burden the rest of the community on that -- with that.
MR. CURRAN: I just want to -- on behalf of Cathy, I want to solicit. The AC can presently not -- abandon a proposal before it comes if the mailing list truly doesn't have any support for it. If anyone thinks that's a bad idea, please approach the mic. Because the AC obviously wants some reassurance that they're not doing a bad thing. They don't think that's a problem.
MR. DICKSON: Brian Dickson, Afilias. One small caveat. There are always going to be new members, new participants on the mailing list. If they propose something, I think that guidance should be given. If a proposal is strongly rejected on the mailing list that -- even though it is dropped, there is a petition process.
MR. CURRAN: Sure. That's a valid point. Cathy, is this good feedback for you in total?
MS. ARONSON: Yeah.
MR. CURRAN: Okay. I'm going to -- Ray, you go ahead.
MR. PLZAK: One comment regarding the petition process. Whenever, the AC rejects a proposal, either at the initial stage or at any other subsequent stage, the author is notified personally by the shepherds of the proposal and by staff of the availability of the petition process and are given instructions.
MR. CURRAN: Right. Okay, so I'm going to -- so there are two remaining speakers at the open mic. Far right side, yes.
MR. DICKSON: Just a suggestion on making both better use of the long-term time in terms of cycles between meetings, especially on proposals which may effect multiple RIRs, and to encourage participation on the mailing list, that if there are proposals which are somewhat contentious but have a lot of interest at a meeting that notification be given to -- that it should be considered as an active ongoing discussion that people should participate on a mailing list on. So specifically, that notification would be given at the meeting saying, we're going to take this to the mailing list, as opposed to -- let's talk about it at the next meeting, six months from now.
MR. CURRAN: Understood. I think it's safe to assume that, but you're right, we need to make that clearer for Policy Proposals that are neither advanced nor abandoned. Ray.
MR. PLZAK: Regarding that last comment, the shepherds take it as one of their duties to make sure that those kinds of things are brought to the attention of the community on the PPML. They periodically go out to the community and say, hey, no one's been discussing this for a while. They will go out and say, we need to have discussion on this, so that is occurring today.
MR. CURRAN: Okay, but we take the point that we may need to reinforce it, thank you. Final comment for open mic, new topic.
MR. ALEXANDER: Dan Alexander, ARIN Advisory Council. I just wanted to offer a point of information, because on the earlier open mic, a lot of people had brought up the idea of, you know, they would like a better means to solicit feedback from the community outside of these meetings and so forth. And earlier in the year, the Advisory Council had requested ARIN staff to actually develop a means to pull the mailing list and collect actual feedback. And they did a very good job in it, and just wanted to let everyone know that that is at their disposal. You know, it was never intended to, you know, vote on policies or anything like that, but if you actually are looking to collect some real numbers as far as feedback from the community, you can reach out to an AC member.
MR. CURRAN: Right, the AC members have at their disposal a tool to pull their community. Good point. Okay, that concludes our open mic session, thank you very much. And I'm going to turn it back to Ray, who will, send us on our way, I think, for the evening.
Closing Announcements and Adjournment
MR. PLZAK: Okay, first of all the AC will be sent on its way to have a rather lengthy meeting tonight to provide a report tomorrow to the meeting. And they thank you for everything that you give them as far as helping them with information. Some reminders. The breakfast tomorrow morning for the members meeting starts 8:00 o'clock. The meeting itself is at 9:00. Also you do not have to be a member of ARIN in order to get in -- to get into the meeting. It's an open meeting. It is a members meeting but it's open to the public. The agenda is in your -- is in the meeting bulletin. If you have a wireless card, return it to the meeting registration desk before leaving, and the wireless network that is supporting this meeting will be shutdown after the members meeting tomorrow. Please complete your surveys and go for these lucky raffles. Again, let's thank Shaw for helping out here. (Applause)
MR. PLZAK: And also One Connect IP for what they've done for us. And thank yourselves, it's been a good two days. (Applause)
MR. PLZAK: And so, we'll see you tomorrow.
(Whereupon, at 5:31 p.m., the PROCEEDINGS were adjourned.)