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

[Scott Leibrand]

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"?  If contact fails, then I'd say that re-validation 
fails as well.

Thoughts?

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.