[arin-ppml] ARIN-prop-165 Eliminate Needs-Based Justification

[David Farmer]

On 2/19/12 23:09 CST, Astrodog wrote:
> On Sun, Feb 19, 2012 at 5:58 PM, Owen DeLong<owen at delong.com>  wrote:
>>
>> Yes, that's exactly how it works. I agree that an expiration on STLS entries would be a good thing.
>>
>> The re-qual. is an important safeguard as far as I am concerned. It discourages partial fills and excessive fragmentation due to multiple partial fills.
>>
>> Glad to hear that STLS mostly addresses your concern. Hopefully that means we can abandon 165 soon.
>>
>
> STLS certainly smoothes things over for sellers. I do agree that
> fragmentation is undesirable, but if the suggestion here is that
> transfers are all need based, the quantity of space an entity needs
> does not decrease simply because a partially filled transaction
> occurred. If one *needs* a /18, and instead gets a /19, the remaining
> /19 is still "needed".
>
> If the intent of the community is to drive transfers based on need,
> then an approval for an /18 is also an approval for 2 /19s, 4 /20s,
> etc. If an organization is approved for an /18, and gets a /19
> instead... and is subsequently denied for another /19, then it sounds
> like the original approval for an /18 was incorrect.

The single block requirement has been removed, so it is possible to 
fulfill a /18 demand with 2 /19s or 4 /20s from a single seller in a 
single transfer transaction.  There is still an issue with multiple 
transactions from different sellers that I believe would require a new 
justification, between each transaction.

This is mostly to be consistent with the unmet request/waiting list 
provisions of sections 4.1.8.  I believe the idea is you can 
simultaneously be put on to the waiting list and STLS once the free pool 
is exhausted.  if STLS were completely independent then allowing 
multiple transfers until your need was fulfilled would probably work, 
and probably work better than the current process.  But allow you to sit 
on the free-pool waiting list until your need is completely fulfilled 
doesn't seem fair.  So once you accept an allocation, either by 
executing a transfer or from the free-pool, probably usually smaller 
than your need, then you are dropped from the waiting list and you need 
to re-justify and go to the back of the line for free-pool waiting list.

I suppose we could have done it all differently, but transfers will not 
be the exclusive source of addresses, there are and will be some, 
probably small, amounts of address space returned or otherwise reclaimed 
even after free-pool exhaustion, and we need a system to allow fair 
distribution of this returned/reclaimed address space too.  And I think 
a linkage between the waiting list and transfers is necessary, I don't 
think it is fair to keep your place on the waiting list if you also 
executed a transfer.  Maybe there is a different way to handle this, but 
there are a number of different parts than need to fit together and some 
times you can't individually optimize all of the pieces, and still have 
them fit together.

My personal recommendation to those interested in eliminating need-based 
justification, is that you change your tactics and not attack the 
concept of need-based justification, but look at ways to redefine the 
processes and evaluation criteria for need.  Note that there has always 
been a needs basis for assignment or allocation of number resources, 
that is being that you need them to build operational networks and that 
is why an organization receives them.  However, around the time of the 
creation of the RIR system the current processes and criteria for the 
evaluation of need based on slow-start and your historical allocations 
were created and were a significant change from the then current 
processes and criteria.

I believe it should be possible to create a new regime that ensures that 
there is operational need for the assignment of resources that is more 
market friendly than the current slow-start with historical allocations 
as the criteria to ensure operational need.  Also note that I believe 
the current process and criteria have a dependency on a unrestricted 
free-pool in order to accurately determine an organizations actual need 
over time.  And as the free-pool is exhausted, this process will no 
longer accurately determine an organization's actual need but skew 
toward measuring an organizations ability to pay for resources, year 
over year, rather than an abstract measure of need.

Therefore, I think it will be necessary to find a more market compatible 
processes and criteria for ensuring that an organization has operational 
need.  That said, I don't see the idea of completely throwing out the 
concept of needs basis finding consensus within the community.  However, 
a radical redefinition of the processes and criteria for the evaluation 
of need may be possible, if it respects and protects the concept that 
operational need is a necessary component of making an assignment or 
allocation.

Early in the discussion of this proposal I asked about the author's 
intent regarding the "Officer Attestation" and if that was intended to 
be attesting to operational need by the organization.  While I'm not 
sure this is sufficient protection, I think this is the kind of creative 
redefinition of the processes and criteria for the evaluation of 
operational need that we should be discussing and I encourage those that 
support loosening the policy constraints on the market to move the 
discussion toward these kinds of solutions.

Thanks

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================