[arin-ppml] ARIN-prop-165 Eliminate Needs-Based Justification
farmer at umn.edu
Thu Feb 23 11:53:46 EST 2012
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
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.
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
More information about the ARIN-PPML