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

[Owen DeLong]

On May 30, 2011, at 8:42 AM, Brett Frankenberger wrote:

> On Sun, May 29, 2011 at 08:46:28PM -0700, Owen DeLong wrote:
>> 
>> On May 29, 2011, at 7:14 PM, Brett Frankenberger wrote:
>>> 
>>> Now I'm confused . The language below says "No organization shall
>>> offer ... more than one address block per year where said address block
>>> is smaller than its original registered size".  
>>> 
>> 
>> You are correct. I missed that in the original and would probably remove
>> it from what I actually would include in the policy.
>> 
>> What I would think makes more sense as policy would be:
>> 
>> Organizations may transfer multiple address blocks but
>> no organization shall receive more than one address block
>> per year where said address block is smaller
>> than its original registered size.
>> 
>> I believe that accomplishes the intent without undue restrictions on the
>> suppliers.
> 
> So, looking at the other side, if Organization A justified a /15, they
> would be allowed to transfer a /16 from Org B and a /16 from Org C to
> get their /15, provided that at least one of the /16s had originally
> been assigned to Org B or Org C as a /16 (so they would be receiving
> only zero or one "smaller than its original registered size" blocks)?
> 

Correct.

> Matthew Kaufman wrote:
>   If the *only* way to fulfill a /14 is to get two /15s, one from each 
>   of two suppliers, that should be allowed as long as there is
>   demonstrated need for the /14.
> and you (Owne) responded:
>   We can agree to disagree.
> 
> Based on your proposed language above, I assume that the disagreement
> is only over the case where both of the /15s are deaggregates of a
> larger original assignment.  If one of the /15s is what was originally
> allocated by ARIN, then it would be allowed?
> 
Correct.

>> You didn't miss anything. I misread Bill's language the first time through
>> and your diligence caused me to re-examine it and propose a corrected
>> version above. Does that seem to do what you think is right?
> 
> See my question above.
> 
> Also, if we have the above restriction (can only receive one
> deaggregate per year), then perhaps we don't need the existing one
> transfer per three months limit.  John has indicated that ARIN will
> interpret the NRPM provision restricting a provider to one allocation
> from ARIN every three months (except in exceptional cases) as also
> restricting a provider to one receipt of address space via transfer
> every three months.  So if we have the single aggregate clause, the
> three month rule, and the proposed "one deaggregation per year" clause,
> then we have a situation where an organization that needs a /15 and
> finds two /16s available, can transfer one of them immediately, and can
> transfer the second one (a) three months later, if one or both of the
> /16s are blocks that were originally allocated as /16s, or (b) 12
> months later, if both the /16s are part of larger allocations.
> 
The one deaggregation per year clause would be in lieu of the
single aggregate clause.

I believe that the proposed language would allow both transfers
to be treated as a single request under 4.1.8 since the single
aggregate clause would be removed.

> I don't think there would be any reason to not allow, if one or both of
> the /16s were originally allocated as /16s, both transfers to complete
> initially.  (Or, if one is located and transferred, and the second one
> is then located one months later, to allow that transfer to occur
> immediately -- so we don't need the three month rule with transfers,
> either.) The point of a "single aggregate" clause and/or a one transfer
> per three months clause would seem to be to prevent deaggregation.  If
> we instead attain that goal more directly, with a "one deaggregation
> per recipient year" policy, then the other requirements are no longer
> needed.
> 

Agreed. Hence the removal of the single aggregate clause.

> Going forward, there may also be a need to think more about the
> definition of "original registered block size".  Today, we are in the
> early stages of this game, and second order transfers (i.e. 8.3
> transfers of space that has already been transferred under 8.3) are
> rare or nonexistant.  But a few years down the road, that might not be
> the case.  

I think this is less of an issue and I don't expect transfers to be a long-
lasting or permanent solution. The transition to IPv6 will most likely
prevent this from becoming significant. If that's not the case, there is
certainly time to address it through future policy.

> 
> Under the "original registered size" rule above, three years from now,
> an organization needing a /15 would be able to tranfer two /16s from
> two different holders of blocks originally assigned by ARIN as /16s. 
> But such an organization wuld not be able to transfer two /16s from
> two different holders of /16s where those /16s were transferred to
> those holders as /16s, but which /16s were originally part of a larger
> allocation from ARIN.  I'm not sure that's a meaningful distinction. 
> Once space is deaggregated, it's not likely to ever be reaggregated. 
> So it doesn't make a lot of sense to distinguish between a /16
> originally provided as a /16, and a /16 originally provided as part of
> a /14, but which /16 was deaggregated and transferred years prior. 
> Either way, it's a /16 that isn't likely to ever be reaggregated, so
> there's no deaggregation resulting from moving it around.
> 
> Of course, if we seek to fix that, we need to do it in a way that
> doesn't encourage two-step transfers just to get around the rule. 
> Perhaps allow a deaggregate to count as an "originally registered
> block" one year (or some other period) after it's transferred as a
> deaggregate.
> 

I think we can skip this complication for now and address it later
if it becomes a factor.

Owen