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

[Scott Leibrand]

On 1/28/2010 4:00 PM, David Farmer wrote:
> 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"?  If contact fails, then I'd say that 
>> re-validation fails as well.
>>
>> Thoughts?
>
> That should take care of part of it but maybe there should be a limit 
> on the time someone who is one the waiting list has to respond, so 
> that the resources can get allocated to the next person on the list, 
> if they are not responding.  I would want resource tied up too long 
> while ARIN is trying to contact someone and fails, some small number 
> of days something in the range of 2 to 5 business days would seem 
> reasonable to move on to the next guy.
>
> Also, I think a quarterly check with those on the waiting list would 
> be reasonable too.  Basically an email asking do they want to remain 
> on the waiting list, if they don't respond within some time frame they 
> can be removed from the list.
>
> If they don't want to be bothered then they don't have to be on the 
> list do they.

Those sound like excellent suggestions for ARIN's operational procedures 
if/when they implement this policy.  :-)

-Scott

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