[arin-ppml] Prop-151: Clarifying requirements for IPv4 transfers (was "Limiting needs...")

Tue Feb 21 18:28:12 EST 2012

The intent of the condition is to limit ARIN's free pool from being a
source of revenue. One should not be able to double dip by profiting on
the transfer of resources while they are obtaining resources from ARIN,
essentially for free. It is not intended to prevent the flipping of any
particular resource.

If we want to prevent flipping it should be a separate condition, but my
thought was to leave that to the RSA and recipient review.

-Dan

On 2/21/12 5:58 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:

>On Tue, Feb 21, 2012 at 15:38, Alexander, Daniel
><Daniel_Alexander at cable.comcast.com> wrote:
>> Chris,
>>
>> There is a valid point in trying to prevent the "flipping" of IP blocks
>> that are obtained through transfer, but you would have to add more words
>> to specify that it is that particular block that was obtained through
>> transfer that you could not be a source on in the next 12 months. The
>> current wording places the restriction on any resources held by the
>>source
>> entity, not the block in question.
>>
>> There are valid use cases where a provider may need to obtain a block
>>for
>> some need, but would want to transfer off another, unrelated block, to
>> service a customer.
>>
>> I would prefer giving ARIN staff the flexibility to consider these
>>things
>> during the review. Someone may get away with it once, if they chose to
>> take this approach, but I don't see them being approved by ARIN staff
>>as a
>> recipient after that since they obviously didn't need the last one.
>>
>> Let's also consider that the block you are concerned about being flipped
>> has been received under RSA and you now have a question regarding the
>> conditions by which they have obtained the registration.
>
>I do not disagree. My point is that all of what you say above applies
>equally to allocations, assignments, and transfers. If you feel that
>the restriction is not needed, then it is not needed for any of them.
>If you feel that the restriction is needed - then we need it for all
>three. The part I don't understand is how why it should be applied
>selectively to two of the three address acquisition methods?
>
>Cheers,
>~Chris
>
>> Dan Alexander
>> Speaking only as myself
>>
>>
>> On 2/21/12 3:04 PM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:
>>
>>>On Fri, Feb 17, 2012 at 09:42, Alexander, Daniel
>>><Daniel_Alexander at cable.comcast.com> wrote:
>>>> Hello All,
>>>>
>>>> The Staff and Legal review has been provided to the AC for prop-151.
>>>>The
>>>> review focused mainly on the 12 month needs assessment given that the
>>>> Board has recently ratified 2011-12 which changed the transfer needs
>>>> assessment to 24 months. This update and a few others are listed
>>>>below.
>>>>
>>>> Another change that has been suggested is to include transfers in the
>>>>12
>>>> month restrictions on the source of a transfer. The resulting text
>>>>would
>>>> read as follows.
>>>>
>>>> "The source entity 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."
>>>>
>>>> The intent of this change would be to limit an organization from
>>>> "flipping" transferred resources. Do people feel that this should be
>>>> incorporated into the text?
>>>
>>>This inclusion is absolutely mandatory to maintaining a needs-based
>>>system. As such, the question should be reversed: "Is there any reason
>>>to exclude transfers, when allocations and assignments are counted?"
>>>
>>>Cheer,
>>>~Chris
>>>
>>>> All feedback is appreciated.
>>>>
>>>> Dan Alexander
>>>> AC Shepherd
>>>>
>>>>
>>>> Changes to prop-151 text:
>>>>
>>>> - Restored a needs requirement to the text.
>>>> - Eliminated the /12 cap on resources received.
>>>> - Removed the suggestions to altering the text of the RSA.
>>>> - Removed the section regarding "Conditions on the IPv4 address
>>>>block".
>>>> - Revised the condition of space being administered by ARIN to
>>>>incorporate
>>>> inter-RIR transfers as a result of 2011-1.
>>>> - Moved the minimum transfer size requirement down to remaining
>>>>Conditions.
>>>> - Separated in-region and inter-region transfers into separate
>>>>sections.
>>>> - Clarified the starting point of the 12 month restrictions as a
>>>>result
>>>>of
>>>> staff feedback.
>>>> - Changed the proposal title from "Limiting needs..." to "Clarifying
>>>> Requirements..." as a result of feedback.
>>>> - Updated needs requirement from 12 to 24 months as a result of
>>>>2011-12.
>>>>
>>>>
>>>>
>>>> Current text:
>>>>
>>>> Replace Section 8.3 with
>>>>
>>>> 8.3 Transfers between Specified Recipients within the ARIN Region.
>>>>
>>>> In addition to transfers under section 8.2, IPv4 numbers resources may
>>>>be
>>>> transferred according to the following conditions.
>>>>
>>>> Conditions on source of the transfer:
>>>>
>>>> * The source entity must be the current registered holder of the IPv4
>>>> address resources, and not be involved in any dispute as to the status
>>>>of
>>>> those resources.
>>>> * 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.
>>>> * The source entity must not have received an allocation or assignment
>>>>of
>>>> IPv4 number resources from ARIN for the 12 months prior to the
>>>>approval
>>>>of
>>>> a transfer request.
>>>> * The minimum transfer size is a /24
>>>>
>>>>
>>>> Conditions on recipient of the transfer:
>>>>
>>>> * The recipient must demonstrate the need for up to a 24 month supply
>>>>of
>>>> IP address resources under current ARIN policies and sign an RSA.
>>>> * The resources transferred will be subject to current ARIN policies.
>>>>
>>>>
>>>> Add Section 8.4 Inter-RIR Transfers to Specified Recipients
>>>>
>>>> Inter-regional transfers may take place only via RIRs who agree to the
>>>> transfer and share reciprocal, compatible, needs-based policies.
>>>>
>>>> Conditions on source of the transfer:
>>>>
>>>> * The source entity must be the current rights holder of the IPv4
>>>>address
>>>> resources recognized by the RIR responsible for the resources, and not
>>>>be
>>>> involved in any dispute as to the status of those resources.
>>>> * Source entities outside of the ARIN region must meet any
>>>>requirements
>>>> defined by the RIR where the source entity holds the registration.
>>>> * Source entities within the ARIN region will not be eligible 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.
>>>> * Source entities within the ARIN region must not have received an
>>>> allocation or assignment of IPv4 number resources from ARIN for the 12
>>>> months prior to the approval of a transfer request.
>>>> * The minimum transfer size is a /24.
>>>>
>>>>
>>>> Conditions on recipient of the transfer:
>>>>
>>>> * The conditions on a recipient outside of the ARIN region will be
>>>>defined
>>>> by the policies of the receiving RIR.
>>>> * Recipients within the ARIN region will be subject to current ARIN
>>>> policies and sign an RSA for the resources being received.
>>>> * Recipients within the ARIN region must demonstrate the need for up
>>>>to
>>>>a
>>>> 24 month supply of IPv4 address space.
>>>> * The minimum transfer size is a /24
>>>>
>>>> Rationale:
>>>>
>>>> The original text of this proposal attempted to simplify the
>>>>requirements
>>>> of an IPv4 address transfer while protecting any resources in the ARIN
>>>> free pool. This revision is a result of feedback from the mailing
>>>>list,
>>>> and discussions with the original author. The one key point that has
>>>>been
>>>> removed from the original text is that a needs based review remains in
>>>> place.
>>>>
>>>> The current text attempts to retain the original concepts of
>>>>protecting
>>>> any ARIN free pool, and incorporating it with the point of bringing
>>>> resources under RSA. The resulting text attempts to put safeguards in
>>>> place on the practice of paid transfers by creating a black out period
>>>>for
>>>> requests from the free pool. The text also tries to incorporate
>>>> discussions regarding inter-RIR transfers and come up with language
>>>>that
>>>> includes the free pool protections for transfers in and out of the
>>>>Region.
>>>>
>>>> Timetable for implementation: immediate.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 info at arin.net if you experience any issues.
>>>
>>>
>>>
>>>--
>>>@ChrisGrundemann
>>>http://chrisgrundemann.com
>>
>> _______________________________________________
>> 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 info at arin.net if you experience any issues.
>
>
>
>-- 
>@ChrisGrundemann
>http://chrisgrundemann.com