[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