[arin-ppml] Prop-151: Limiting needs requirements for IPv4 transfers

[Chris Grundemann]

Great work, thanks Dan! Comments inline, below.

Cheers,
~Chris

On Fri, Jan 13, 2012 at 01:12, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
> PPML,
>
> Do people think it is possible to consolidate the discussion of prop-151,
> and 2011-1 to achieve a productive end result? If we could use "limiting"
> to clarify rather than eliminate the issue of a needs-based requirement,
> what aspects of a transfer policy still needs work? Here is some revised
> text of prop-151 incorporating the discussions from the previous round.
> Can this be used to address any concerns with 2011-1? I am curious to know
> if this bulleted format is preferred over the current paragraph format of
> the existing section 8.3.

Yes, I think the bulleted format is preferable. In addition to my
personal preference, I have received comments in the past wrt other
policies from community members stating as much.

> -Dan Alexander
>
>
> Changes to the original prop-151 text:
>
> - Restored a needs requirement

While I agree with this, I wonder if we should do this in two separate
proposals. The intent of prop-151 (as per the title) is to limit the
needs requirement on transfers, are we overstepping by ignoring that
seemingly fundamental tenement of the originator's intent? I guess the
fundamental question is: Do we need to have the needs discussion again
or not?

> - Eliminated the /12 cap
> - Removed the suggestions to altering the text of the RSA.
> - Removed the section regarding "Conditions on the IPv4 address block".
> - Removed the condition of space being administered by ARIN to open the
> possibility of inter-RIR transfers.
> - Moved the minimum transfer size requirement down to remaining
> Conditions.
> - Separated in-region and inter-region transfers into separate sections.

I was initially opposed to this. Seeing it here I think it may provide
clarity and future flexibility. However, I still think that it may be
better to collapse the two parts into one section. In any case, I
think the best path forward is to work out the policy bits and then
decide on format.

> Resulting 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 the transfer, or until the exhaustion of ARIN's
> IPv4 space, whichever occurs first.
> * The source entity must not have received an allocation from
> ARIN for the 12 months prior to the transfer.

I think this should include assignments and transfers, and should be
limited to IPv4 addresses (ASNs and IPv6 should not disqualify an IPv4
number transfer). It would then read:

"The source entity must not have received an assignment, allocation,
or transfer of IPv4 number resources from ARIN for the 12 months prior
to the transfer."

> * The minimum transfer size is a /24
>
>
> Conditions on recipient of the transfer:
>
> * The recipient must demonstrate the need for up to a 12 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 compatible, needs-based policies.

Do we need to add a reciprocity requirement here? If yes, perhaps this
sentence would read:

"Inter-regional transfers may take place only via RIRs who agree to
the transfer, share compatible needs-based policies, and allow
transfers both into and out of their region."

> 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 the transfer, 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 from ARIN for the 12 months prior to the transfer.

Again, I think this should include transfers and be limited to IPv4
resources, similar to above:

"Source entities within the ARIN region must not have received an
assignment, allocation, or transfer of IPv4 number resources from ARIN
for the 12 months prior to the transfer."

> * 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
> 12 month supply of IPv4 address space.
> * The minimum transfer size is a /24
>
>
> _______________________________________________
> 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
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.net
www.coisoc.org