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

[Ted Mittelstaedt]

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.