[arin-ppml] ARIN Draft Policy 2017-1: Clarify Slow Start for Transfers proposed updates
Jason Schiller
jschiller at google.com
Mon May 8 14:12:28 EDT 2017
Mike,
No need for apologizes on top posting...
your response are very clear and effective
1. yes, I agree, a forecast based on history is still a forecast.
And either type can equally lead to correct and wrong predictions.
These two statements are different:
I believe we will have more than 1 million customers by the end of 2018.
Since 01/2017 we have added 42,000 customers per month on average.
At this rate we will have more than 1 million customers by the end of
2018.
2. The community is split wrt what parts of section are needed to support
transfers.
Some suggested lowering efficiency to 50% would help to offset not
having a TPA policy.
3. I'm not sure I personally feel comfortable saying extra words that only
help a small
percentage of the members are a waste of space.
What percentage of requests fall under TPA?
I'd counter wrt community networks, the discussion was that the policy was
never used.
I wonder if staff has any insight as to how often slow-start type
justification is used
for transfers?
Can staff sort transfer authorization requests into the following
categorized?
A. Current Consumption Rate
Request considers only current rate, projected out over a time window.
- e.g. we used a /15 over the last 12 months. at this rate a /14 is a
two year supply.
B. Growth rate
Request considers current growth rate, projected over a time window.
- e.g. we used a /16 between 01/15 - 12/2015
we used a /15 over the last 12 months.
at this rate we double every year.
if we keep yearly doubling, then a /14 and a /13 is a two year
supply.
C. Hi bread
Request considers current growth rate, but requests more than the
current rate over some time horizon due to other reasons for
acceleration,
such as entry into new markets, increase in manufacturing of hand
sets, etc.
D. Future looking
Request is purely future looking.
- e.g. We anticipate the sale of 1 Million handsets over the next year.
50-80% of those handsets will use our application and require
an IP.
Do you see all of these types?
Is one type more dominate then the others?
Is one type more successful than others?
Does one type require more transaction time? more back and forth?
__Jason
On Mon, May 8, 2017 at 1:25 PM, Mike Burns <mike at iptrading.com> wrote:
> 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> 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 <(571)%20266-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/20170508/d41f2ead/attachment.htm>
More information about the ARIN-PPML
mailing list