On Thu, Jul 11, 2013 at 12:32 PM, Mike Burns <[email protected]> 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
