[arin-ppml] 2014-2 8.4 Anti-flip Language

Scott Leibrand scottleibrand at gmail.com
Sat Feb 22 18:28:16 EST 2014

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?


On Sat, Feb 22, 2014 at 3:06 PM, Owen DeLong <owen at delong.com> wrote:

> Several options are being discussed regarding this proposal:
> 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.
> 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.
> 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.
> 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.
> As such, I am much more comfortable with option 2. One set of language
> that was suggested which I like is:
> "...subsidiaries having been operational for a minimum of 18 months."
> 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.
> 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.
> Owen
> _______________________________________________
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140222/8f1ef2a4/attachment-0001.html>

More information about the ARIN-PPML mailing list