[arin-ppml] Emergency PDP process
George, Wes E [NTK]
Wesley.E.George at sprint.com
Mon Dec 6 12:35:00 EST 2010
John - thanks for your reply - some comments below inline.
> -----Original Message-----
> From: John Curran [mailto:jcurran at arin.net]
> Sent: Friday, December 03, 2010 5:27 PM
> To: George, Wes E [NTK]
> Cc: arin-ppml at arin.net List
> Subject: Re: [arin-ppml] Emergency PDP process
> I believe that the emergency policy mechanism exists to handle imminent
> catastrophe situations which would otherwise prevent ARIN from
> performing
> its mission of technical coordination and management of Internet number
> resources, or cause ARIN's performance of its mission to be contrary to
> the principle of stewardship.
[WES] This is actually a pretty good start on a set of definitive tests, and
exactly the type of discussion I was hoping to generate. I think it needs to
be documented so that our process is as open and understandable as possible,
even when we're using the emergency process.
>
> ARIN performing allocations according to community-developed policy is
> the
> status quo. As CEO, I know would recommend to the Board for the
> adoption
> of emergency policy under circumstances where the existing policy could
> no
> longer be followed (e.g. in response to unforeseen legal developments,
> or
> due to an action at IETF/IANA/ICANN which prevented ARIN following our
> policies).
[WES] Ok, this is also a helpful framework with which to evaluate
emergencies. So the main thing that is open to interpretation is if you view
IANA exhaustion as an "action ... which prevented ARIN from following our
policies."
In my view, it's not, because we have seen this coming for quite some time.
We may not have known the exact date, but it was still close enough that a
lot of the flurry of recent policies could have been written and adopted in
enough time to manage a change in policy prior to runout. The fact that
runout exists does not, in and of itself, create an emergency situation. It
may be that the only way to trigger/justify emergency policies based on
runout is to actually let it happen and *then* realize that there are some
unintended side-effects that we need to correct ASAP.
> That doesn't mean that there aren't other circumstances which
> might also warrant emergency policy, only that it's extremely difficult
> to establish the criteria in advance. The ARIN Board has not discussed
> specific criteria by which it would judge emergency policy, so I cannot
> not provide any additional guidance, but I hope my particular examples
> prove helpful.
[WES] Agreed, and your examples are helpful. I wasn't trying to say that
there should be one rigid set of guidelines for which no exceptions can be
made. However, I disagree with the idea that you can't establish at least
some of the criteria in advance. We as a community and ARIN as an
organization have a much more defensible position against second-guessing
and other miscellaneous cries of "foul!" regarding our handling of IPv4
resource allocation/runout if we're a bit clearer on the framework for
evaluating policy changes that don't follow the standard PDP. There are some
things that will fall into the "know it when you see it" category, but we
also know enough about the way the world works here to have some predefined
criteria.
I would still strongly recommend the AC and board having this discussion
amongst themselves and the community prior to taking any emergency action on
any of the policies currently on the table.
Thanks
Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101206/0ba47646/attachment.bin>
More information about the ARIN-PPML
mailing list