<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 2, 2009, at 1:41 PM, Azinger, Marla wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"> <div> <div> <blockquote> <div><span style="FONT-SIZE: 11pt"><font size="3">I've waited for calmer waters to discuss the merits of this proposal in hopes that others can do the same and not get lost in the sea of procedural commentary. Just looking at the merits of 2009-1 here is what I came up with and I would like to hear what other pro's, con's, solutions and opinions the rest of the community has. While I am grateful for those who have already posted their opinions to ppml I'm hoping to hear from folks that have not yet posted to ppml on this subject. <br> <br><b><i>Sunset Clause </i></b></font></span><b><font size="3"><i><span style="FONT-SIZE: 10pt">(was taken out of 2009-1)<br></span></i><span style="FONT-SIZE: 11pt">Pro</span></font></b><span style="FONT-SIZE: 11pt"><font size="3">: Sets a hard date to stop transfers and resume original policy.<br><b>Con</b>: A hard date could be totally the wrong date. <br><b>Con</b>: Results may show evidence that keeping the transfer policy as permanent policy is better for the ARIN than reverting back to original policy. <br><b>Alternate solution</b>: It might be better to write in a clause the requires review and analysis of the state of address space availability every year. If there proves to be zero difficulty fulfilling IP requests for a period of one year then revert back to original policy and deactivate this policy.<br><b>My opinion</b>: Its cleaner and easier not to have a sunset clause or anything of its kind. If in the future we enter into free flowing address space again, we can always enact the policy process to revert back to the original transfer policy. <span class="945260420-02042009"> Either way its not a show stopper but going without it seems to me to be the best way.</span></font></span></div></blockquote></div></div></blockquote><div>Pro: It provides a default expiry of a policy that much of the community considers<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>otherwise undesirable.<br></div><div>Pro: It sends a clear message that this policy is transient in nature and not expected</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>or intended to be a permanent extension to IPv4.</div><div><br></div>My opinion: Much of the community was able to agree to 2008-6 specifically because it</div><div>had a sunset clause and therefore provided a temporary solution to get over the</div><div>emergency, but, did not create a permanent market in IP addresses which many</div><div>regard as a bad thing. If the sunset proves to be undesirable, there can always</div><div>be policy action to extend or repeal it, but, that should be something that goes before</div><div>the community for consensus, not a line-item veto.</div><div><br><blockquote type="cite"><div><div><blockquote><div><span style="FONT-SIZE: 11pt"><br><font size="3"><b><i>Implementation Date Now and no wait time<br></i>Pro</b>: Immediate implementation would halt the growth of the Black Market which is currently active and growing.<br><b>Pro</b>: Immediate implementation would help preserve WHOIS data. <br><b>Con</b>: The free world of addressing <span class="945260420-02042009">as we currently know it </span>comes to an end. <span class="945260420-02042009"> </span></font></span></div></blockquote></div></div></blockquote>I don't agree with your premise on your first Pro or the Con.</div><div>First, the world of addressing as we know it continues until runout regardless of</div><div>this policy. The black market that exists today exists to serve those that would</div><div>not or would choose not to qualify under 2008-6 or 2009-1 anyway, so, I don't</div><div>see how this will diminish that black market in any way.</div><div><br></div><div>The implementation date doesn't really bother me that much one way or the</div><div>other, but, I think we should be realistic about what it does or does not change.</div><div>The community seemed to come to consensus around the idea of implementation</div><div>at a date when the board felt there was a sufficient need to implement the policy.</div><div>As such, if the board thinks that is now, then, so be it. We left it to their judgment.</div><div><blockquote type="cite"><div><div><blockquote><div><span style="FONT-SIZE: 11pt"><font size="3"><br><b>Alternate solution</b>: Wait till the address availability has reached a choking point.<br><b>My opinion</b>: It sucks to see there is no escape from supply and demand. The former utopian addressing world was great but the fact is when the quantity of anything becomes limited, people no longer freely share or give but require some form of monetary return. We can't escape the fundamentals of supply and demand and I believe maintaining the integrity of WHOIS as much as possible is more important than clinging to the past and in that time frame watching the black market grow and the accuracy of IP usage and record of authoritative source decline. We already need to improve in those areas and this isn't a jab to start that discussion on ppml right now, but it would be best to in the least take action that stops it from getting any worse while at the same time ensuring conservation/proper usage.<br></font></span></div></blockquote></div></div></blockquote><div><br></div>I don't think there is a significant change to whois integrity until such time as</div><div>ARIN is no longer able to issue new addresses through the normal process.</div><div><br><blockquote type="cite"><div><div><blockquote><div><span style="FONT-SIZE: 11pt"><font size="3"> <br><br><b><i>New Definition </i></b></font></span><b><font size="3"><i><span style="FONT-SIZE: 14pt"><font size="3">“Organization. An Organization is one or more legal entities under common control or ownership.”<br></font></span></i><span style="FONT-SIZE: 11pt">Pro</span></font></b><span style="FONT-SIZE: 11pt"><font size="3">: This will force organizations into proper management of IP addresses.<br><b>Pro</b>: This could cut down on waste from large organizations that are segmented. <br><b>Con</b>: Large segmented organizations will have to face management of address space on a higher level. Currently one organization can own three or more companies that up until now have operated separately when it came to address management. With this additional definition Company A could have allot of address space that effectively stops Company B from getting more address space because per the new definition the addresses would need to be shared among the whole Organization not individually by Company as in the past. This would force address management up to the organizational level.<br><b>Alternate solution</b>: Grandfather existing organizations.<br><b>My opinion</b>: While this may be difficult to swallow for some organizations I believe its the most accurate and efficient way to manage address space.<span class="945260420-02042009"> It may also serve as an indirect push towards the adoption of IPv6.</span></font></span></div></blockquote></div></div></blockquote>I don't see your Con as a Con from the community's perspective. I can see</div><div>how some organizations might consider it a con internally, but, looking at</div><div>it from the larger community perspective, I see it as a Pro.</div><div><br></div><div>You left out:</div><div>New Requirement: "Organization"</div><div>Pro: ?</div><div>Con: Excludes individuals that could currently qualify for address space from participating in the market to obtain additional address space.</div><div>Con: May prevent individuals that hold address space from providing it to the market (I am unsure of the interpretation of this).</div><div>Alternate Solution: Use the term resource holder in place of Organization where appropriate in the policy.</div><div>My opinion: This change should be made. Any entity that can qualify under current policy should be able to participate on either side of any market we create.</div><div><br><blockquote type="cite"><div><div><blockquote><span style="FONT-SIZE: 11pt"><font size="3"><span class="945260420-02042009"></span></font></span></blockquote> <blockquote> <div><span style="FONT-SIZE: 11pt"><font face="Arial" size="2"><span class="945260420-02042009"><strong><em>Clarification needed on what this policy specifically is applied to (v4, v6 both?)</em></strong></span></font></span></div> <div><span style="FONT-SIZE: 11pt"><span class="945260420-02042009"><font face="Arial" size="2">New wording doesnt clarify that this is supposed to be for IPv4 only. I think it needs to be clear what this policy will be applied to as it makes sense for IPv4 but not IPv6 since its needed due to a supply and demand situation.</font></span></span></div> <div><span style="FONT-SIZE: 11pt"><font size="3"><font face="Arial" size="2"></font><br></font></span></div></blockquote></div></div></blockquote>As it is currently written, I believe this policy would apply to IPv4, IPv6, and ASNs. I believe that it should apply only to IPv4.</div><div><br></div><div>While most of this is a redux of what I have posted before in pieces, I think having all of it</div><div>collected in one thread is worth-while.</div><div><br></div><div>Owen</div><div><br></div></body></html>