[arin-ppml] Statistics regarding NRPM 8.3 Transfers to date

[Owen DeLong]

On May 1, 2011, at 9:25 AM, John Curran wrote:

> On May 1, 2011, at 6:05 PM, Owen DeLong wrote:
> 
>>> Imagine you qualify to receive a /23 but there are no /23s available on
>>> the market.  AIUI, the policy's intent was to prohibit you buying half
>>> of someone else's /22.  However, is there any harm in ARIN fulfilling
>>> your request with my two disjoint /24s in that scenario?  Keep in mind
>>> you could get my /24s (or one from me and one from someone else) anyway
>>> via two separate transfer requests.
>>> 
>> No, that intent went out the window early in the debate. It was replaced with
>> an intent to prevent you from creating a /18 equivalent out of disparate /24 sized
>> chunks of someone else's /8.
> 
>>> This interpretation, which could be creatively read into the policy
>>> text, could easily explain the statistics recently posted and, IMHO,
>>> doesn't violate the policy's intent or goals.
>>> 
>> While I would be fine with ARIN fulfilling your request with 2 /24s that were already
>> disjoint, however, I don't want to see someone with, say, 44/8 find a buyer that needs
>> a /20 and sell them 44.0.5/24, 44.0.8/24, 44.15.23/24, 44.28.6/24, etc.
> 
> Owen - 
> 
> Please elaborate.  The phrase "single aggregate", if moved to the 
> resources transferred clause, would definitely preclude the example 
> that Stephen provides.
> 
> /John

Agreed... I think that the original intent was to preclude it, but, I agree that intent
isn't necessarily in the community interest.

So... I'll try to provide some examples of what should and shouldn't be allowed...


1.	Org. A has a /8 and wants to transfer 32 of it's constituent /24s to Org. B.
	However, Org. A doesn't want to put any effort into renumbering,
	so, those 32 /24s are each individual non-aggregable /24s.

	This transfer should not be allowed.

2.	Org. A has a /20 and a /18. Org. B has need for a /19. Org. A has
	deprecated their use of the /20 and all of their resources are in
	the /18, but, they are using just under 75% of the /18.

	Org. A would rather transfer the /20 and the top 1/4 of the /18 than
	renumber that 1/4 of the /18 into the /20.

	This transfer should not be allowed (though I admit the case against
	it is weak).

3.	Org. A has four disparate /20s. Org B. has need of a /19. Org. A
	would like to transfer two of their /20s to Org. B, but does not have
	any pair of /20s which can be aggregated.

	This transfer should be allowed. The /20s are already disaggregated
	in the routing table and there is no increase in routing table
	size that results.

4.	Org. A has four disparate /20s. Orgs. B, C, D, and E all have need
	for /24s. Org. A would like to sell individual /24s from one of their
	/20s to each of the above Orgs. (B,C, D, and E).

	These transfers should be allowed as there is no significant
	difference between this and transfers where ARIN has
	carved up a block during the initial allocations. The transfer
	sizes comply with community accepted policy.

In essence, I'm trying to say that transfers which create unnecessary
additional disaggregation should be avoided.

Owen