[arin-ppml] transfer conditions

[Brett Frankenberger]

On Sat, May 07, 2011 at 08:40:57PM -0400, William Herrin wrote:
> 
> Something like... Under NRPM 8, ARIN shall not accept a transfer request:
> 
> a. for an IPv4 CIDR address registration containing fewer than 256 addresses.
> b. which would transfer two or more disaggregate pieces of a single,
> larger aggregate IPv4 address registration
> c. which would disaggregate a CIDR-aligned IPv4 address registration
> less than one year after said aggregate was first registered in that
> exact size.
> 
> a. Nothing smaller than /24
> b. If you break up a block and transfer part of it, you can only
> transfer *one* part of it.
> c. Can't get around B by doing multiple rapid transfers.
> 
> Thoughts?

Org. A has a /18 that it isn't using.  Org. B needs a /19; Org. A
transfers half of its /18.  6 months later, Org. C needs a /20.  Org. A
would like to transfer half of its remaining /19, but can't because of
requirement (c) above.  

In other words, (c) has impacts beyond preventing organizations from
trying to get around (b) by doing multiple transfers.

Getting to where I think you headed is doable, but the language is
going to be a lot more complex.  John's point about keeping it simple
because of all the new players is valid, but there's a certain amount
of complexity that is unavoidable.

The goal is probably something like:  When an aggregate is split to
effect a transfer, it shall be split into the smallest number of
smallest aggregates possible to effect the transfer.  Once that occurs,
for a period of one year, none of the resulting smaller aggregates
shall be further split to effect a transfer, except that to effect a
transfer of an aggregate smaller than the smallest resulting aggregate
still remaining with the holder of the original aggregate, the holder
of the original aggregate may further split the smallest aggregate that
he still holds (and such split shall be into the smallest number of
smaller aggregates possible to effect the transfer).

So if Org. A splits a /19 to transfer a /22, Org. A will be left with a
/20, a /21, and a /22.  For the next year, Org. A can then transfer the
/20, the /21, or the /22, or can further split the /22 to transfer a
/23 or a /24.  If Org. A transferred the /22, it would then be allowed
to split the /21 to transfer a /22, /23, or /24.  And so on.  After one
year from the original split, Org. A would be allowed to split the /20,
the /21, or the /22, to effect a transfer.

Except, no, it needs to be more complicated than what I wrote above. 
If Org. A splits a /19 to tranfer a /22, and then later transfers a
/21, it will be left with a /20 and a /22.  At that point, we'd
probably want them to be able to split the /20 to transfer a /21, but
my language above would prevent that.

So maybe replace
  ... except that to effect a transfer of an aggregate smaller than the
smallest resulting aggregate still remaining with the holder of the
original aggregate, the holder of the original aggregate may further
split the smallest aggregate that he still holds ...
          with
  ... except that to effect a transfer of an aggregate of a size not
existing in the resulting aggregates still remaining with the holder of
the original aggregate, the holder of the original aggregate may
further split the smallest remaining aggregate the he still holds that
is larger than size of the aggregate to be transferred ...

(Anyone wondering why the tax code is complicated should read this
thread.  Some of the complexity comes from political gamesmanship, but
lots of it comes from the fact that defining income is fundamentally
difficult.  Same goes for this policy.  We're going to have to accept a
policy with a lot of loopholes or unintended restrictions, or it's
goign to be a wordy, complicated policy.)

     -- Brett