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

[Ted Mittelstaedt]

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.
>