[address-policy-wg] 2013-03 New Policy Proposal (No Need - Post-Depletion Reality Adjustment and Cleanup)

Hi John,

I had thought I had included a link to it in my ealrler post, but
apparently not, so here it is:

http://www.ietf.org/id/draft-housley-rfc2050bis-00.txt



On Tue, Mar 19, 2013 at 2:08 PM, John Curran <jcurran at arin.net> wrote:
> On Mar 19, 2013, at 11:39 AM, McTim <dogwallah at gmail.com> wrote:
>
>> I think that perhaps we should all read the latest draft of the RFC2050 update:
>>
>> https://www.ripe.net/ripe/policies/proposals/2013-03
>>
>>       1) Allocation Pool Management: Due to the fixed lengths of IP
>>          addresses and AS numbers, the pools from which these resources
>>          are allocated are finite.  As such, allocations must be made
>>          in accordance with the operational needs of those running the
>>          networks that make use of these number resources and by taking
>>          into consideration pool limitations at the time of allocation.
>
> McTim -
>
>   Note that you are referencing an Internet Draft which is only
>   barely announced and yet to be considered by the community.
>   The document is actually lists several additional goals
>   (i.e. Hierarchical Allocation and Registration Accuracy) and
>   they are to be considered as a whole, not taken singularly:


agreed, did not mean to imply otherwise, but only meant to
highlight (by quoting) the bit that conflicts with this proposal.


>
>    "These goals may sometimes conflict with each other or be in conflict
>     with the interests of individual end-users, Internet service
>     providers, or other number resource consumers.  Careful analysis,
>     judgment, and cooperation among registry system providers and
>     consumers at all levels via community-developed policies is necessary
>     to find appropriate compromises to facilitate Internet operations."
>
>   (This is very similar to language in the existing RFC 2050.)
>
>   I have no view on the policy proposal, either supporting or against,
>   but want to make clear that the RIPE community should decide what
>   is best for it overall and not feel constrained by a reference to
>   just one of these goals (whether from existing or revised RFC2050)


agreed.
-- 
Cheers,

McTim
"A name indicates what we seek. An address indicates where it is. A
route indicates how we get there."  Jon Postel