[arin-ppml] ARIN-prop-146 Clarify Justified Need for Transfers

[Owen DeLong]

On May 2, 2011, at 5:05 PM, Matthew Kaufman wrote:

> 
> On May 2, 2011, at 4:29 PM, Owen DeLong wrote:
> 
>> 
>> On May 2, 2011, at 2:51 PM, Matthew Kaufman wrote:
>> 
>>> 
>>> On May 2, 2011, at 2:42 PM, Owen DeLong wrote:
>>>> there is no reason
>>>> to treat transfers differently from initial allocations and assignments.
>>> 
>>> Fundamentally disagree. Policy for handing out the last of the free pool of IPv4 (which has already become much MORE restrictive, now that we are subject to the "last /8" policies) should be different than policy for approving transfer recipients. There is no reason to believe, for instance, that we are in the "last /8" of transfers. And no new entrant post-runout will spend the time and money attempting to acquire only what they can justify for a 3-month period.
>>> 
>>> Matthew Kaufman
>> 
>> The three month restriction is a temporary abomination in the IPv4 policies related to runout.
>> 
>> The rest of the policy is not specially restrictive related to runout.
>> 
>> That temporary abomination is specifically exempted in 8.3, so, you already have exactly what
>> you have stated is needed above.
> 
> No it isn't. Section 8.3 has NO language exempting itself from the 3 month rule. That's what I hear on the list, but I looked it up, and it isn't there. That's how I ended up writing this proposal, after all.
> 
> The only exemption is in 4.2.4.4. That exemption ONLY works if you are not getting an initial assignment through transfer (a likely scenario for new orgs post-runout) AND you are not a new member who only recently got their initial 3 month supply (where you'd be restricted to using transfer in 3-month increments for the first year in order to grow).
> 
The only 3 month rule is section 4.2.4.4, so, I'm not sure why you think this needs to be fixed
in 8.3 instead of 4.2.4.4.

> AND there's other bugs in that 4.2.2.1.1 and 4.2.2.1.3 and 4.2.2.2 (at the very least) call out specific block sizes that might be *smaller* than the block you're trying to qualify under transfer.
> 
Those call out the minimums you must justify, so, again, I don't see that as a bug.

> I hate to say it, but... did you actually *read* my policy proposal text?
> 
Yes... Did you actually understand the NRPM you were trying to modify?

Either I'm not understanding the change you are attempting to make
(it seems you're just trying to eliminate the shortening of justification for
8.3 transfers to 3 months which, as I said, didn't happen anyway), or,
you're trying to radically rewrite the justification for transfers.

In the former case, you're attempting a policy no-op and I'm not in favor
of policy churn for the sake of churn.

In the latter case, I don't see the benefit to your proposal.

The three-month provision for runout is strictly embodied in 4.2.4.4. It does not
trigger for anything other than an ISP additional allocation request and it
exempts an ISP acquiring their additional allocation through transfer from
that 3-momth shortening.

The other 3-month language has been in policy for a long time and does not
relate specifically to runout. It provides the requirements for a new entrant to
create a justification to obtain addresses and I support the preservation of
those requirements into the transfer regime as I think they have been and
remain reasonable minimums.

>> 
>> There is no need for a policy change.
> 
> There clearly is, IF you run through each and every one of the paths in section 4 and see which ones 4.2.4.4 triggers for, and more important, which ones it *doesn't* trigger for.
> 
I can't say for certain that I have followed EVERY path, but, I have followed the ones
which I am aware of and they seem to result in what I consider to be the desired
outcome.

> If you qualify for an 8.3 transfer there is NO reason that transfer should fall under the 3-month rules, which right now, in many cases, it does... without a change like the one I have proposed.
> 
Please cite such a case because as it currently stands, I don't believe that to be
accurate.

Owen

> Matthew Kaufman