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

[Owen DeLong]

On Feb 21, 2012, at 2:38 PM, Alexander, Daniel 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.
> 

I disagree. I hate it when the government plays these games and I see no
reason to enable them in IP address transfers.

Whether you get resource A and immediately sell resource B instead of
using resource B to fill the need for which you got A, or, get resource A
and sell it, it's still effectively flipping.

Just like when the government allocates lottery money to the schools
in order to get the ballot measure passed, then decreases other funding
for schools by the amount the lottery brings in.

If you receive addresses through any mechanism, you should not be able
to transfer excess addresses out for 12 months. ARIN should not be in the
business of providing free revenue to organizations from their existing
address resources.

> 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 think these are corner cases. I think that the flipping scenario is far more likely
as it has strong monetary incentives.

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

If the policy doesn't prohibit it, then, ARIN staff can't really use that as a basis
to reject them as a recipient.

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

Yeah, but, we put safe harbor all over the transfer stuff, so, the fact that they are
transferring it kind of makes them mostly immune to that.

Owen

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