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

[Mike Burns]

Hi Owen,

I sent this from the wrong address so it didn't post to the list.
I figured I would just ignore that, but since you replied I will answer.

>> 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.


Yes, I indicated that serialization was a benefit, but fleeting, unless you 
really think people will be making significant use of the waiting list.


>> 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.

I thought ARIN allowed legacy holders to sign an LRSA and pay significantly 
less than non legacy addresses. Isn't that a difference?

>> 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.

Not yours, but John Curran offered this as sort of a counter-argument to 
2014-14, based on fairness. Although he quickly indicated that it could be 
overcome.

>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.

OK, I think that is a new position and I think it makes sense. Team review 
for both transfers and free pool allocations until the free pool expires. I 
guess we'll need a definition of expiration then, but it seems fair. Maybe 
if we pick the right definition, we can avoid a thousand team reviews of 
/24s.

Regards,
Mike