[ppml] Revised Policy Proposal Resource Reclamation

In a message written on Tue, May 01, 2007 at 03:28:35PM +0100, michael.dillon at bt.com wrote:
> In fact, after it is determined that an org cannot demonstrate technical
> justification for their existing address space, the right action for
> ARIN to take is dependent on the state of their recordkeeping. If bad
> records are the reason why they cannot demonstrate justification, then
> ARIN should start by ordering them to bring their records into order,
> and give them time and assistance to do so. Part of that assistance is
> the above-mentioned standards for recordkeeping. If the org has good
> enough records but just lack the justification, then ARIN should order a
> remediation plan. This will also give the org ample time to deal with
> any issues surrounding renumbering, but it also allows the org to do
> things like acquire new customers and thus acquire the technical
> justification that they need. They could buy another ISP and renumber
> all their customers and give back the other ISP's addresses instead of
> their own. This is like when a court orders an accounting firm to run a
> business's financial affairs rather than ordering a bankruptcy. I use
> this analogy specifically because I believe that ARIN's role here has to
> be in helping an org reach compliance, not in punishing an org or
> pulling the rug out from under them.

Perhaps you and I have a different definition of the word "probation",
but to me that's exactly what you describe here.  If the records
are not in order, they get put on probation, during which time they
make amends (update records, remediation plan, etc).  Perhaps also
important is that an org on probation can't get new resources.  I
don't think that needs to be in the policy, that's already the way
it is....if you can't justify your current resources you don't get
more.

What I suggested and you jumped on is that if the org refused to
update their records, or refused a reasonable remediation plan then
and only then would the proper recourse to be to revoke all of their
assignments.  Why is this important?  Otherwise there's no reason.
If I don't believe I'll need more IP space for the life of IPv4,
and ARIN comes to audit me, what's the penality for saying no?

Of course, if the org has proper records and has simply shrunk over
time such that now a large amount of their space is unused, then a
partial reclamation is the absolutely appropriate thing to do, and
ARIN should be lenient with time frames for that to happen.

> The fact is that for many years (and maybe still to this day) there has
> not been any accepted description of what constitutes technical
> justification for IPv4 address allocations/assignments. In the absence
> of a clear description, thousands of engineers and managers have built
> up networks and businesses thinking that they were following ARIN
> guidelines in good faith. 

I believe ARIN policy and operational procedures make it clear to
many people on a daily basis what constitutes justification.  Every
single new space allocation meets that standard, so I'm not sure why
anyone would think the standard is a mystery or undefined.

> You simply cannot turn 180 degrees and attack these people who have been
> acting in good faith. If it means that we run into the brick wall of

This is not a 180 degree turn.  It's perhaps a 10 degree turn.
Today anyone applying for new resources may have to fully document
all existing ARIN allocations in order to get new space.  Anyone
who may need additional space in the future should already be
prepared to do everything this policy requires, or they are in big
trouble.  The only thing this policy does is to add a second trigger,
now not only a new request but being dormant for too long will
trigger the same level of review.

I suspect there's a lot of low hanging fruit too.  Many small ISP's
are partnerships, that might get a /19.  Then fail.  One partner
takes the /19 and starts using 10 addresses for a new ASP business,
and keeps paying the fee.  He never requests more, so an ARIN review
is never triggered.  Yet there is massive waste.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.arin.net/pipermail/arin-ppml/attachments/20070501/9266cb4f/attachment.bin