[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3

[Matthew Kaufman]

On 5/29/2011 3:54 PM, Gary Buhrmaster wrote:
> On Sun, May 29, 2011 at 22:02, Matthew Kaufman<matthew at matthew.at>  wrote:
> ....
>> I'm not sure what you're trying to do here. If the problem is
>> dis-aggregation of blocks, why don't we propose a change that limits the
>> dis-aggregation on the supply side?
> I think this is one of the problems I continue to struggle with
> regarding the entire transfer policy.  It attempts to try to
> accomplish many things.  Among those I would include:
>
>    * Ensure that any/all such transactions are properly recorded.

Definitely required.

>    * Allow underused numbers to be better used.

Good, but not absolutely mandatory.

>    * Minimize dis-aggregation

Agreed. Somewhere on the spectrum between "no transfers that are smaller 
than /24" and "no transfers that are smaller than the size of the block 
as originally allocated by ARIN" makes sense. The former could cause a 
lot of table bloat, the latter makes it very hard for the /8 holders to 
help anyone in need.

I think there's probably a good policy proposal here around "carving 
limits"... like "a supplier may divide their block into as many as 4 
pieces on bit-aligned boundaries once per year"... perhaps adding 
something like like "a block originally allocated as bigger than /16 may 
be broken into pieces no smaller than a /16, and thence per the above" 
to get the /8s in circulation sooner. And then make sure that the limits 
follow the block so that the buyer is on the same timer.


>    * Allow $DESPERATE_CORP$ to move to the head of the number
>      queue via the directed transfer policy by paying for that privilege
>      (to the supplier).

That's the whole point of transfer, yes.

>    * Prevent $MEGA_CORP$ from buying all available numbers (perhaps
>      one /24 at a time, infinitum).

Not sure this can be prevented if they have enough money. For all we 
know, someone has already purchased the right of first refusal on nearly 
all of the space and the holders just haven't mentioned that to anyone.

> I am not entirely sure that the existing policy consensus will
> actually do these things well (and while I can conjecture with
> the best, until we get deeper into runout/transfers, my crystal ball
> is still cloudy).
>
> However, that all said, I think it is important that if the intent
> of the consensus is not being implemented (because of vague
> or inconsistent language), we should try to *just fix that* now
> (and let another policy proposal open all the discussion on
> what is the "right"/"best"/"different" policy).

The problem is that what was added to the NRPM probably wasn't consensus 
*and* staff interpreted NRPM differently than some folks expected.

So we can't "just fix that".

> So, I support this proposal moving forward to correct the
> implementation to match consensus.
>

Which consensus? The one from before the actual language was added? What 
people *thought* 8.3 meant? What we realize we want now?


>
> (*) However I also struggle here with the case that why should a supplier
>      have any additional restrictions to dis-aggregate than would ARIN, if
>      the same numbers were available to ARIN.  I know I have multiple
>      minds regarding this issue.

I think the point here is to try to put some known upper bounds on how 
fast the table might grow post-runout... noting of course that the BGP 
table might fragment faster than the actual whois registrations for a 
variety of reasons.

Matthew Kaufman