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

[Owen DeLong]

On May 29, 2011, at 7:49 PM, Matthew Kaufman wrote:

> 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.
> 
Again, I think that this requirement should not be held above the
need for rational policies for address distribution.

>>   * Allow underused numbers to be better used.
> 
> Good, but not absolutely mandatory.
> 

I'd actually argue that this is more important than recording every
transfer and I think that greater use of section 12 is a better way
to address unauthorized or out-of-policy attempts to transfer.

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

Yes. I think that the latest modification of Bill's language (which I just posted
a few moments ago) addresses this nicely.

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

The initial proposal set out to be the smallest surgical alteration necessary
to bring staff behavior in line with the original intent of the policy that was
already adopted. The discussion has led me to reconsider that approach.

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

Funny, I thought the whole point of transfer was to allow $ANY_CORP to
get addresses from $OTHER_CORP when there was no more free pool.

The ability to use excessive capital to jump to the front of the line strikes
me not as a desirable outcome so much as an unfortunate and inevitable
side effect.

>>   * 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'm pretty sure that it can be prevented and that it is less likely to occur
if we have policy that makes it clear that preventing it is the desired outcome
which has community consensus.

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

I'm not sure how you figure that what was added to the NRPM wasn't consensus.
Yes, staff interpreted it differently than almost everyone expected. Additionally, yes,
the make up of the active community has changed since that policy was adopted.

However, it absolutely did have consensus in 2009.

> So we can't "just fix that".
> 

We can, but, I understand that doing so may not be the most desirable outcome.

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

The consensus was for the actual language, but, I am convinced that among that
consensus group, the expectation of what the language meant was not the way
staff interpreted it. The consensus intent was that the single aggregate would
bind with the amount received, not the amount justified.

> 
>> 
>> (*) 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.
> 

Yep.

Owen