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

Tue Feb 21 19:01:47 EST 2012

On Tue, Feb 21, 2012 at 16:28, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
>
> 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.

Thanks for the clarification. I still choose to place profiting from
the improper acquisition of ARIN managed resources in a single bucket
however. I believe that ARIN should act as steward for all number
resources within the region, not just those that have not been
previously handed out.

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

If the RSA and recipient review can control "flipping" why can they
not prevent "profiting"?

Cheers,
~Chris

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