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

Steve Bertrand steve at ibctech.ca
Wed Jan 27 01:27:34 EST 2010


Scott Leibrand wrote:
> On 1/26/2010 8:48 PM, Steve Bertrand wrote:
>> Scott Leibrand wrote:
>>   
>>> On 1/21/2010 11:45 AM, Member Services wrote:
>>>     
>>>> 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.
>>>>        
>>> To address this issue, I have added one more Q&A to the FAQ in the
>>> Rationale of this proposal:
>>>
>>> Q5: What would constitute "an unforeseen change in circumstances since
>>> their last request" that would allow ARIN to waive the 3-month delay to
>>> receive a second block?
>>>
>>> A5: This would, of course, be a matter of discretion for ARIN, but the
>>> idea here is that the burden of proof is on the requester to document
>>> some change in circumstances, that could not have been reasonably
>>> foreseen at the time of the original request, that now justifies
>>> additional space.  This is intended to be a rarely used safety valve.
>>>      
>> Given that this deals with runout, I'll take my first crack... all
>> criticism very welcome (I'm bracing for it ;)
>>    
> 
> Thanks: good feedback.
> 
>>
>> A5: The use of this 'emergency safety valve' would have the burden of
>> proof put upon the requester, as to force them to adequately document a
>> significant change in circumstance. The requesters documentation would
>> include information on their proper initial due diligence, and reasoning
>> for not have been able to foresee such a situation at the time of the
>> original request.
>>    
> 
> I like this, and may steal some of your language.  :-)
> 
>> Any and all requests that fall under this 'clause' category shall be
>> presented to the ARIN PPML mailing list without any identifying
>> information, other than the number of IP blocks that the requester has
>> requested within the last 12 months, the number and size of IP blocks
>> the requester has received within the last 18? months, and the [due
>> diligence] documentation presented with the 'emergency' request.
>>
>> The blocks will be provided for distribution to the requester upon
>> community consensus, following the same procedures of the PDP, but at
>> [expedited pace] timeframe.
>>    
> 
> I'm not convinced that we want to inject PPML into the process in-line. 
> Given that the current policy process cycle is about 6 months, I'm not
> sure if we could do an [expedited pace] that would actually be faster
> than waiting the 3 months...

The way I see it, the only way to present something to the entire
community is via the PPML. Unfortunately, I haven't found any method
that ARIN staff is permitted to use that would allow them to expedite
such information to the PPML, without "declaring an emergency".

It would seem that over-using this portion of the PDP would cause the
term 'emergency' to become useless, and also, would require a policy
draft to be submitted, which is senseless regarding an IP request.

Again however, as I understand (I've only read the PDP once-over, other
than glancing here-and-there) (btw, the PDF Appendix A reflects nicely),
the only way to present something for community consensus *is* via the
PPML, _after_ it has gone through proper channels.

Perhaps you're not convinced that a request for _whoops_ emergency
requests should have to fall through the PPML due to the 'normal'
process cycle, but could this [expedited pace] not be written into a
community agreed-upon policy of some-sort that could bypass the first
few PDP steps if it's been noted within an ARIN 'system' that it falls
within this 'clause'?

- passed directly to the AC (bypassing staff, clarity and understanding)
- AC verifies, sends to PPML
- 10 days on PPML (everyone is paying attention near runout ;)
- community consensus, even if its 1-0
- BoT fiduciary
- done, yay/nay... no recourse. The community said so.
- apply again if necessary, but your same stats will be provided the
next time around, otherwise, wait until you are out of the 'clause' window

> However, I definitely want to see transparency in how this policy is
> being used.  We do have an existing mechanism for ARIN staff to report
> back to the community on how policies are working out: at every ARIN
> meeting staff (Leslie) gives a Policy Experience Report, detailing how
> one or more aspects of policy are actually working in practice, and
> suggesting changes where necessary.  And, of course, she takes questions
> as well.  So I'm thinking maybe we'd want to have staff report on the
> number of waivers requested and granted, and any interesting details of
> the circumstances surrounding the requests...

I'm going overboard on a finer point on your proposal. Hopefully I'll be
at the next ARIN meeting to hear the Policy Experience Report. I do like
the transparency of the process. I specifically like the fact that
*anyone* can drum up ideas, throw them at the list, and see what
happens. The transparency, and bottom-up approach seems to be quite
effective (all the while spurring intriguing and very interesting dialogue).

I'm more concerned whether your policy will ensure that *ALL* IPv6
addresses will fall under: "Each allocation/assignment size will be made
out of separate blocks reserved for that purpose." however...

Steve



More information about the ARIN-PPML mailing list