[arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow Start and Simplified Needs Verification

[Jason Schiller]

Mike,

I think these are good questions for each of us to think about.

Why there is a need to separate the needs policy for transfers from the
needs policy for ARIN IP space?
What is it about transfers that changes justifiable need of recipients?
Is there any difference between free-pool and transferred addresses?
Why do you support dramatically simplifying the needs test policy now?

I think these questions are useful to help us consider if we need to depart
from the status quo.

I think there are issues with the status quo.
How to deal with slow start
  - can't assume the upstream can or will provide addresses
How to reduce the burden of multiple transfers
  - multiple transfers are much more time intensive than multiple ARIN
allocations / assignments
  - there is a higher per transaction overhead cost
How to reduce the problems of over issuing
  - reclaiming is problematic in the transfer space, how do you deal with
the exchange of money.
  - what was the price when the deal was inked, what is the price now, who
is responsible for the difference?

These reasons are the essential differences between transfer space and ARIN
space.

I do not believe there is a need to separate justified need for transfer
policy and justified need for ARIN issued resources.  I feel that the
community is pushing to have them separated.

I also think the community recognizes there are issues with the transfer
policy (most clearly how does slow start work), and are more willing to
accept changes.  I think the community has less of a willingness to change
justified need wrt ARIN issued resources, partly on the grounds that
changing it now feels unfair, like changing the rules of the game when we
are all so close to the finish line, especially when organizations have may
plans within the time horizon that these rules do not change.

In short it less controversial to make changes to needs justification of
transfers than of ARIN issued space.

As to why now?  I think it would be best to sort this out before ARIN
begins telling members that while they do qualify for what they have asked
for, ARIN is unable to issue a block of that size.

I think we have 1-2 meetings before that happens, and it may take that long
to close discussion on this topic.


___Jason



On Mon, Sep 15, 2014 at 4:07 PM, Mike Burns <mike at iptrading.com> wrote:

>   Scott wrote:
>  It seems to me that this proposal actually simplifies things a lot more
> than it appears at first glance.  Obviously it expands section 8 with a lot
> more words.  But it does so in order to almost completely remove the
> dependencies on section 4 (leaving just a reference to the minimum
> allocation size).  So once the ARIN free pool is exhausted, that will mean
> that the policy under which most people get IPv4 space will be dramatically
> simpler than it is today.  It will also open up the way to dramatically
> simplifying section 4 after free pool exhaustion.
>
> I haven't yet worked through all the situations I can think of to make
> sure this is better than current policy in all cases, but on first pass it
> appears to me to be a significant improvement on the status quo.
>
> -Scott
>
>
> Hi Scott and Jason,
>
> Maybe it would help to understand WHY there is a need to separate the
> needs policy for transfers before we endeavor to create an all-new and
> separate policy.
> What is it about transfers that changes justifiable need of recipients?
> Is there any difference between free-pool and transferred addresses?
> Is it the $500 transfer fee?
> Why do you support dramatically simplifying the needs test policy now?
>
> My understanding is that we chose to utilized the existing needs regime
> for transfers, but extended the horizon from 3 to 24 months for the
> purposes of providing some incentive to get the STLS system operational. Or
> was it some other reason?
> If there is some qualitative difference between transfers and free pool
> allocations, why is there an RFC2050 principle requiring needs tests for
> transfers as well as free pool allocations?
>
> My answers to these questions have been offered, and I believe they are
> consistent with the thought processes at the time of RIR creation:
> "We are responsible for growing the Internet through dissemination of IP
> addresses.
> We want to give addresses out, we want to grow the Internet, but we can't
> just allow anybody to take all the addresses."
> So, RFC2050 required needs testing of allocations to prevent plunder of
> the free pool.
> RFC2050 also required needs tests for transfers, because without them,
> there would be plunder of the free pool.
>
> But conservation is a natural mechanism of a market, and the price of
> transferred IPv4 addresses imposes a natural conserving force absent from
> the RFC2050 environment.
> That is why there is in fact a qualitative difference between free pool
> and transfer addresses. The one has no natural conservation force and
> requires the needs test. The other has a natural conservative force which
> does not require the needs test.
>
> That is my rationale for 2014-14, which removes needs tests from small
> transfers. It has the benefit of addressing all the scenarios addressed by
> 2014-20, and does so in a more streamlined fashion.
>
> TL'DR:
> What is the rationale behind 2014-20's call for a different needs test for
> transfers versus free pool allocations?
> Didn't we have small, medium, large, slow growing, fast growing, and every
> other business scenario in the past?
>
> Regards,
> Mike
>
>
>
>
>
>
>
>
>
>
> On Sat, Sep 13, 2014 at 5:34 AM, Mike Burns <mike at iptrading.com> wrote:
>
>>  Hi Jason,
>>
>>
>>
>>
>>  However, assuming that 2014-14 is discussed first and does not pass,
>> would you still oppose 2014-20?
>>
>> Possibly.
>>
>>
>> Would you agree that 2014-20 a movement in the direction as it is in the
>> middle ground between current needs based and transfers without need?
>>
>> It seems like you are removing the 24month distinction between transfers
>> and free pool allocations and replacing it with a more complex, although
>> possibly more expansive mechanism. I would have to consider more analysis
>> of the various scenarios and balance my support against my opposition to
>> NRPM bloat and transfer policy complexity.
>>
>> Would you agree that while 2014-20, in your opinion does not go far
>> enough, it is still better than the status quo?
>>
>> Well the status quo has changed, with minimums reduced to /24, and I have
>> not had time to analyze sufficiently. One of the real problems I had
>> encountered with transfers was related to the /20 minimum and I have not
>> had problems with transfers due to explosive growth. Unfortunately!
>>
>>
>> 2014-20 does in fact separate the needs test for transfers from the needs
>> test for ARIN allocations and assignments.
>> WRT transfers, at any time, an org that can demonstrate 80% utilization
>> on average across all their IP space, is eligible to completed 1 or more
>> transfer and up to double their holdings.  This is very different from
>> demonstrating 80% utilization of your most recent block, and efficiently
>> using all your older IP space, and only getting double what you used in the
>> last 12 months.
>>
>> This however does not help orgs with no resources 2*0=0, nor does it help
>> orgs that have a history of slow growth with recent rapid growth.
>>
>> To help orgs that have no resources, I wanted to make it fairly easy for
>> them to get what ever the minimum assignment/allocation is (the only tie
>> back to ARIN issued IP space) up to a /24 for end-sites and up to a /21 for
>> ISPs.  I wanted at the same time to disqualify orgs that have no actual
>> plan on having stuff to number.  Once they get their initial space that can
>> use it to 80% and then double, us that to 80%, and double again, and so on.
>>
>> For orgs with only recent rapid growth, and for new orgs who don't want
>> to keep doubling, they can choose a look back window between 3 and 12
>> months, and calculate a two year supply.
>>
>> So a new org may transfer in a /24, show 80% utilization after 45 days,
>> transfer in an additional /24, show 80% utilization of both blocks after 90
>> days, and then qualify to transfer in up to the equivalent of  16 * /24s.
>>
>> __Jason
>>
>>
>> It sounds better to me than the current system, but I definitely prefer
>> 2014-14. My concern is that whenever verbiage is added to the NRPM it opens
>> new doors to misinterpretation which have to be addressed through more
>> verbiage. In addition, whenever new issues or problems are discovered when
>> applying this new mechanism to different business-case scenarios, more
>> verbiage would be necessary to restore "fairness". And considering the
>> myriad ways that businesses can find themselves in need of IPv4 space I
>> think we are taking the first steps down a dangerous path with your
>> proposal. On the other hand 2014-14 addresses the needs of fast and slow
>> growing companies, and the needs of small companies, with less of this
>> danger and less risk of out-of-policy transfers which hold their own
>> separate dangers.
>>
>> Regards,
>> Mike
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 12, 2014 at 1:19 PM, Mike Burns <mike at iptrading.com> wrote:
>>
>>>   Hi Jason,
>>>
>>> I apologize for not commenting on this earlier, I decided to sit back
>>> and see what other input was received.
>>>
>>> I think that you have correctly identified in your problem statement
>>> certain issues we face at the near-exhaust stage and beyond.
>>> ARIN allocation policy was always premised on the free pool, and we have
>>> decided to borrow the same policy and apply it to the wholly new
>>> environment of a trading market.
>>>  You correctly identify issues like transactional costs which are
>>> imposed on recipients as a result of free-pool premised policies whose
>>> authors did not consider these implications.
>>> You note that ARIN policy does not efficiently accommodate various
>>> recipient growth profiles, especially as any wiggle-room is squeezed out of
>>> every allocation by a team of ARIN reviewers.
>>>
>>> We can expect more such problems as market forces tend to diverge from
>>> ARIN policy prescriptions, and it is my belief that the weight of these
>>> distortions puts a strain on Whois accuracy as more money flows into this
>>> market.  When business needs are faced-up against ARIN policy, at a certain
>>> point the business risk of inadequate allocation overrides the risk of an
>>> out-of-policy transfer. And these out-of-policy transfers can happen by
>>> multiple means, including phased-contracts, permanent leasing,  and zombie
>>> corporations which ARIN policy can't touch. ARIN policy is a market
>>> distortion which will likely grow larger over time.
>>>
>>> Rather than try to put our finger in the dyke through more and more NRPM
>>> verbiage, isn't it time we acknowledged that a separate allocation paradigm
>>> exists in the trading market which requires a separate (or absent)
>>> needs-test for transfers?
>>>
>>> I believe that every circumstance elucidated in your proposal is
>>> answered by the much more streamlined 2014-14, which removes needs testing
>>> from transfers smaller than a /16, once per year.
>>>
>>> I am against further un-necessary clutter in the NRPM, and if we seek to
>>> match every unknown and unknowable vagary of the impending transfer market
>>> with new policy, we open the door to a virtual tax code of text. Here is
>>> one of your new sections:
>>>
>>> 8.3.2.3.2.1 Calculation of Monthly Average Use Rate
>>> An organization may choose a look-back window of any number of months
>>> between 3 and 12, inclusive, from the date of the current request. ARIN
>>> will calculate the total amount of new addresses acquired, during the
>>> look-back window, by the organization from non-M&A transfers, direct
>>> allocations or assignments from ARIN, or reallocations or reassignments
>>> from an ISP. That total will be divided by the number of months in the
>>> look-back window to calculate the organization's monthly average use rate.
>>>
>>> 8.3.2.3.2.1?
>>>
>>> While I support the recognition of the problems Jason identified, I am
>>> opposed to 2014-20.
>>> (Also I would counsel against regarding silence as approval.)
>>>
>>> Regards
>>>
>>> Mike Burns
>>>
>>>
>>>  *From:* Jason Schiller <jschiller at google.com>
>>> *Sent:* Friday, September 12, 2014 12:13 PM
>>> *To:* owens at nysernet.org ; Kevin Blumberg <kevinb at thewire.ca> ; David
>>> Farmer <farmer at umn.edu>
>>> *Cc:* arin-ppml at arin.net
>>> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy
>>> Slow Start and Simplified Needs Verification
>>>
>>>   It has been a week, and there has been no discussion on this thread.
>>>
>>> I take the silence to mean the suggested "option 2" rewrite is
>>> non-controversial and meets all of Bill's concerns.
>>>
>>> I also take the silence to mean that all three options I have suggested
>>> all result in the same implementation,
>>> and since no one believes any of the three options differ in
>>> implementation, there is no preference.
>>>
>>> I humbly submit we should go with option 2, as it is closest to Bill's
>>> suggestion, and keeps 8.2 and 8.3 in line
>>> (setting the ground work for a future unification of 8.2 and 8.3).
>>>
>>> Will there be discussion now?  Or should we just silently move forward?
>>>
>>>
>>> Thanks,
>>>
>>> ___Jason
>>>
>>>
>>>
>>>
>>> On Thu, Sep 4, 2014 at 11:34 AM, Jason Schiller <jschiller at google.com>
>>> wrote:
>>>
>>>> Bill,
>>>>
>>>> Thank you.
>>>>
>>>> The intent was NOT to remove the requirement for in-region recipients
>>>> of transfers to sign an RSA.
>>>>
>>>> My apologies.
>>>>
>>>> There is a lot or parallel structure in 8.3 and 8.4 and in my mind 8.4
>>>> is identical to 8.3 except 8.4 has a clause "Except when the recipient
>>>> is out of region then that region's policy applies", and " Except when
>>>> the source is out of region then that region's policy applies".  I
>>>> really wanted to completely merge 8.3 and 8.4 to remove the parallel
>>>> structure but as an editorial re-write only and not part of this
>>>> discussion.
>>>>
>>>> in 8.4 there are a separate bullets for 24-month supply and sign the
>>>> RSA:
>>>> "> 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."
>>>>
>>>> I think in my mind I imagined a similar separate bullets in 8.3, one
>>>> for 24-month supply and another for sign RSA, and I intended just to remove
>>>> the 24 month part.
>>>>
>>>> I think there are a few ways to fix this.
>>>>
>>>>  Option 1 - minimun rewrtite
>>>> - remove only the "24-month" portion of the 8.3 text. This is the
>>>> minimum change, but brings section 8.3 and 8.4 further out of alignment
>>>>
>>>> Option 2 - single bullet for "meet ARIN policy" and "sign RSA" (8.3 as
>>>> the model text)
>>>> - replace the whole "24-month" text and "meet ARIN policy" text in 8.3
>>>> with a bullet that included "sign the RSA" and "meet ARIN policy" under one
>>>> bullet and is parallel to text in 8.4 (minus within the ARIN region)
>>>>
>>>> Option 3 - two separate bullets for "meet ARIN policy" and "sign RSA"
>>>> (8.2 as the model text)
>>>> - replace the whole "24-month" text in 8.3 with a bullet that included
>>>> "sign the RSA"
>>>> -separate the "sign the RSA" and "meet ARIN policy" in 8.4 into two
>>>> bullets and is parallel to text in 8.3 (plus the within ARIN region)
>>>>
>>>> (If the summary of the options are hard to follow I have a suggestion
>>>> for the specific rewrites below)
>>>>
>>>> I think your suggestion is roughly Option 2 below (the only difference
>>>> is with your suggested rewrite, there are now two bullets in 8.3 stating
>>>> the recipient is subject to current ARIN policies).  Assuming all the
>>>> options have the same policy implications, I would prefer option 2 or 3, as
>>>> these bring greater alignment of the sections.
>>>>
>>>> Do these options all meet your concern?
>>>>
>>>> Does the community and ARIN staff agree that the thee options have the
>>>> same policy implications?
>>>>
>>>>
>>>> Kevin, David,
>>>>
>>>> I think at this point you own the text?
>>>> I would be supportive of the friendly amendment to modify the draft
>>>> policy as follows:
>>>>
>>>>
>>>> OPTION 1:
>>>> Replace the following Section 8.3 text:
>>>>
>>>> "> 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."
>>>>
>>>> with:
>>>>
>>>> "> Recipients will sign an RSA for the resources being received."
>>>>
>>>>
>>>> OPTION 2:
>>>>
>>>>  Replace the following Section 8.3 text:
>>>>
>>>> "> 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.
>>>> "
>>>>
>>>> with:
>>>>
>>>>  "> Recipients will be subject to current ARIN policies and sign an
>>>> RSA for the resources being received."
>>>>
>>>> OPTION 3:
>>>>  Replace the following Section 8.3 text:
>>>>
>>>> "> 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."
>>>>
>>>> with:
>>>>
>>>> "> Recipients will sign an RSA for the resources being received."
>>>>
>>>> and replace the following Section 8.4 text:
>>>>
>>>> "> 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."
>>>>
>>>> With:
>>>>
>>>>  "> Recipients within the ARIN region will sign an RSA for the
>>>> resources being received.
>>>> > The resources transferred to recipients within the ARIN region will
>>>> be subject to current ARIN policies."
>>>>
>>>> If all the options are indeed the same I would prefer option 2 or 3.
>>>> If the options have different policy implications and we can converge
>>>> on one standard for both 8.2 and 8.3, then I would prefer that.
>>>>
>>>>
>>>> ___Jason
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 4, 2014 at 8:50 AM, Bill Owens <owens at nysernet.org> wrote:
>>>>
>>>>> On Wed, Sep 03, 2014 at 04:55:58PM -0400, ARIN wrote:
>>>>> > On 28 August 2014 the ARIN Advisory Council (AC) accepted
>>>>> > "ARIN-prop-212 Transfer policy slow start and simplified needs
>>>>> > verification" as a Draft Policy.
>>>>> >
>>>>> . . .
>>>>> >
>>>>> > Draft Policy ARIN-2014-20
>>>>> > Transfer Policy Slow Start and Simplified Needs Verification
>>>>> >
>>>>> > Date: 3 September 2014
>>>>> >
>>>>> . . .
>>>>> >
>>>>> > Policy statement:
>>>>> >
>>>>> > Remove the following section 8.3 text:
>>>>> >
>>>>> > "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."
>>>>>
>>>>> Shouldn't that be something like this, instead?
>>>>>
>>>>> Replace the following Section 8.3 text:
>>>>>
>>>>> "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."
>>>>>
>>>>> with:
>>>>>
>>>>> "The recipient will be subject to current ARIN policies and sign an
>>>>>   RSA for the resources being received."
>>>>>
>>>>> As written it appears to remove the requirement for recipients of
>>>>> in-region transfers to sign an RSA.
>>>>>
>>>>> Bill.
>>>>>  _______________________________________________
>>>>> 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.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> _______________________________________________________
>>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>>>
>>>>
>>>
>>>
>>> --
>>> _______________________________________________________
>>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>>
>>> ------------------------------
>>> _______________________________________________
>>> 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.
>>>
>>
>>
>>
>> --
>> _______________________________________________________
>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>>
>>
>> _______________________________________________
>> 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.
>>
>
>



-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140916/6d969e96/attachment.htm>