<div dir="ltr">Thanks to Owen and Scott for beginning a conversation about this Draft.<div>Scott....given the other restriction that you reference, do you prefer one alternative over another....does the addition of an operational time frame associated with option #2 improve its ability to accomplish the problem statement.....</div>
<div><br></div><div><span style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:1.2em;line-height:1.5em">"Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers."</span></div>
<p style="margin:0.5em 0px;padding:0px;border:0px;font-size:1.2em;line-height:1.5em;color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">This accidentally prevents anyone who receives BLOCK A in 2014 from transferring to another RIR a different block, BLOCK B, which was issued 5, 10, 15, 20 years ago. In my company, we needed to move a block being used in Asia over to APNIC. The block was legacy. But because we had gotten a new block in 2013, we were prevented from moving the old block to a different RIR."</p>
<div><br></div><div>bd</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 22, 2014 at 5:28 PM, Scott Leibrand <span dir="ltr"><<a href="mailto:scottleibrand@gmail.com" target="_blank">scottleibrand@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>There is another restriction already in 8.3, which reads "The source entity will be ineligible to receive any further IPv4 address
allocations or assignments from ARIN for a period of 12 months after a
transfer approval, or until the exhaustion of ARIN's IPv4 space,
whichever occurs first." In light of that, do you still see a problem with #3?</div><div><br></div><div>-Scott</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Several options are being discussed regarding this proposal:<div><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote></div></div></div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><span style="font-family:arial,sans-serif;font-size:13px">1. Use the existing last sentence as is and ask ARIN staff to be particularly watchful for seeming abuse and to bring such back to the community through regular Policy Experience Reports. There was discussion about this option suggesting that by the time abuse was recognized and reported, and given limited existing free pool stocks and the extended policy development cycle....this option is mute.</span></div>
</div><div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><div><span style="font-family:arial,sans-serif;font-size:13px">2. Remove the clause 'and its subsidiaries' and or modify it in such a way as to mitigate the risk of a laundering of addresses through fraudulent transfers, but potentially limit the utility of organizations who may have complex organizations structures in use internationally.</span></div>
</div><div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><div><font face="arial, sans-serif">3. Take an alternative tack and simply restrict the Inter-RIR re-org transfer of the 'recently issued block' only, allowing other existing blocks to be transferred without restriction by recent block acquisition. This alternative seems to have been expressed and supported in the recent Atlanta Public Policy Consultation.</font></div>
</div></blockquote><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">It is my opinion that option 3 is perilous in that it allows a large resource holder to sell off their address space out of region while backfilling from the ARIN free pool.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">As such, I am much more comfortable with option 2. One set of language that was suggested which I like is:</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">“…subsidiaries having been operational for a minimum of 18 months.”</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">While this might not prevent all possible subsidiary-based rinse-repeat abuse scenarios, it would at least prevent the obvious subsidiary created for this purpose scenario and certainly provides better protections than proposal number 3.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I think option 1 is probably an unfair burden for the ARIN staff and makes policy vague in a way that would be difficult, if not impossible, to reliably enforce and may be even harder to defend in the event of litigation. This is strictly my own opinion as a member of the community and I have not discussed the matter with legal council or even the other members of the AC.</font></div>
<span><font color="#888888"><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Owen</font></div><div><font face="arial, sans-serif"><br></font></div></font></span></div>
<br>_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div>
<br>_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div>