[arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests

[Ted Mittelstaedt]

Scott Leibrand wrote:
> Good point.  I wonder if that would be covered by the existing clause 
> that "ARIN will fulfill requests on a first-approved basis, subject to 
> the size of each available address block and a re-validation of the 
> original request"?  

Oops, I didn't notice that.

> If contact fails, then I'd say that re-validation 
> fails as well.
> 

Yup.

> Thoughts?
> 

Well, other than the obvious thought that I can just see some
prankster putting in a /8 request, with justification, after runout,
just for the fun of it.

Ted

> I'll go ahead and add a FAQ on this as well.
> 
> Thanks,
> Scott
> 
> On 1/28/2010 1:29 PM, Ted Mittelstaedt wrote:
>> My only comment to the AC on this is I think that you need to give ARIN
>> the ability to pull a request off the waiting list if they can no longer
>> reach the requester.  If a request on the list languishes for years,
>> it may only be satisfied once the Internet has shifted from IPv4 to IPv6
>> and orgs are abandoning IPv4 is droves - and at that time if they cannot
>> reach the requester, it seems that the request will then be in limbo.
>>
>> Ted
>>
>> Member Services wrote:
>>> Draft Policy 2010-1
>>> Waiting List for Unmet IPv4 Requests
>>>
>>> On 15 January 2010 the ARIN Advisory Council (AC) selected "Waiting List
>>> for Unmet IPv4 Requests" as a draft policy for adoption discussion on
>>> the PPML and at the Public Policy Meeting in Toronto in April.
>>>
>>> The draft was developed by the AC from Policy Proposal "97. Waiting List
>>> for Unmet IPv4 Requests". Per the Policy Development Process the AC
>>> submitted text to ARIN for a staff and legal assessment prior to its
>>> selection as a draft policy. Below the draft policy is the ARIN staff
>>> and legal assessment, including the original proposal text.
>>>
>>> Draft Policy 2010-1 is below and can be found at:
>>> https://www.arin.net/policy/proposals/2010_1.html
>>>
>>> You are encouraged to discuss Draft Policy 2010-1 on the PPML prior to
>>> the April Public Policy Meeting. Both the discussion on the list and
>>> at the meeting will be used by the ARIN Advisory Council to determine
>>> the community consensus for adopting this as policy.
>>>
>>> The ARIN Policy Development Process can be found at:
>>> https://www.arin.net/policy/pdp.html
>>>
>>> Draft Policies and Proposals under discussion can be found at:
>>> https://www.arin.net/policy/proposals/index.html
>>>
>>> Regards,
>>>
>>> Member Services
>>> American Registry for Internet Numbers (ARIN)
>>>
>>>
>>> ## * ##
>>>
>>>
>>> Draft Policy 2010-1
>>> Waiting List for Unmet IPv4 Requests
>>>
>>> Version/Date: 21 January 2010
>>>
>>> Policy statement:
>>> Replace 4.1.6 with:
>>>
>>> 4.1.6. Aggregation
>>>
>>> In order to preserve aggregation, ARIN attempts to issue blocks of
>>> addresses on appropriate "CIDR-supported" bit boundaries. As long as
>>> sufficient space is available, ARIN may reserve space to maximize
>>> aggregation possibilities. ARIN will make each allocation and assignment
>>> as a single continuous range of addresses.
>>>
>>> Add new section 4.1.8:
>>>
>>> 4.1.8 Unmet requests
>>>
>>> In the event that ARIN does not have a contiguous block of addresses of
>>> sufficient size to fulfill a qualified request, ARIN will provide the
>>> requesting organization with the option to either modify their request
>>> and request a smaller size block, or be placed on a waiting list of
>>> pre-qualified recipients. Repeated requests, in a manner that would
>>> circumvent 4.1.6, are not allowed: an organization may only receive one
>>> allocation, assignment, or transfer every 3 months, but ARIN, at its
>>> sole discretion, may waive this requirement if the requester can
>>> document an unforeseen change in circumstances since their last request.
>>> Qualified requesters whose request cannot be immediately met will also
>>> be advised of the availability of the transfer mechanism in section 8.3
>>> as an alternative mechanism to obtain IPv4 addresses.
>>>
>>> 4.1.8.1 Waiting list
>>>
>>> The position of each qualified request on the waiting list will be
>>> determined by the date it was approved. Each organization may have one
>>> approved request on the waiting list at a time.
>>>
>>> 4.1.8.2 Fulfilling unmet needs
>>>
>>> As address blocks become available for allocation, ARIN will fulfill
>>> requests on a first-approved basis, subject to the size of each
>>> available address block and a re-validation of the original request.
>>> Requests will not be partially filled. Any requests met through a
>>> transfer will be considered fulfilled and removed from the waiting list.
>>>
>>> 8. Rationale:
>>>
>>> ARIN will soon be unable to meet all approved requests for IPv4 address
>>> space. In the absence of a policy like this, it is unclear what ARIN
>>> should do with subsequent requests.
>>>
>>> This policy would allocate reclaimed address blocks (and the last of the
>>> ARIN free pool) on a first-come-first-served basis, while preserving
>>> aggregation to the degree possible. As the free pool shrinks, requests
>>> larger than the largest block left would be placed on a waiting list,
>>> while smaller requests would use up the rest of it, until all requests
>>> have to go on the waiting list. As additional reclaimed addresses become
>>> available, the requests that have been waiting the longest would be met
>>> first. If a requester gets the addresses they need via transfer, then
>>> they would be removed from the waiting list and would need to wait and
>>> submit a new request for additional address space, either directly or
>>> via transfer.
>>>
>>> FAQ:
>>>
>>> Q1: The effect of 2009-8, if implemented by the Board, is to allow
>>> transfers to be up to a 12 month supply of resources and up to a 3 month
>>> supply for resource from the ARIN free pool. Does that jive with your
>>> intent for this policy?
>>>
>>> A1: Correct. After we get to the last /8, you can request up to a
>>> 3-month supply from the free pool, but only every 3 months unless you
>>> can document an unforeseen change in circumstances since your last
>>> request. However, if you get the space via transfer, you can get a block
>>> big enough for 12 month's need, and if you end up using it up faster,
>>> you can submit another request after 3 months.
>>>
>>> Q2: If I were on the waiting list, and subsequently received a transfer
>>> via 8.3, would I be removed from the waiting list?
>>>
>>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer
>>> will be considered fulfilled and removed from the waiting list."
>>>
>>> Q3: Would receipt of an M&A transfer remove you from the waiting 
>>> list, too?
>>>
>>> A3: I think that depends on how the M&A is justified. If you acquire a
>>> company that is already efficiently utilizing all its IP space, I don't
>>> think that would count toward fulfilling an outstanding need that you
>>> have a request on the waiting list for. However, if your justification
>>> for keeping the space held by the acquired company is that you plan to
>>> use it for new stuff, then that would meet an outstanding need, and a
>>> request for that same need would be considered fulfilled and removed
>>> from the waiting list.
>>>
>>> Q4: What about Multiple Discrete Networks?
>>>
>>> A4: Allocations and assignments to organizations using the Multiple
>>> Discrete Networks policy must still be made as a single continuous range
>>> of addresses. This preserves future aggregatability of the space, and
>>> ensures fairness between MDN and ordinary requests.
>>>
>>> Timetable for implementation: Immediate.
>>>
>>>
>>> #####
>>>
>>>
>>> STAFF ASSESSMENT
>>>
>>> Proposal: Waiting List for Unmet IPv4 Requests
>>> Proposal Version: Updated by AC and given to staff for assessment on 29
>>> Dec 2009
>>>
>>> Date of Assessment: 12 January 2010
>>>
>>> 1. Proposal Summary (Staff Understanding)
>>>
>>> Staff understands that this proposal would create a waiting list for
>>> requestors whose IPv4 address needs cannot be fulfilled by ARIN at the
>>> time of the request approval. The proposal includes text to prevent
>>> requestors from gaming the policy's intent by forbidding requestors from
>>> making multiple requests of a small size and limiting the issuance of
>>> space to no more than once every 3 months.
>>>
>>> 2. Comments
>>>
>>> A. ARIN Staff Comments
>>>
>>> • In section 4.1.8, the author says “Repeated requests, in a manner that
>>> would circumvent 4.1.6, are not allowed: an organization may only
>>> receive one allocation, assignment, or transfer every 3 months, but
>>> ARIN, at its sole discretion, may waive this requirement if the
>>> requester can document an unforeseen change in circumstances since their
>>> last request”.
>>>
>>> As written, the portion of the policy that starts with “but ARIN, at its
>>> sole discretion” gives no concrete criteria for staff to use in its
>>> assessment of the request. This “exception clause” is open to
>>> interpretation and may not be applied consistently by staff if there are
>>> no guidelines or rules for staff to follow. It essentially allows ARIN
>>> staff to determine the policy criteria for who can or can’t qualify
>>> under this waiver.
>>>
>>> B. ARIN General Counsel
>>>
>>> "At this time counsel has no significant legal comments. Any system to
>>> order and prioritize requests for resources which may exceed the
>>> available resources must permit consistent administration by ARIN."
>>>
>>> 3. Resource Impact
>>>
>>> This policy would have moderate resource impact. It is estimated that
>>> implementation would occur within 6 months after ratification by the
>>> ARIN Board of Trustees. The following would be needed in order to 
>>> implement:
>>>
>>> • The development of software to monitor IPv4 returns, a “waiting list”
>>> that will include request size as well as minimum size acceptable, and a
>>> system that will match/compare returns with the waiting list
>>> • Modifications to the management web application
>>> • Changes to current business processes
>>> • Updated guidelines
>>> • Staff training
>>>
>>>
>>>
>>> 4. Proposal Text: Waiting list for unmet IPv4 requests
>>>
>>> Replace 4.1.6 with:
>>> 4.1.6. Aggregation
>>> In order to preserve aggregation, ARIN attempts to issue blocks of
>>> addresses on appropriate "CIDR-supported" bit boundaries. As long as
>>> sufficient space is available, ARIN may reserve space to maximize
>>> aggregation possibilities. ARIN will make each allocation and assignment
>>> as a single continuous range of addresses.
>>> Add new section 4.1.8:
>>>
>>> 4.1.8 Unmet requests
>>> In the event that ARIN does not have a contiguous block of addresses of
>>> sufficient size to fulfill a qualified request, ARIN will provide the
>>> requesting organization with the option to either modify their request
>>> and request a smaller size block, or be placed on a waiting list of
>>> pre-qualified recipients. Repeated requests, in a manner that would
>>> circumvent 4.1.6, are not allowed: an organization may only receive one
>>> allocation, assignment, or transfer every 3 months, but ARIN, at its
>>> sole discretion, may waive this requirement if the requester can
>>> document an unforeseen change in circumstances since their last request.
>>> Qualified requesters whose request cannot be immediately met will also
>>> be advised of the availability of the transfer mechanism in section 8.3
>>> as an alternative mechanism to obtain IPv4 addresses.
>>>
>>> 4.1.8.1 Waiting list
>>> The position of each qualified request on the waiting list will be
>>> determined by the date it was approved. Each organization may have one
>>> approved request on the waiting list at a time.
>>>
>>> 4.1.8.2 Fulfilling unmet needs
>>> As address blocks become available for allocation, ARIN will fulfill
>>> requests on a first-approved basis, subject to the size of each
>>> available address block and a re-validation of the original request.
>>> Requests will not be partially filled. Any requests met through a
>>> transfer will be considered fulfilled and removed from the waiting list.
>>>
>>>
>>> Rationale:
>>> ARIN will soon be unable to meet all approved requests for IPv4 address
>>> space. In the absence of a policy like this, it is unclear what ARIN
>>> should do with subsequent requests.
>>> This policy would allocate reclaimed address blocks (and the last of the
>>> ARIN free pool) on a first-come-first-served basis, while preserving
>>> aggregation to the degree possible. As the free pool shrinks, requests
>>> larger than the largest block left would be placed on a waiting list,
>>> while smaller requests would use up the rest of it, until all requests
>>> have to go on the waiting list. As additional reclaimed addresses become
>>> available, the requests that have been waiting the longest would be met
>>> first. If a requester gets the addresses they need via transfer, then
>>> they would be removed from the waiting list and would need to wait and
>>> submit a new request for additional address space, either directly or
>>> via transfer.
>>>
>>>
>>>
>>>
>>> FAQ:
>>> Q1: The effect of 2009-8, if implemented by the Board, is to allow
>>> transfers to be up to a 12 month supply of resources and up to a 3 month
>>> supply for resource from the ARIN free pool. Does that jive with your
>>> intent for this policy?
>>> A1: Correct. After we get to the last /8, you can request up to a
>>> 3-month supply from the free pool, but only every 3 months unless you
>>> can document an unforeseen change in circumstances since your last
>>> request. However, if you get the space via transfer, you can get a block
>>> big enough for 12 month's need, and if you end up using it up faster,
>>> you can submit another request after 3 months.
>>> Q2: If I were on the waiting list, and subsequently received a transfer
>>> via 8.3, would I be removed from the waiting list?
>>> A2: Yes. In 4.1.8.2, it says that "Any requests met through a transfer
>>> will be considered fulfilled and removed from the waiting list."
>>> Q3: Would receipt of an M&A transfer remove you from the waiting 
>>> list, too?
>>> A3: I think that depends on how the M&A is justified. If you acquire a
>>> company that is already efficiently utilizing all its IP space, I don't
>>> think that would count toward fulfilling an outstanding need that you
>>> have a request on the waiting list for. However, if your justification
>>> for keeping the space held by the acquired company is that you plan to
>>> use it for new stuff, then that would meet an outstanding need, and a
>>> request for that same need would be considered fulfilled and removed
>>> from the waiting list.
>>> Q4: What about Multiple Discrete Networks?
>>> A4: Allocations and assignments to organizations using the Multiple
>>> Discrete Networks policy must still be made as a single continuous range
>>> of addresses. This preserves future aggregatability of the space, and
>>> ensures fairness between MDN and ordinary requests.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>