[arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod?

[Tom Vest]

I'm just curious: assuming that decentralized resource transfers are  
approved with *any* policy-based requirements or limitations, what  
mechanisms will survive to enable the community to do the following:

1. Establish the primacy of the surviving policies in (at least some)  
cases where they conflict with more general property-based laws,  
requirements, and limitations, and/or possession/ownership-related  
rights & privileges.
2. Exert influence of any kind (carrots, sticks, et al.) to encourage  
adherence to the surviving community policies.
3. Know when the policies are being being followed, and when they are  
not being followed.
4. Assuming noncompliance is detectable, exert influence of any kind  
(carrots, sticks, et al.) to encourage remedial action.
5. Promote ongoing community interest, or get consistent input/ 
feedback by any other means, on any number resources or policies  
within the scope of the transfer proposal.

For anyone generous enough to respond, I'd be especially grateful for  
specifics (e.g., point-by-point, or at least individual point-level  
answers, matched with specific policies or RIR/community coordination- 
like jobs).

Thanks,

TV

On Jun 21, 2008, at 8:03 AM, Robert E. Seastrom wrote:

>
> Note that these are both restrictions on the transferor, not the  
> transferee.
>
> The goal here is to create a situation where organizations *who are
> not using their address space* are incented to give up some or all of
> it.  While there may indeed be corner cases where organizations
> suddenly don't need any of their addresses, in the vast majority of
> situations demand has been following some sort of curve over time and
> either increasing (in which case in all probability the organization
> will be a transferee in the future) or decreasing (in which case the
> organization will not have been back to ARIN in a while) or remained
> constant (in which case, the organization might not even be an ARIN
> member, having pre-RIR space).
>
> There is no goal of creating a market where people can speculate, and
> the two year pre-transfer clause helps mitigate concerns about ARIN
> having to deal with fabricated requests creating a run on the market.
>
> I am categorically against having any shorter period of time than two
> years or getting rid of the before/after dual restriction.  I would be
> an enthusiastic proponent of expanding the timeouts on both sides of
> the event to three years or whatever the time between "right now" and
> the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is,
> whichever is less.
>
>                                        ---Rob
>
> "Milton L Mueller" <mueller at syr.edu> writes:
>
>> Oops, I pasted the wrong text in.
>> Here is the selection from 8.3.1. apologies to all:
>>
>> * The transferor has not received any IPv4 allocations or assignments
>> from ARIN (through ordinary allocations or assignments, or through  
>> this
>> Simple Transfer policy) within the preceding 24 months.
>> * The transferor may not request any IPv4 allocations or assignments
>> from ARIN (through ordinary allocations or assignments, or through  
>> this
>> Simple Transfer policy) within the subsequent 24 months.
>>
>>> -----Original Message-----
>>>
>>>> -----Original Message-----
>>>> From: Leo Bicknell [mailto:bicknell at ufp.org]
>>>>
>>>> Correction, a 2 year time out on IPv4 resources only.
>>>
>>> Nope. 4 years. You can't have gotten any ARIN or transfer  
>>> resources 2
>>> years _prior_ to the transfer, and you can't get any 2 years after.
>>> 2+2=4.
>>>
>>> Exact quotes:
>>> Nope. 4 years. You can't have gotten any ARIN or transfer  
>>> resources 2
>>> years _prior_ to the transfer, and you can't get any 2 years after.
>>> 2+2=4.
>>>
>>> Your position is relatively reasonable. As I said in my prior  
>>> message,
>> I
>>> think RIPE handled this correctly. You restrict what the RECIPIENT  
>>> of
>>> the market-transfer does with the transferred addresses for two  
>>> years,
>>> not the releaser. That stops speculation cold.
>>>
>>> _______________________________________________
>>> PPML
>>> 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 the ARIN Member Services Help Desk at info at arin.net  
>>> if
>> you
>>> experience any issues.
>> _______________________________________________
>> PPML
>> 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 the ARIN Member Services Help Desk at info at arin.net  
>> if you experience any issues.
> _______________________________________________
> PPML
> 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 the ARIN Member Services Help Desk at info at arin.net  
> if you experience any issues.