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

Mon May 8 12:27:12 EDT 2017

Comments in line.

On Wed, May 3, 2017 at 1:49 PM, Mike Burns <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:arin-ppml-bounces at arin.net] *On Behalf Of *WOOD
> Alison * DAS
> *Sent:* Wednesday, May 03, 2017 1:35 PM
> *To:* 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).
> 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/20170508/be641769/attachment.htm>