[arin-ppml] Global policy development process [was: Re: NRPM 2010.1 ? New Policies Implemented]

Leo Bicknell bicknell at ufp.org
Fri Jan 15 17:10:32 EST 2010


In a message written on Fri, Jan 15, 2010 at 12:57:36PM -0800, Ted Mittelstaedt wrote:
> I think that ICANN/IANA should effectively duplicate what we have for
> global policies - a mailing list with all interested parties, etc.

Your description encompases several different aspects of how
ICANN/IANA works, but let me dive into a particularly interesting
case.

Let's say 4 of the 5 RIR's agree strongly for some reason that IP's
should only be issued on Tuesdays and Thursdays (as a straw man).
Today there is absolutely no way to enforce that on the 5th RIR.
It takes all 5 to agree to any change in the IANA policy, so if
you wrote the "stick policy" of:

  "IANA will only provide IP's to RIR's who issue them on Tuesday's
   and Thursday's."

You could never get it passed.

This is both the simplest, and extreme case of what we have now.  Think
of a 5 clause global policy where ARIN wants to change clause 1, LANIC
clause 2, APNIC clause 3, and so on.  You end up with deadlock.

There are, at a high level, two ways to address this:

1) Lower the threshold at the IANA level.

This is simple.  Change it so the NRO NC can certify a global policy
once 3 or 4 of the 5 RIR's sign off on it.

2) Create a PDP at the IANA level.

This would be "top down" policy development, as opposed to the current
RIR "bottom up" policy development.  Some representatives of the RIR's
(think ASO AC members, or sending part of the staff, or sending the AC)
would particiapte in a IANA PDP with some process to come up with an
idea, evaluate it, and pass it.

The second idea seems more complete and fair, but it is also much more
heavyweight.  It also creates a very interesting question for each of
the RIR's about who represents them.  There is also the problem that it
turns the "bottom up" process on its head, which some may feel is a good
thing, while others may not like.

> The problem here is what we are running up against is the 
> (understandably) strong desire of the public (represented by
> all of our customers) to not shift away from IPv4.  People (and it's
> not just limited to customers, it includes a great many networks
> who have not got any IPv6 running on them at all) have a "chicken"
> mentality on this issue - they won't ABANDON IPv4 until "the other
> guy" does - and "the other guy" won't abandon IPv4 until the first
> guy does.  Both players of this game could be FULLY DEPLOYED with
> IPv6 and they would STILL be playing it!!!

While that may be a principal problem, that is not the only problem.
Even if folks were willing to move to IPv6, we still had to create a way
to reuse IPv4 through IANA (most likely).  We still had to figure out
how we were going to handle 16 bit ASN exhaustion, and so on.  

Now, with all that said (as it would appear I'm in full support of an 
actual global policy process) there are more practical problems.  ICANN
operates under MoU's with several entities.  There's a lot invested in
the "bottom up" process.  ICANN is not set up (staff, resources) to host
a real global PDP at this time.  It's unclear what carrots and sticks
could be used to get everyone on board with such a system.

I strongly prefer evolutionary change over revolutionary change.
I also prefer when that evolutionary change is moving towards a
target in the distance.  The central tennant of Ted's post is that
the world today is not the world when these things were set up.  We
shouldn't throw the baby out with the bath water, but we might want
to take notice that the baby is now a teenager.

I leave with this: I support ARIN {staff,board,AC} looking into how
the global PDP could be changed or improved, and making recommendations.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20100115/90bda5c9/attachment.sig>


More information about the ARIN-PPML mailing list