Important New Requirement for IPv4 Requests [re "impacting revenue"]

Tue Apr 21 17:57:40 UTC 2009

On Apr 21, 2009, at 10:36 AM, Roger Marquis wrote:

> John Curran wrote:
>> A) ARIN's not ignoring unneeded legacy allocations, but can't take
>> action without the Internet community first making some policy
>> on what action should be taken...  Please get together with folks
>> of similar mind either via PPML or via Public Policy meeting at
>> the the Open Policy Bof, and then propose a policy accordingly.
>
> Thanks for the reply John, but PPML has not worked to-date.  Too many
> legacy interests willing and able to veto any such attempt at a  
> sustainable
> netblock return policy.  Not sure how us folks, of a similar mind as  
> it
> were, would be able to change that equation.  IMO this change has to  
> come
> from the top down.  Towards that goal can you give us any hint as to  
> how to
> effect that?
>
At this point, the community consists of far more non-legacy holders
than legacy holders. Additionally, nobody has "VETO" power other than
the ARIN Board as a body in the policy development process.

As such, I don't think that your argument quite fits the situation.

If folks of a similar mind are able to put a policy proposal together
and submit it to policy at arin.net (there's a template on the ARIN
web site), it will receive the same treatment as any other policy
proposal.

How the community as a whole reacts to the proposal is another
matter, but, if a substantial majority of the community feels the
policy proposal is a good one, then, it should be possible to
obtain consensus. If that's not the case, then, I'm not sure how
you can justify implementing such a policy contrary to the
consensus of the community.

I hope there is no way to effect a top-down policy within ARIN since
we work very hard to maintain a bottom up policy process. If there
is, then, something is very broken.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090421/21e572f7/attachment.bin>