[ppml] Revised Policy Proposal Resource Reclamation

[Leo Bicknell]

In a message written on Mon, Apr 30, 2007 at 01:26:25PM -0700, Owen DeLong wrote:
> 		4.  If the review shows that existing usage is substantially 
> 		not in  compliance with current allocation and/or assignment policies, the  
> organization shall return resources as required to bring them into  
> compliance. If an organization holds multiple ARIN delegations, they  

I'm going to raise the objection I think staff will raise, what is
"substantially not in compliance"?

I think this goes to two different areas, procedural and utilization.
In the procedural camp we have things like failing to maintain
records (no SWIP's, no RWHOIS, perhaps not even any real written
documentation, or even giving out /24's to every customer regardless
of actual need).  I would think on any procedural violation the
right thing to do would be a "probation" period where the holder
can rectify the situation, and quite frankly, if they can't comply
with the documentation aspects I think all of their space should
be pulled.

Utilization is sticker, and I suggest it needs to be a high and low
watermark sort of arrangement.  Right now (for ISP's) the numbers
are you get a 6 month supply, and you need 80% for more space.  So
what if you get a six month supply and then your business experiences
some issue so that a year later you're only at 60% utilization?  Is
that "substantially not in compliance"?

So what about a definition like:

	Any block less than 25% utilized is substantially not in
        compliance.

I think that works for ISP's, who must show 80% to get a new block,
and then only get a 6 month supply, and also for end users, who
must show 25% day one, with 50% utilization projection for one year.

I do support the concept of the policy, and I think what you've put
together is pretty reasonable.

-- 
       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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070501/53c7a398/attachment.sig>