[arin-ppml] Policy Proposal: Waiting list for unmet IPv4 requests

[Scott Leibrand]

Ah, ok.  So you're saying that the request must be revalidated only at 
the time the numbers become available?  That actually is simpler, and I 
hadn't thought of it.  Thanks.

The only possible downside I can think of is that someone might think 
that they've already gotten approved for addresses, and then be 
surprised when the addresses come available that they no longer qualify 
because something has changed.  That should be manageable with 
reasonable expectations-setting, though...

I'm not sure we want to completely remove the transfer clause.  For 
example, consider an entity that qualifies for a /18 of space.  They 
only ask for a /20, though, and get put on the waiting list.  If they 
subsequently go get a /19 through transfer, they would still qualify for 
a /20, but IMO they should lose their place on the waiting list and have 
to re-apply.

So the resulting language might look something like this?

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.

Thoughts?

-Scott

Ted Mittelstaedt wrote:
> Hi Scott,
>
>   I would recommend you scratch the "any requests met through a
> transfer" line and scratch the "ARIN may provide a validity duration"
> line and simply state that the request will be revalidated.  I
> would also suggest scratching the expiration language - if your
> not going to require ARIN to put an expiration on the requests then
> don't suggest it in policy.  Requiring revalidation makes
> an expiration a moot issue, as well.
>
> Scratching out all 3 of these would make the proposal a lot
> simpler and easier to understand.
>
> If the transfer allowance is revoked in the future, or a sunset
> clause applied and it goes away, you now will have some dead language
> in this proposal.  Since it isn't necessary, why do it?
>
> revalidation should not be a problem once an org makes a request,
> since they will have all the paperwork on file that they did for
> the initial request.  If nothing has changed from the time they
> filed to the time the numbers become available, the org just tells
> the hostmaster "nothing changed" and that is that.  And if something
> did change, then the revalidation will prompt them to disclose that
> on the request.
>
>
> Ted
>
> Scott Leibrand wrote:
>> Good comments, thanks.  Replies inline...
>>
>> Ted Mittelstaedt wrote:
>>>
>>>
>>> I'm sorry to report that I'm against this proposal as written.
>>>
>>> I like the idea of a waiting list, and I had assumed ARIN would
>>> do this post-IPv4 runout.
>>>
>>> However, I feel that if the number resources become available
>>> more than 3 months AFTER the date of the initial request, that
>>> the waiting org must be re-qualified.
>>>
>>> They should be allows to "keep their place in line" but they should
>>> not be allowed to qualify then keep the qualification as good for
>>> an indefinite period.
>>
>> I agree that renewal should not be automatic.  Perhaps I should word 
>> it something like this?
>>
>> ARIN may provide a validity duration on each qualification.  In that 
>> case, the requester may re-apply to renew their request prior to its 
>> expiration and preserve their position on the waiting list.
>>
>> The assumption here is that ARIN's operational procedure would be to 
>> validate that all of the information on the initial application is 
>> still valid, and that the org still qualifies for space, before 
>> renewing the request.
>>
>>>
>>> Keep in mind that once ARIN issues a qualification to an org,
>>> that qualification becomes an asset.  Supposing for example the
>>> ISP is purchased by another ISP with adequate IPv4.  Why should
>>> they be able to get even more?
>>>
>>> Or, if you think that scenario is unlikely, then suppose the
>>> ISP puts in a IPv4 request, is denied, goes on the waiting list,
>>> then 3 months later executes a "private buy" with another org
>>> for a directed IPv4 transfer, and gets more numbers.  Then, 3
>>> months after that, IPv4 becomes available for the next org up
>>> on the wait list, and this ISP is the next in line.
>>>
>>> They no longer meet utilization requirements because they paid
>>> money out for the directed transfer 3 months earlier - but since
>>> they are prequalifed on the wait list, they can now get even more
>>> IPv4 under the rules.  Which of course they are going to want to
>>> do so they can turn around and "sell it" on the open market - to
>>> cover their cost from 3 months earlier of paying for IPv4 on the
>>> transfer market.
>>
>> There is also the clause that "Any requests met through a transfer 
>> will be removed from the waiting list.", which should address this case.
>>
>>> If the proposal was rewritten to force re qualification I'd probably
>>> support it.
>>
>> LMK if the changes above constitute a sufficient change to address 
>> your concerns.
>>
>> Thanks,
>> Scott
>>
>>> Member Services wrote:
>>>> Please be advised that the following policy proposal has been 
>>>> posted to the ARIN Public Policy Mailing List. All discussion of 
>>>> the proposal must take place on the PPML
>>>>
>>>> Regards,
>>>>
>>>> Member Services
>>>> American Registry for Internet Numbers (ARIN)
>>>>
>>>> ## * ##
>>>> 1. Policy Proposal Name: Waiting list for unmet IPv4 requests
>>>>
>>>> 2. Proposal Originator: Scott Leibrand
>>>>
>>>> 3. Proposal Version: 1.0
>>>>
>>>> 4. Date: 6/11/2009
>>>>
>>>> 5. Proposal type: new   6. Policy term: permanent    7. Policy 
>>>> statement:
>>>>
>>>> Replace 4.1.6 with:
>>>>
>>>> 4.1.6. Aggregation
>>>>
>>>> In order to preserve aggregation, ARIN issues blocks of addresses on
>>>> appropriate "CIDR-supported" bit boundaries. ARIN will make all 
>>>> allocations and assignments 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. 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. ARIN may provide a validity 
>>>> duration on each qualification, in which case the requester may 
>>>> renew their request  prior to its expiration to preserve their 
>>>> position on the waiting list.  Each organization may have one 
>>>> approved request on the waiting list at a time.  Any requests met 
>>>> through a transfer will be removed from the waiting list.
>>>>
>>>> 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.  Requests will not be partially filled.
>>>>
>>>> 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.
>>>>
>>>> This policy does not attempt to ration addresses, define maximum 
>>>> allocations, or otherwise manage how much address space any given 
>>>> organization may request.  As such, it is completely independent of 
>>>> any "Predictable IPv4 Run Out" proposals.
>>>>
>>>> 9. Timetable for implementation: Immediate.
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ARIN-Announce
>>>> You are receiving this message because you are subscribed to
>>>> the ARIN Announce Mailing List (ARIN-announce at arin.net).
>>>> Unsubscribe or manage your mailing list subscription at:
>>>> http://lists.arin.net/mailman/listinfo/arin-announce
>>>> 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.
>