[arin-ppml] Policy Proposal: Change Utilization Requirements from last-allocation to total-aggregate

[Leif Sawyer]

Based on Jeffrey Lyon's <jeffrey.lyon at blacklotus.net> email regarding
utilization requirements, I've put together a draft proposal:

---
Template: ARIN-POLICY-PROPOSAL-TEMPLATE-3.0

	1.	Policy Proposal Name: Change Utilization Requirements from last-allocation to total-aggregate

	2.	Proposal Originator 
		a.	name: Leif Sawyer
		b.	email: lsawyer at gci.com
		c.	telephone: 907-265-5600
		d.	organization: General Communications, Inc

	3.	Date: 1 May, 2014

	4.	Problem Statement: Utilization requirements for new requests is
		being calculated on a per allocation basis rather than in
		aggregate.
		For example, if an organization has 4 x /22 and 3 of them are
		utilized 100% and the fourth utilized at 75%, that request would
		be denied.
		This is a bit out of balance as an organization with a single /20
		utilized at 80% would have less efficient utilization but would be
		eligible to request additional space.

	5.	Policy statement:
      Section 4.2.4.1-  Change text to read:
		"ISPs must have efficiently utilized all previous allocations, in
		aggregate, to at least 80% in order to receive additional space.
		This includes all space reassigned to their customers. Please note
		that until your prior utilization is verified to meet the 80%
		requirement, ARIN can neither process nor approve a request for
		additional addresses."

	Section 4.3.6.1-  Change text to read:
		"End-users must have efficiently utilized all previous assignments,
		in aggregate, to at least 80% in order to receive additional space,
		and must provide ARIN with utilization details. The prefix size for
		an additional assignment is determined by applying the policies
		found in Section 4.3 of the NRPM."

	6.	Comments:
		a.	Timetable for implementation: Immediate, possibly through
			board action.
		b.	Per originator, This does not currently extend into MDN
		(aka 4.5.4), and I'm not really sure how to reconcile it against
		4.5.5, but OP expressed some concern that there may be undue
		restrictions there.  It might be better served by a separate
		proposal.
		c.    There should probably also be an attempt to clean up the
		language between 4.2.4.1  and 4.3.6.1, as they're both currently
		very clunky.

END OF TEMPLATE