[arin-ppml] ARIN-prop-153 Correct erroneous syntax in NRPM 8.3
rbf+arin-ppml at panix.com
Mon May 30 11:42:08 EDT 2011
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
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)?
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?
> 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.
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
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
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
All this seems complicated, but necessarily so, I think, due to the
competing objectives and the strong incentive to seek loopholes that
will exist once ARIN runs out of space.
As far as doing what I think is right, I have previosuly commented that
a limit on transfers per unit time was the only realistic way to
prevent massive deaggregation, but I now think a limit on
deaggregations (such as you propose above) to a single entity per unit
time might be a better approach to that goal. But I'm not certain.
(One clear effect of the policy is to place a higher value on blocks
offered for transfer that were originally registered in the size being
transferred. An organization would pay more for a block that wouldn't
use up their one deaggregate for this year than for a block that would
use up their one deaggregate for the year and restrict them to
transferring onyl whole blocks for the next year. That's probably
good, but it's not clear ...)
More information about the ARIN-PPML