[arin-ppml] Q2: on Address Transfers - Enforcement mechanisms

[Scott Leibrand]

Tom Vest wrote:
> 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.

As I understand it the RSA controls for address blocks covered by one. 
For legacy blocks without an RSA, the situation is much murkier.

> 2. Exert influence of any kind (carrots, sticks, et al.) to encourage  
> adherence to the surviving community policies.

The primary carrot is inclusion in the ARIN listing service.  The 
primary stick is that some ISPs require space be listed in whois before 
routing it.  (/me waves at Heather.)

> 3. Know when the policies are being being followed, and when they are  
> not being followed.

ARIN staff are getting fairly good at fraud-sniffing.

> 4. Assuming noncompliance is detectable, exert influence of any kind  
> (carrots, sticks, et al.) to encourage remedial action.

ARIN can and does revoke space transferred fraudulently, or in a manner 
that violates a signed RSA.

> 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.

Not sure what you mean by this, unless you're just referring to the 
public policy process in general.

-Scott

> 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.
> 
> _______________________________________________
> 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.