[arin-ppml] Draft Policy 2010-1: Waiting List for Unmet IPv4 Requests
scottleibrand at gmail.com
Wed Jan 27 01:42:14 EST 2010
On 1/26/2010 10:27 PM, Steve Bertrand wrote:
> 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
>>>>> 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
>>>>> last request”.
>>>>> As written, the portion of the policy that starts with “but ARIN, at
>>>>> 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
>>>>> 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.
If they wanted to, the ARIN Board could set up a mechanism to do
something like this. However, I'm not sure they would, for a few
reasons, such as:
- Balancing degree of participation with timeliness would be
difficult. As you allude to, the amount of feedback on PPML can often
be counted on one hand. OTOH, there are routinely 10x as many
participants expressing an opinion at a public policy meeting, but those
only occur twice a year.
- The bottom-up policy process works well partly because it is limited
to producing non-discriminatory policies that apply to the whole
community. If we were to propose policy that applied to individual
organizations, we would be playing a whole different ballgame with an
entirely different set of requirements, legal and otherwise.
So, I think we're best off using the policy process to set the overall
policy and provide guidelines to ARIN staff, and then trusting them to
implement the policy fairly. If necessary, they can always set up an
internal procedure to escalate (appeals on) sensitive requests, all the
way to the president or board level if necessary.
>> 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 agree wholeheartedly. You (plural) are ARIN, and you are the ones
that make the policy process work. Please keep participating.
More information about the ARIN-PPML