Draft Policy ARIN-2017-1: Clarify Slow Start for Transfers [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: Abandoned
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 21 March 2017
Origin - ARIN-prop-237
Draft Policy -21 March 2017
Abandoned -20 June 2017
ARIN Public Policy Meeting:
ARIN Advisory Council:
AC Shepherds:
Andrew Dul, Alison Wood
ARIN Board of Trustees:
Revisions:
Revised - 3 May 2017
Implementation:
Version Date: 03 May 2017
Problem Statement:
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.
Problem Discussion:
In a pre-transfer world ISPs who are growing rapidly, or have no history of utilization to support their IPv4 two year growth requirements, could qualify under slow start.
The initial block was either a small block (between /24 and /21), or double what they efficiently used in the previous year. If thate space was used in less than a year, they could get twice as much the next time.
The implementation of Policy 2016-5 severs transfer policy form section 4 where the slow start rules are defined. As a result it is unclear if the slow start process can be used to justify a specified transfer.
Additionally, the inability to complete regular transfers could lead to a situation where lack of IPv4 addresses is rate limiting deployment. As a result demonstrated utilization of the last 12 months may not be indicative of actual growth.
NRPM 8.5.3 / 8.5.4 (ARIN Policy 2016-4) supports an initial block of only a /24 if there is no allocation or assignment.
Policy Proposal 2016-3 (the sister policy to 2016-4) supports a larger block (after demonstration of efficient utilization) equal to their current holdings up to a /16 every 6 months.
Because 2016-3 no longer permits using a /16 at a time and demonstrating utilization before coming back for another, organizations who are growing at more than a /15 a year are forced to use the two year forward looking projected growth as justification.
This prediction is difficult to measure, difficult to justify, difficult to verify, and provides unpredictability to the amount of time a justification requires to be processed, and the likelihood of approval. This process favors organizations who more aggressively optimistic and has no penalty if an organization fails to meet their plans.
Problem solution:
Permit organizations who demonstrate efficient utilization to use the utilization of their most recent specified transfer(s) to extrapolate a two year growth projection allowing a specified transfer of up to double the size of the transfers used in the justification.
Policy statement:
Current policy:
8.5.5. Block size
Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
Proposed changes:
Add the following to the end of 8.5.5:
Organizations may demonstrate a 24 month future projection based on the average amount of time required to efficiently utilize one or more of their most recent specified transfers.
The organization must show efficient utilization of at least 50% of all specified transfers from the current date back to the the date of the earliest specified transfer included in the request. The organization will be pre-authorized for a two year window to complete one or more specified transfers up to the total number of IPv4 addresses of the transfers included in the request, divided by the number of days (no less than 90) since the earliest specified transfer included in the request was completed, multiplied by 730.
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.
Comments:
Timetable for implementation: Immediate
##########
Earlier Version
###########
Version Date: 21 March 2017
Problem Statement:
With the adoption of 2015-5, transfer policy is severed from ARIN allocation / assignment policy. It is no longer clear how slow start applies (if at all) to justifying a transfer. Having a slow start algorithm available to the transfer market will make for a more predictable and more right sized blocks in line with organizational growth.
Problem Discussion:
In a pre-transfer world ISPs who are growing rapidly, or have no history of utilization to support their IPv4 two year growth requirements, could qualify under slow start.
The initial block was either a small block (between /24 and /21), or double what they efficiently used in the previous year. If thate space was used in less than a year, they could get twice as much the next time.
The implementation of Policy 2016-5 severs transfer policy form section 4 where the slow start rules are defined. As a result it is unclear if the slow start process can be used to justify a specified transfer.
Additionally, the inability to complete regular transfers could lead to a situation where lack of IPv4 addresses is rate limiting deployment. As a result demonstrated utilization of the last 12 months may not be indicative of actual growth.
NRPM 8.5.3 / 8.5.4 (ARIN Policy 2016-4) supports an initial block of only a /24 if there is no allocation or assignment.
Policy Proposal 2016-3 (the sister policy to 2016-4) supports a larger block (after demonstration of efficient utilization) equal to their current holdings up to a /16 every 6 months.
Because 2016-3 no longer permits using a /16 at a time and demonstrating utilization before coming back for another, organizations who are growing at more than a /15 a year are forced to use the two year forward looking projected growth as justification.
This prediction is difficult to measure, difficult to justify, difficult to verify, and provides unpredictability to the amount of time a justification requires to be processed, and the likelihood of approval. This process favors organizations who more aggressively optimistic and has no penalty if an organization fails to meet their plans.
Problem solution:
Permit organizations who demonstrate efficient utilization to use the utilization of their most recent specified transfer(s) to extrapolate a two year growth projection allowing a specified transfer of up to double the size of the transfers used in the justification.
Policy statement:
Current policy:
8.5.5. Block size
Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN.
Proposed changes:
Add the following to the end of 8.5.5:
Organizations may demonstrate a 24 month future projection based on the average amount of time required to efficiently utilize one or more of their most recent specified transfers.
The organization must show efficient utilization of at least 50% of all specified transfers from the current date back to the the date of the earliest specified transfer included in the request. The organization will be pre-authorized for a two year window to complete one or more specified transfers up to the total number of IPv4 addresses of the transfers included in the request, divided by the number of days (no less than 90) since the earliest specified transfer included in the request was completed, multiplied by 730.
Comments:
Timetable for implementation: Immediate
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.