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

Fri Jan 13 12:08:07 EST 2012

Thanks Mike.

Just wanted to clarify that we would like to hear from Bill H. to ensure
we are addressing his concerns and his thoughts on that.

Thanks

On 1/13/12 11:53 AM, "Mike Burns" <mike at camplink.net> wrote:

>Yes, it's been watered down with the requirement for a needs test by
>ARIN,
>this is something I don't like, but still the proposal has some
>protections
>of the free pool which I think are necessary in order to get 2011-1 or
>something similar passed.
>
>One of the underlying reasons for my proposal was an attempt to bring
>together legacy and non-legacy addresses by reducing RSA restrictions,
>but
>this may be biting off too much in one proposal.
>
>I support free(er) trade of IPv4 addresses, and the proposal as modified
>still moves  us in that direction.
>
>I tried to introduce the idea of restrictions on accessing the free pool
>for
>those involved in the transfer market, because of the risk of plundering
>the
>free pool for profit.
>
>I support the modified proposal and thank Dan for his efforts to move it
>along through compromise.
>
>Regards,
>Mike
>
>
>-----Original Message-----
>From: Sweeting, John
>Sent: Friday, January 13, 2012 11:37 AM
>To: Chris Grundemann ; Alexander, Daniel
>Cc: arin-ppml at arin.net
>Subject: Re: [arin-ppml] Prop-151: Limiting needs requirements for
>IPv4transfers
>
>Really good feedback Chris and thanks to Dan as well. I believe that Dan
>has been working with Mike Burns and they have an understanding on the
>needs based issue but it would be great if Mike or Dan could confirm that.
>I would really like to have input from Bill H. on this so we can be sure
>we are working in the right direction. I welcome everyone to take the time
>to provide thoughts and input as the time line for Vancouver is starting
>to get very short. Thanks.
>
>
>++
>
>On 1/13/12 11:05 AM, "Chris Grundemann" <cgrundemann at gmail.com> wrote:
>
>>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
>>_______________________________________________
>>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.
>
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for
>the use of the individual or entity to which it is addressed. If you are
>not
>the intended recipient of this E-mail, you are hereby notified that any
>dissemination, distribution, copying, or action taken in relation to the
>contents of and attachments to this E-mail is strictly prohibited and may
>be
>unlawful. If you have received this E-mail in error, please notify the
>sender immediately and permanently delete the original and any copy of
>this
>E-mail and any printout.
>_______________________________________________
>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.
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.