[arin-ppml] Team Review - policy matter? (was: Re: reverse COEstatement)

[Owen DeLong]

On Sep 25, 2014, at 8:46 AM, Mike Burns <mike at camplink.net> wrote:

> Free pool addresses are costless, yet have monetary value.
> For this reason it makes more sense to scrutinize free pool allocations to prevent a rip-off of public resources.

Actually, I think it makes sense from a serialization perspective.

If there aren’t other people working on transfers and transfers aren’t getting ahead of free pool allocations in line for those people to review as a result of the team review process, than i’m fine with the existing system as being fair and equitable.

If people doing transfers are bypassing the lineup  of requests going through this process and getting handled faster as a result, then I have an issue and am concerned that the situation is unfair to free pool requestors.

> I wonder if we are applying team review to transfers, what was the reason we did not have team review of all allocations in the past?
> After all the population of non-free pool address space rapidly approaches the totality of all IPv4 space, and when presented with the fact that in the early days, when virtually all IPv4 space remained in the free pool, team review was not used, I ask why now for transfers?

I think this is moot given my last paragraph. If you think it still applies, then let me know.

> I tossed this team-review grenade to the list to make evident the obvious fact that ARIN policy already treats free pool and non-free pool space differently. Heck the 24 month distinction is clear evidence of that, how can we pretend that we have always treated these the same?  For a time there was no needs test for 8.2 transfers. This is another example of different treatment of the two address types.

Not so much.

Yes, we put in an exemption for longer timeframes. (If you will recall, I still don’t think said exception is fair or a good idea and I would much rather see us revert both to 12 months. However, that ship has sailed, the community has spoken, and we are where we are.)

> Legacy addresses are also treated differently in policy.

No. Show me any policy statement in the entire NRPM which states that there is such a thing as a legacy address, let alone provides differentiated policy for it. That simply isn’t true.

What is true is that there are legacy allocations/assignments which were made by ARIN predecessors under different (and mostly unwritten) policies  without any sort of contractual documentation between the issuer and the recipient.

The resources themselves do not have any special status and if they are transferred through the standard ARIN process under 8.2/8.3/8.4, the allocation/assignment to the recipient does not have any special status. The recipient must sign an RSA with ARIN and pays the same fees as anyone else with an ARIN allocation/assignment of the same size.

> It's silly to pretend there is some new issue of fairness that has recently reared its  head.

The team review process is new. If it created an advantage for transfer requestors over free pool requestors, then there would, in fact, be a fairness issue. It wouldn’t be new in the sense that it just started this week, but awareness of it on the part of the community would, in fact, be new.

> It's silly to ignore the intrinsic difference between a costless, valuable item and the same item with a price attached.

While this is true, it is also true that merely attaching a price to an item does not remove the properties that existed when it was costless.

> It's silly to team review over a thousand /24 allocations from the free pool, yet that is in the offing.

Maybe it is and maybe it isn’t. What I consider important is that requestors attempting transfers not be treated in a manner that provides an unfair advantage over requestors seeking free pool allocations/assignments. You may not agree with my opinion in this regard, but that alone doesn’t make my position any less reasonable or any more silly than yours.

> It's silly to object to 2014-14 because it has a size limit in it, aren't there size limits throughout the NRPM?

I don’t think any of my objections to 2014-14 have been related to the size limit. I think 2014-14 is generally a bad idea and a step in the wrong direction. I have expressed that if there is strong community support (which I don’t currently see here) for it, I would accept 2014-14 with a smaller limit and a time limit as being a reasonable experiment to see whether such a policy is likely to cause harm or not.

> The only benefit to me of the team review is the check on potential corruption. And also there is some benefit towards sequencing requests fairly, but this is minimal and goes away with the free pool. Does anybody expect much waiting list action?

And I don’t consider preserving team review beyond the time it is required for the free pool necessary. As I said, I want to make sure that both classes of requestor are being treated fairly and consistently. If requests which do not require team review are waiting their place in line behind requests that do, then I have no problem even if they are not “team reviewed”. It was not clear from earlier information that this was the case.

> I'm undecided on team review of transfers, but then again I don't think transfers should be reviewed at all, beyond vetting the seller as the address rights holder.

And here you and I have long ago agreed to disagree. Further, the community so far has not shown much support for this position.

> If they have to happen, at least team review minimizes corruption risk, but at the cost of delays and extra ARIN expense.

Just one of the many ways in which IPv4 costs are only going to get worse until we abandon this obsolete decrepit protocol as the life blood of the internet.

Owen

> 
> Regards,
> Mike Burns
> 
> 
> 
> 
> -----Original Message----- From: Owen DeLong
> Sent: Wednesday, September 24, 2014 7:01 PM
> To: John Curran
> Cc: arin-ppml at arin.net List (arin-ppml at arin.net)
> Subject: Re: [arin-ppml] Team Review - policy matter? (was: Re: reverse COEstatement)
> 
> 
> On Sep 24, 2014, at 3:50 PM, John Curran <jcurran at arin.net> wrote:
> 
>> On Sep 24, 2014, at 6:26 PM, Owen DeLong <owen at delong.com> wrote:
>>> On Sep 24, 2014, at 2:03 PM, John Curran <jcurran at arin.net> wrote:
>>>> ...
>>>> ARIN's IPv4 Countdown Plan is quite similar to the serialization
>>>> and review of requests that APNIC and RIPE performed as part of
>>>> their IPv4 pool runout plans, and originated in order to provide
>>>> for fair treatment of requests from the free pool as we approach
>>>> runout.  Team review of requests (where the entire analyst staff
>>>> gathers to process the request queue) is not efficient, but does
>>>> provide benefits for serialization in processing of requests. It
>>>> is unclear how that would be at all beneficial for IPv4 transfers
>>>> and it definitely would impact IPv4 transfer processing times.
>>> 
>>> I doubt it would be beneficial to transfers. However, I don’t think it is fair for transfers to be expedited and handled faster than free pool requests.
>>> 
>>> I believe it is a fairness issue, not an efficiency issue.
>> 
>> Owen -
>> 
>> Once the IPv4 free pool is depleted, would you suggest still
>> continuing the team review process for all IPv4 transfers going
>> forward?
> 
> I think that depends. If the supply continues to exceed demand, probably not. At the point where transfer demand exceeds supply and transfers start developing a waiting list, then it might make sense. I trust staff to use good judgment for this.
> 
> What I don’t want to see is undue advantages being given to transfers over free-pool requests during a time when both are possible.
> 
> I do not believe ARIN should be creating incentives to use transfers vs. the free pool. As I said, as long as both remain, fairness should, IMHO, dictate that they be treated the same.
> 
> Owen
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.