[arin-ppml] Draft Policy 2014-14, WAS Re: About needs basis in 8.3 transfers

[Andrew Dul]

On 6/9/2014 8:28 PM, John Springer wrote:
> So, Andrew. As one shepherd of 2014-14 to another, what are we to do
> with "Re: [arin-ppml] About needs basis in 8.3 transfers" WRT 2014-14?
> Are arguments there able to be applied wholesale to 2014-14, mapping
> (divining?) pro-needs basis logic as anti-2014-14 and vice verse?  If
> not, is it all to be discounted by saying that the authors did not
> explicitly express either support or opposition and therefore we are
> not permitted to read anything into their statements?
>
While 2014-14 has been narrowly crafted currently to be about
alleviating ARIN staffing issues associated with transfers, I believe
the author's intent is to remove needs basis testing from "small" block
transfers and then moving toward "larger" blocks later.  While I cannot
speak for the author directly, his comments on the list and to me have
lead me to this conclusion.  Thus, while the policy draft is construed
as being narrow about one issue, in effect it is opening the debate
about 8.3 transfer needs assessment.  Given that we have been discussing
needs basis in 8.3 transfer, not fixing the ARIN staffing issue, which
could be resolved in other manners than this policy change, I believe
that the discussion "About needs basis in 8.3 transfers" is germane to
the discussion of this policy and should be taken into consideration.

Based upon the assertion that the general discussion about needs
assessment in 8.3 transfers, I do not see consensus currently forming
around the current draft policy.

Given, we do not have consensus on the current draft, I see the
following options available to us which are all not mutually exclusive:

1. Move to abandon the current draft policy, if the community disagrees
with this approach, I invite them to petition the abandonment by the AC
if it occurs.
2. Update the policy text to allow up to a /20 to be transferred without
the needs assessment.  We have had posts by some authors who believe /16
is to big but would support a smaller block. 
3. Update the problem statement of the draft to better highlight the
other issues that the policy is addressing, notably that there are
organizations and individuals who believe that the current needs
assessment needs to be updated in a post-exhaustion IPv4 world.
4. Work with members of the community to see if there are areas of
common ground which could be used to rework the current policy into
something that might gain consensus in the future. (See my discusiion
about the needs basis continuum below)
5. Continue to allow the draft policy to be debated and look for
additional ideas from the community to refine and update the policy
sometime in the future.

>> Are there, in your opinion, any reasonable "steps" (e.g. policy
>> elements) that the registry community should implement as policy between
>> a buyer and a seller that are not the "existing traditional needs
>> assessment" which would provide a benefit to the IPv4 market and
>> Internet community as a whole?
>
> Excellent question, such commentary would be valuable and welcome, and
> if so, what?
>
Others ideas are certainly desired here...

In my opinion, not speaking as the shepherd here, needs basis testing is
not a binary operation, instead it is a continuum from "no needs" to
somewhere near the current needs based policies.  One could imagine this
continuum as a series of steps which move from no restrictions toward
more restrictions.  Overtime the RIRs generally added restrictions to
promote conservation and efficient use.  Given that we now will have
market forces applying to the IPv4 address rights, it makes sense to
reexamine the current needs basis criteria.  Perhaps, now is the time to
move downward from the current criteria toward the "no needs" side of
the continuum.  I, personally, believe there is value in retaining some
aspect of needs testing specifically the two attestations enumerated
below.  There may also be value in retaining some backward looking
auditing of utilization at additional allocations.  There may also be
other restrictions which could be valuable the the Internet community as
a whole such as anti-flipping restrictions on transfers.  There may also
be value in some other policy elements that I have not enumerated here.

No needs testing
        V
Attestation of legal use
        V
Operation need attestation
        V
Backward looking auditing of utilization* at additional allocations
        V
Forward looking projection of utilization* at additional allocations
        V
Additional restrictions at additional allocations

* Utilization can also be weakly or strongly defined.  I would consider
current policy quite strongly defined, but one could envision a policy
which was much weaker.  (e.g. 50% utilization rather than the current 80%)


Andrew