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

[Owen DeLong]

On Apr 30, 2011, at 6:30 AM, John Curran wrote:

> On Apr 30, 2011, at 1:23 AM, Owen DeLong wrote:
>> I would very much appreciate it if staff could provide phraseology that would
>> result in an interpretation of the policy along the lines of what was intended...
>> 
>> That each transfer be only a single aggregate block.
> 
> Owen - 
> 
>  The phrase is presently applies to the aggregate demand, but presuming it is
>  to moved appropriately,  may I ask the following to make sure we can respond 
>  accurately to your request? 
> 
>  Org A & Org B show up hand in hand, and want to transfer some of Org A's /16
>  IPv4 space to Org B.  Org B completes the documentation requirement, and it 
>  is determined (hypothetically) that Org B doesn't qualify for a /19, but does clearly 
>  qualify for /20 (4096 addresses).
> 
>  Org A has no available continuous block of 4096 addresses, but does have 
>  1 /21 block available and numerous non-adjacent /22, /23, and /24 blocks 
>  block available.  Your policy intent is that Org B may transfer a single block
>  (/21, /22, /23, or /24) but may not transfer multiple blocks from Org A?
> 

I'm not sure what the relevance of the /19 part of your statement above
is. After all, if Org B had a contiguous /19, they would, by definition, have
a contiguous /20 within that /19. (2 as a matter of fact).

Your understanding is almost my intent, but, there is a subtle difference.

My intent is that one of the following should occur:

	1.	Org B has to go find Org C that has a /20 they will part with.
or
	2.	Org A moves some of their utilization around to make use of
		those /22s, /23s, /24s, etc. and free up the remainder of the /20
		which is then transferred to Org B.

In other words, no, Org A should not be able to transfer the /21 and then
come back to the transfer policy immediately for more. They should be
transferring the EXACT AMOUNT of their justified need as a SINGLE
AGGREGATE. (The justification process includes provision that your
need is rounded up to appropriate bit boundaries, so, your need of
800 addresses, for example is a justified need for a /22).

>  If that is the goal, then moving the "as a single aggregate phase" to after 
>  "may only be received" should suffice.
> 
OK... I will work on drafting a modification to the policy along those lines.
That certainly is the clear intent expressed during AC deliberations and
by the community both during the development of this policy and in numerous
messages that have been flying on PPML since the current staff interpretation
was revealed to the community.

>  ARIN will inform the parties that Org B gets to transfer one contiguous address
>  block.  As the parties will have had quite different expectations, the most likely 
>  result is either Org B quickly deploying the block received and immediately 
>  reappearing to transfer another block from Org A (repeat as needed), or it is 
>  more likely Org A and B simply agree that Org B can should use the previously
>  agreed set of address blocks and not bother with updating of the ARIN records
>  after all. 
> 
I recall being on record as opposed to this policy and the abandonment of
2008-2 because of issues like this.

I agree with you that the revolving door issue is an unfortunate artifact of the
current policy and that we probably need to come up with additional
language to address it.

> I hope this helps in consideration of policy,

It does. Thanks for your feedback.

Owen