<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 13, 2012, at 1:09 PM, Scott Leibrand wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Tue, Mar 13, 2012 at 12:37 PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net">info@arin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In accordance with the ARIN Policy Development Process, the ARIN Advisory Council (AC) held a meeting on 8 March 2012 and made decisions about several proposals.<br>
<br>
The AC selected the following proposals as draft policies for adoption<br>
discussion online and at the ARIN XXIX Public Policy Meeting in<br>
Vancouver in April. The draft policies will be posted shortly to the PPML.<br>
<br>
ARIN-prop-157 Section 8.3 Simplification<br></blockquote><div><br></div><div>This is a revised version that the AC also retitled to "ASN transfers". The revised draft policy text is short enough to post here: </div>
<div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_quote">In NRPM 8.3, replace "IPv4 number resources" with "IPv4 number resources and ASNs".</div></blockquote>
<div class="gmail_quote"><div><br></div><div>I personally feel that while there is not a compelling need to be able to transfer ASNs as there was/is with IPv4 addresses, that there are legitimate use cases, and very few downsides that I can see to allowing it.</div>
<div> </div></div></blockquote><div><br></div>Scott has not yet been able to articulate to me use cases that I consider particularly legitimate, so, community input in that regard would be helpful.</div><div><br></div><div>Personally, I don't feel that there is a compelling need for this. Further, given the number of problems we have already created by opening up a market in IPv4 number resources, I really feel that it is imprudent to expand this strategy before we've had time to better understand the ramifications of such a transfer policy and work out some of the policy kinks.</div><div><br></div><div>There was urgency and a necessity for implementing an IPv4 resource transfer policy and process. I see no such urgency for ASN transfers and I don't think we need to be creating more headaches for staff and more policy problems for ourselves at this time.</div><div><br></div><div>I supported the motion to discuss this with the community, but, as it currently stands, I do not support the draft policy.</div><div><br><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ARIN-prop-162 Redefining request window in 4.2.4.4<br></blockquote><div><br class="Apple-interchange-newline">This was also re-titled to "Return to 12 Month Supply and Reset Trigger to /8 in Free Pool".</div>
<div><br></div><div>In my opinion we have (perhaps unintentionally) achieved somewhat of a "soft landing" with the current policy that allows for 3 month allocations from the free pool and 24 months worth of space via transfer. I don't think moving back to a 12 month free pool supply will be helpful, but I voted to put this on the agenda for Vancouver because I think we need to have a full discussion on it.</div>
</div></blockquote><div><br></div>It is my opinion that we missed the target on the soft landing we were trying to achieve and we have actually caused quite a bit of harm in the process. When we passed the soft landing proposal, we did not realize that there would be a significant difference between the time that ARIN received its last /8 from IANA and the time that ARIN would be starting to consume that last /8 for address allocations.</div><div><br></div><div>It was much easier to codify the IANA date than the ARIN free pool based date which resulted in policy that was easier to read and understand. Unfortunately, since the dates ended up being far apart, it is having significant impact to a number of organizations in the ARIN constituency and I believe we should correct this mistake post haste. On the other hand, if we debate the issue long enough, it will become moot in 1-2 policy cycles.</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
The AC abandoned the following proposal:<br>
<br>
ARIN-prop-165 Eliminate Needs-Based Justification on 8.3 Specified Transfers<br></blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The AC provided the following statement about prop-165:<br>
"Based on significant community opposition to the removal of the needs<br>
requirement in 8.3 transfers, the AC chose to abandon proposal 165. While the author has brought to light privately additional issues, most of them are procedural in nature and would require a complete rewrite of both the policy and rationale text well beyond the original proposal's intent. The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions."<br>
</blockquote><div><br></div><div>I was in the minority here, largely because I think this is an important issue that should be discussed at the public policy meeting. (I was not in favor of putting this particular text up for adoption discussion, and in any event, it was received too late to make the timeline for Vancouver). </div>
<div><br></div><div>Given that the majority of the AC (and the community) opposed this particular text, I would agree with the statement above that "The AC feels that there is merit in the discussion of these issues, and suggests that the author look at more specific issues outside of removal of needs, that could be applied to new proposal submissions." I look forward to having such discussion at upcoming meeting(s) and working towards a consensus proposal for how to assess needs basis on transfers, particularly after the free pool is empty.</div>
</div></blockquote><div><br></div>It might be an important issue. However, it is an issue that has been discussed, re-discussed, and discussed again. The community each and every time this has come up has resoundingly responded with opposition to eliminating needs basis. Further, we structured our response to inter-RIR transfers to say "agree to needs basis or go play in your own sandbox</div><div>without access to resources from the ARIN community". That was almost the only aspect of inter-RIR transfers that had</div><div>really wide community consensus from the start.</div><div><br></div><div>I'm not saying we shouldn't discuss it further, but, this proposal in anything remotely resembling its current form had such overwhelming community opposition that I felt any action other than abandonment would have been disingenuous to the community and to the author.</div><div><br></div><div>Owen</div><div><br></div></body></html>