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

Thu Sep 18 22:01:04 EDT 2014

Below is a first try at brining MDN into 2014-20....

8.3.2.1.1 MDN Minimum Requirements

Organizations that have multiple discrete networks (MDNs) and do not
qualify under 8.3.2.1 may still qualify for a non-M&A transfer if the
organization can demonstrate 50% utilization on average, as measured under
section 4, across the aggregate of all addresses that are currently
allocated, assigned, reallocated, or reassigned to, or otherwise in use by,
the organization, and has one or more MDN(s) with at least 80% utilization
on average.  The organization must report the utilization of all MDNs
separately.

In these cases only the resources of the MDN(s) that are at our above 80%
utilization will be considered when determining the transfer size under
section 8.3.2.3

___Jason

On Thu, Sep 18, 2014 at 1:54 PM, Jason Schiller <jschiller at google.com>
wrote:

> David,
>
> I appreciate  your comments wrt if ARIN should accept a purely future
> looking 2 year projected growth.  I think that is at the heart of this
> proposal.
>
> My personal (ISP) experience is that ARIN allocations are always based on
> past usage, and if your 3 month need is greater than 1/4 your usage last
> year, then you are slow started, you get 1/4 of your last year's usage, and
> if you use it up in less than 1.5 months you get double, if you use it up
> in less than 3 months you get the same size block, and if you use it up in
> more than three three months you fall back to your current utilization over
> the last year.
>
> My personal End user experience has only been for things that currently
> exist (and the challenge of getting 25% of them numbered in 30 days, and
> 50% with in a year).
>
> I have asked ARIN staff if they do provide addressing on a future looking
> projection that is greater than the past utilization.
>
> I have completed no 8.3 / 8.4 transfers, and assumed the references to a
> 24 month need, and comply with current ARIN policies would make the
> transfer subject to the same needs test for ARIN allocations, except that
> the end result would result in a two year need, instead of a one quarter
> need.  You seem to suggest this is not the case.
>
> ARIN staff, can you comment on if you provide addressing on a future
> looking projection that is greater than the past utilization?
>
> I wonder what the intent of the originator?
>
> It seems this language comes from 2008-6.  "Number Resources may only be
> received under RSA in the exact amount which can be justified under ARIN
> resource-allocation policies.
>
> This was further modified in 2011-11 where we reduce ARIN
> allocations/assignments to 3 months, and moved the 1 year restriction from
> the ARIN allocation/assignment section 4 to the transfer section.  This
> yields the more familiar text:
>
> "...they can justify under current ARIN policies showing how the addresses
> will be utilized within 12 months."
> At the time there was some contrversiy for how need should be determined
> for transfers, but that portion of the policy was dropped.
> "not clear how "justified need" has been or should be determined, however
> this proposal no longer addresses this."
>
> My read is 2011-11 leave the previous needs test in place.
>
> This was immediately further modified by 2011-12 which simply extended the
> time from 12 to 24 months.
>
> It was modified by 2011-1 which removed and added ARIN specific language
> to separate intra-ARIN transfers, but did not change the intra-ARIN policy
> otherwise.
>
> 2012-1 broke the requirements down into bullets and added additional
> requirements that the organization providing the space for transfer is
> ineligible for additional space from ARIN for 12 months, and could not have
> received ARIN space 12 months prior to the transfer.  It also established a
> minimum of a /24.
>
> The text changed from:
>
> "Such transferred number resources may only be received uder RSA by
> organizations that are within the ARIN region and can demonstrate the need
> for such resources in the amount wihch they can justify under current ARIN
> policies showing how the addresses will be utilized within 24 months"
>
> to:
> "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."
>
> While the word "justify" is gone I believe the intent is still intact.
> There is some discussion in the rational that
> "The one key point that has been removed from the original text is that a
> needs based
> review remains in place."
>
> This refers to the original prop that added a clause to remove needs based
> reviews, which is not part of the adopted draft.
> this text that was dropped is:
> "and add to the NRPM Section 12:
> 10. ARIN will not use utilization as a measure of policy compliance
> for addresses transferred under 8.3."
>
> this was then further modified by 2012-3 but that just changed IP
> addresses to number resources...
>
> ------
>
> On the other topic of MDN and TPIA...
>
> This policy does not seek to change the definition of what counts as
> utilized.
> It is my impression that if a transit provider's down stream customer has
> 130 hosts, and is assigned a /24, that the transit provider can count all
> 256 of those IP addresses as utilized.
>
> The same is true about TPIA.  Those TPIA resources can be counted as fully
> utilized assuming the initial assignment is the smallest CIDR needed to
> serve the customer base, and additional assignments represent a 3 month
> supply.
>
> The same is true for residential market areas.  If the block assigned to
> the market area is at least 50% utilized, then all the addresses in the
> block can be counted as utilized.
>
> As such I do not think the proposal will limit organizations using these
> mechanism.
>
>
> MDN on the other hand, does lower the total utilization bar to 50% of the
> last block and on average, in order to allow for one discreet network to
> have just been topped up (and therefore under utilized) and allow another
> discreet network which is out, to get additional space.
>
> ___Jason
>
> On Wed, Sep 17, 2014 at 2:40 PM, David Huberman <
> David.Huberman at microsoft.com> wrote:
>
>> Kevin's very cogent call-outs were an eye opener for me.  TPIA has gotten
>> the short-shrift from ARIN policy for a long time, and it's a very complex
>> technical situation that needs careful thought.  MDN is a well-practiced
>> policy that applies to specific situations that need different rules.
>>  2014-20 as written inadvertently stomps on these.  That's fixable with
>> language changes, surely.
>>
>> But even before Kevin posted, I was concerned about the principles of
>> 2014-20. The position that ARIN policy should somehow trump an
>> organization's 24 month projections was big for me. Current 8.3 *as
>> implemented* gives flexibility to the network operator to buy needed IPv4
>> addresses with a reasonable and business-sane timeline for building out.
>> You build a forecast, you show it to ARIN staff during the 8.3 or STLS
>> process, and you go buy addresses to fill that need.
>>
>> 2014-20 seems to say "no, that's wrong. You can't have a 24 month supply
>> based on forecast; you have to show past performance" which is something I
>> don't agree with at all.  Needs basis should never be just looking
>> backwards.  That approach ROYALLY penalizes newer entrants, and ignores
>> networks which have irregular growth but recently did well with a product
>> offering and need to quickly deploy a lot of new capacity.
>>
>> Put this all together, and I find myself opposed to 2014-20.  I heartily
>> applaud Jason for trying to solve a good problem which needs solving. I
>> hope we can continue thinking and discussing solutions to a better solution
>> for post-exhaustion transfers.
>>
>> David R Huberman
>> Microsoft Corporation
>> Principal, Global IP Addressing
>>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Owen DeLong
>> Sent: Wednesday, September 17, 2014 11:25 AM
>> To: Kevin Blumberg
>> Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
>> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy Slow
>> Start and Simplified Needs Verification
>>
>> I haven't weighed in on this, but I will now.
>>
>> I remain opposed to the idea of uncoupling transfer policy from section
>> 4. There were good reasons we tied the original section 8 language to the
>> existing section 4 requirements and I believe that the extent to which we
>> have already uncoupled them has already had negative effects.
>>
>> The 3 month limit on free pool allocations to ISPs is proving to be very
>> dysfunctional. Creating incentives to move to the transfer market while a
>> free pool remains is beneficial only to those seeking to profit from the
>> IPv4 marketplace and does nothing to benefit the community overall.
>>
>> Yes, the slow start problems and some other problems need to be solved,
>> but we should be solving them with updates to section 4 so that they are
>> solved for both free pool and transfer applications.
>>
>> Owen
>>
>> On Sep 17, 2014, at 12:24 AM, Kevin Blumberg <kevinb at thewire.ca> wrote:
>>
>> > Jason,
>> >
>> > I'm specifically concerned about section 4.5 (Multiple Discrete
>> Networks) and 4.2.3.8 (Reassignments for Third Party Internet Access (TPIA)
>> over Cable).
>> >
>> > The criteria for those policies I see as being in conflict with the 80
>> percent aggregate utilization in 8.3.2.1 text.
>> >
>> > 8.3.2.1 Minimum requirements
>> > Prior to qualifying for non-M&A address transfers, an organization must
>> demonstrate an average of 80% utilization, as measured under section 4,
>> across the aggregate of all addresses that are currently allocated,
>> assigned, reallocated, or reassigned to, or otherwise in use by, the
>> organization.
>> >
>> > Thanks,
>> >
>> > Kevin
>> >
>> >
>> > From: Jason Schiller [mailto:jschiller at google.com]
>> > Sent: September 16, 2014 10:45 PM
>> > To: Kevin Blumberg
>> > Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
>> > Subject: Re: [arin-ppml] Draft Policy ARIN-2014-20: Transfer Policy
>> > Slow Start and Simplified Needs Verification
>> >
>> > Kevin,
>> >
>> > I am not sure I grasp the question.  If the organization is requesting
>> a direct allocation/assignment from  ARIN then they must qualify under
>> 4.x.  If the organization is requesting approval for transfer space, then
>> they must qualify under 8.x.
>> >
>> > I don't immediately see a case where you might qualify under 4.x but
>> not 8.x other than immediate need (I'll come to that shortly), but I'm
>> guessing you do, and we will need to deal with that.  Maybe something got
>> lost in leveling the playing field between ISP and End-user and if so I'm
>> ok with that (although maybe it should have tipped the other way).
>> >
>> > I consciously made "immediate need" different.  I think actually
>> deployment of in 30 days for ISPs or 25% in 30 days and 50% with in 1 year
>> is a bit burdensome, and I have heard that many Orgs ignore this.  I also
>> think it is problematic to size the block based purely on a future looking
>> projection with little recourse to correct things at the 30 day or 1 year
>> mark.  I wanted to put some teeth into it so I wanted proof of actual
>> things to number (maybe 50% is not the right figure).
>> >
>> > So what is the specific scenario you see?
>> >
>> > __Jason
>> >
>> > On Tue, Sep 16, 2014 at 10:07 PM, Kevin Blumberg <kevinb at thewire.ca>
>> wrote:
>> > Jason,
>> >
>> > In a situation that a request would be approved under a 4.x section,
>> but not in 8.x, which would take precedence?
>> >
>> > Thanks,
>> >
>> > Kevin Blumberg
>> >
>> > _______________________________________________
>> > 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.
>>
>> _______________________________________________
>> 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.
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140918/9c1dc91d/attachment.htm>