[arin-ppml] Policy Proposal 124: Clarification of Section 4.2.4.4

Hannigan, Martin marty at akamai.com
Thu Dec 9 14:28:42 EST 2010


On 12/9/10 2:19 PM, "John Curran" <jcurran at arin.net> wrote:

> On Dec 9, 2010, at 2:10 PM, Hannigan, Martin wrote:
> 
>> Restricting transfers is akin to using austerity measures that we are going
>> to implement post exhaustion except that now it's inverse as applied to the
>> STLS. It would seem to me that it would discourage some abuses of the
>> transfer system and discourage abuses related to "address funding" of
>> transfers. It also gives us some time to come up to speed on the issues. I'd
>> hate to see someone grab large swaths of legacy space only to find out that
>> we've created a mess that will deprive others the opportunity to acquire
>> transition addresses if they have to. Finally, how many transition addresses
>> does one need? On 11/29, Scott Liebrand suggested that non-profits operating
>> CI be forced to the STLS. It's important to get it right. Can you think of a
>> reason not to implement a cap on the STLS, at least to start out?
>> ...
> 
> Its likely that everyone understood what you meant, but just for clarity...
> I believe that most your references in the above should be to NRPM 8.3,
> the Specified Transfer policy.  The STLS (Specified Transfer Listing Service)
> is completely separate, and is simply one way parties might find each other.
> For more details on STLS, see
> <https://www.arin.net/resources/transfer_listing/>
> Regardless of how parties find one another, they may transfer space via ARIN
> if they qualify under NRPM 8.3


Yes, and thanks. To be perfectly clear, I have proposed as a part of PP 124
to remove the following from the policy statement in 4.2.4.4:

"This  reduction does not apply to resources received via section 8.3. An
organization receiving a transfer under section 8.3 may continue to  request
up to a 12-month supply of IP addresses."


The effect would be that transfers would also be subject to a three-month
window of need.

Best,

-M<




More information about the ARIN-PPML mailing list