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

Ted Mittelstaedt tedm at ipinc.net
Fri Jun 12 17:00:04 EDT 2009


Scott Leibrand wrote:
> 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.
> 

Yes, that's precisely it.

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

The wait list should specify that they should ask for the max they
need and only best-effort will be made to meet the request - if they ask
for a /18 and are next in line and ARIN has a /20 come up, they should
be offered the /20 and stay on the wait list until the order is filled.

Besides the fact I think most orgs will ask for the max anyhow if they
are going to be on a wait list, here's how I think the scenario you
illustrate would play out.

So this org goes on the waitlist, while waiting for their /18 they
buy a /19 through transfer.

6 months later the /18 comes available.  Normally they would no longer
qualify BUT what ARIN does in this case is they offer them the /18
IN EXCHANGE for a trade-in of the /19 that they "bought" from transfer.
(or a trade-in of the partial /20 that was given to them)

The benefits are obvious - ARIN can aggregate the /19 (if possible) or 
give it to another org that only requested a /19.  Also, the org that
bought the /19 through transfer gets a unified contiguous /18 not 
another discontiguous /19

And finally, this is the best part - since the /19 is traded in to ARIN,
it doesn't go right back on to the transfer market and is then sold by
a broker to someone else - thus we are helping to discourage growth
of transfer brokering.

> 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  strike thiat

Requests will be partially filled only on condition the requesting
org agrees to return the partial allocation in exchange for a
larger allocation, should a larger allocation become available
that would fill the original request.

  Any requests met through a
> transfer will be considered fulfilled and removed from the waiting list.
> 

strike the last bit.

Ted

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




More information about the ARIN-PPML mailing list