[arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates

Mon May 8 13:25:42 EDT 2017

Hi Jason,

Sorry for the top-post, but I will be short with three points.

1.       A forecast based on history is still a guess

2.       We don’t need ANY of section 4 in section 8 because free pool <> transfers

3.       Maybe we could do a show-of-hands ala the community networks rule to see if this matters to anybody, because if it matters to very few people (2%?) and if there is a workaround, then IMO we shouldn’t waste NRPM space on it. 

Regards,

Mike

From: Jason Schiller [mailto:jschiller at google.com] 
Sent: Monday, May 08, 2017 12:27 PM
To: Mike Burns <mike at iptrading.com>
Cc: WOOD Alison * DAS <Alison.WOOD at oregon.gov>; arin-ppml at arin.net
Subject: Re: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates

Comments in line.

On Wed, May 3, 2017 at 1:49 PM, Mike Burns <mike at iptrading.com <mailto:mike at iptrading.com> > wrote:

Hi Alison,

We have done 400+ transfers and have never heard of this problem from any buyer.

1. Going forward, organizations requiring a /15 or less per year would likely just use the simplified 

doubling approach (2016-3) , as such this policy proposal would not be helpful 

(and current policy not a problem).

2. This problem would only impact organizations that are large enough to have their own relationship with 

ARIN.   The organization's internal struggle with creating a justification that they can stand behind, 

and meet ARIN requirements would generally be kept internal to such an organization.  I expect

these organizations would have already secured pre-approval prior to engaging an outside organization

to complete a transfer.

3. This problem has only emerged since the implementation of ARIN-2016-6 which occurred on 

02/21/2017.  Transfers prior to this date could have been justified under slow start in section 4.

- How many of the 400+ transfers has the approval been completed post 02/21/2017?  

- Of those, how many transfer are larger than a /16? 

 (or the transfer in question brings the org to over a /15 worth of transfers in the previous

  1 year rolling window)

- Of those, how many have you consulted on putting together the justification for transfer approval?

So yes, I am not surprised that in your 400+ transfers you have not seen this as an issue.  

Thant doesn't mean it is not an issue.   

While I expect that well over 90% will make use of either NRPM 8.5.4 or 2016-3 

(maybe even as Owen suggests 2016-3 "obviates the need for [2017-1] by and large."),

there are still a small number of requests that are for larger than a /15 per year.

To not address that small amount of requests suggests we as a community do not

care about their need.

Prior to  02/21/2017 those requests had the option to base their two year need solely

on the recent past consumption rate.  These requests will now be forced to use a 

purely future looking projection, with no clear guidance on what justification ARIN 

will accept, or how much additional information, back and forth discussion, and time

will be required, nor the ability to predict the likelihood that a request should or should

not be approved.

Google is a data driven company. 

In a data driven company it may be easier to simply base a future looking growth on a

real measure of current consumption rate, knowing that this will necessarily result in a

short fall because you are only requesting IP addressed based on the current rate, and

not the current growth rate.  

In the absence of real data, people will often guess.  Some people guess better, some 

worse.  Some guesses are based on intricate algorithms, real data, and Fermi maths, 

others are just what feel right.  Either type can be multiple orders of magnitude off, or 

in the right ballpark.

Do we really want to encourage data driven companies who previously requested less IP

space then they needed because their requests have always been based on a real 

measure of consumption, and not addressing speculative growth, to instead require them

to guess about the future?  Especially noting that if they guess too low, the penalty is

running out of IPs, and if they guess to high there is no penalty (except if they buy a 

surplus and end up with IPs that were bought which go unused)?  

Buyers are far more concerned with ensuring supply and what it will cost.

I don’t see the value in more Section 8 clutter.

I would encourage you to no think of this as more clutter in section 8, but rather addressing 

a justification that was previously support under section 4, and now has to be mirrored into

section 8 to continue to support the legitimacy of this type of a request in order to address

over-pruning. 

Anybody in the world with any sort of concern about demonstrating need by whatever arcane formula can avail themselves of the needs-free policy in RIPE.

Open an account there, buy what you need, use them anywhere. Plus no transfer fees! 

That’s the workaround.  Even better would be to address this problem through excision of the needs test from ARIN transfer policy, rendering the NRPM  simpler, easier to use, and less cluttered by pointless artifacts from the free-pool era.

We attempted this with 2016-3 where the needs justification was simplified, and it has 

been addressed for those organizations that need less than a /15 per year.

Initially there was no cap on this proposal, but the community pushed back, and said 

we don't need to make things more simple for large organizations.  That, and a severing

transfers from section 4 resulted in removal of the option to use slow start.

So now we have to deal with adding slow-start complexity (for large ISPs) to transfer

policy.

Please note, this does not add any new required test, nor would it force anyone who

qualifies under the current policy to get rejected.

If you oppose this on the grounds of less clutter, then I suggest you should have 

provided more support for moving 2016-3 forward without a cap.

___Jason

So I don’t support the proposal in its revised form.

Regards,
Mike Burns

From: ARIN-PPML [mailto: <mailto:arin-ppml-bounces at arin.net> arin-ppml-bounces at arin.net] On Behalf Of WOOD Alison * DAS
Sent: Wednesday, May 03, 2017 1:35 PM
To:  <mailto:arin-ppml at arin.net> arin-ppml at arin.net
Subject: [arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates

The ARIN Draft Policy 2017-1 shepherds working with the original author have updated the problem statement and added clarification to section 8.5.5.  The AC would like feedback on the proposed updated problem statement and modification to 8.5.5. We encourage community members to comment on the proposed updates.  

Problem Statement (revised):

Some number of organizations may be uncomfortable making speculative forward projections (that are now required under NRPM section 8 for purposes of transfer request approval) and prefer that there be available a more certain approach based solely on extrapolation of their existing IPv4 number usage trend.

And adding the following text to the end of 8.5.5

Organizations may qualify for an additional block by using a projection of their address use from 6-24 months of allocations or assignments just prior to the transfer request.

Thank you!

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto: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 <mailto:info at arin.net>  if you experience any issues.

-- 

_______________________________________________________

Jason Schiller|NetOps| <mailto:jschiller at google.com> jschiller at google.com|571-266-0006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170508/49929855/attachment.htm>