[arin-ppml] Thoughts on Conservation [was: Re: Draft Policy ARIN-2013-4: RIR Principles - revised]

Chris Grundemann cgrundemann at gmail.com
Thu Jul 11 15:14:49 EDT 2013


On Thu, Jul 11, 2013 at 12:32 PM, Mike Burns <mike at nationwideinc.com> wrote:
>
>>> I say that conservation as effected through RIR policies have never been>
>>> directed at the utilization of allocated addresses, except in the context of
>>
>> additional free pool allocations.
>
>
>> That should read "except in the context of additional allocations."
>
> The free pool has nothing to do with it. Really. If you want more
> addresses (from any source) it seems perfectly reasonable to ensure
> that all the other addresses you have are actually being used, if they
> are not, you don't need more addresses. This feels like common sense
> to me.
>
> That's right, the only time utilization was considered was in the allocation
> of new addresses, but if there truly is a conservation principle that
> applied to the entire address space, then we should not have specifically
> said that we would *not* consider utilization in the RSA. To me it is
> entirely unreasonable for stewards to extend their grasp beyond what is
> minimally required. Really, the free pool has everything to do with
> conservation in RFC-2050, as did RFC-2050's language about transfers, which
> was in place to protect the free pool from repeated allocation/transfer
> cycles by bad actors.

>From RFC 2050:
   1) Conservation: Fair distribution of globally unique Internet address
   space according to the operational needs of the end-users and Internet
   Service Providers operating networks using this address space.
   Prevention of stockpiling in order to maximize the lifetime of the
   Internet address space.

"Internet address space" != "free pool"

>>> Considering that as stewards we were charged with growing and sustaining
>>> the
>>
>> Internet, it made absolute sense to try to get as many addresses allocated
>> as possible, constrained only by the need to protect the free pool from
>> bad
>
>
>> Again, the constraint was and is protection of the number space, you
>
> are elevating the free pool to an unwarranted level of attention in
> order to claim that the principle disappears with the free pool. The
> fact remains that we are discussing conservation of the entire
> Internet number space(s) and have never been explicitly limited to
> conservation of the free pool. In fact, conservation of the free pool
> is antithetical to conservation of the number resource as a whole
> because our goal is efficient utilization, not maintaining a perpetual
> free pool.
>
> IMO, you are erroneously elevating the allocated pool to a level which
> requires some foggy conservation principle be applied to it, which the RSA
> seems to ignore.
> I am describing the thought processes that went into the writing of the
> RFC-2050, why conservation was necessary, and why it only applies to
> unpriced addresses.
> You continue to claim that what we are discussing is the conservation of the
> entire Internet space, but that is merely an assertion on your part. Your
> last sentence there makes no sense if you contemplate bad actors accessing a
> free pool with no conservation principle attached.
>
>
>
>
>> I have not seen anyone propose that we dismantle the existing paradigm
>
> (save those who wish to drop needs assessments completely) nor anyone
> proposing a new ongoing audit and revocation mechanism. Let's stick to
> the facts and proposals that are on the table, I'm passionately
> against the slaughter of unicorns but I doubt that's relevant to this
> discussion...
>
> You are the one proposing change here.
> And even though there are not currently any proposals on the table to begin
> auditing and revokations, the placement of the conservation principle in the
> NRPM with the assertion that it covers all addresses will act to bolster any
> such pending proposal. That's why I am opposed to the proposal.
>
> Regards,
> Mike
>
>
>
>



-- 
@ChrisGrundemann
http://chrisgrundemann.com



More information about the ARIN-PPML mailing list