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

[David Farmer]

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.

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


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================