[address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

Hello

As Nick said, unregistered transfer will become problem on updating 
"RIPE Database" and as you know the database is main reason of RIRs mission.

Also IP is IP and it's now important it's on last /8 or not.All IPs 
owner should have same right to transfer/re-allocation.


On 10/19/2016 1:23 PM, Nick Hilliard wrote:
> Marco Schmidt wrote:
>> We encourage you to read the draft document and send any comments to
>> <address-policy-wg at ripe.net> before 17 November 2016.
> The purpose of the policy is to restrict the flow of /22 allocations
> from the RIPE remaining ipv4 pool.  While I'm sympathetic to this idea,
> the policy is not going to fix the problem that it sets out to fix and
> will create a new set of problems which will be extremely difficult for
> the RIPE NCC to recover from.  Consequently I do not support it, because:
>
> 1. the core problem won't be fixed: the outgoing flow of /22s will not
> be affected in any way because speculators will get allocations using
> shelf Companies which can be sold as-is, thereby bypassing any policy
> that the RIPE community might want to consider in this area.  The only
> way to even begin to fix this would be to move back to a needs-based
> allocation policy.
>
> 2. unregistered transfers will become a problem and this may become
> intractable in the future.  This directly goes against the core
> principals of the RIPE database which is to ensure accurate registration
> of address holder details.
>
> Also, asset divesting is not catered for in the policy. If a company /
> LIR splits up, there is no way to handle splitting of IPv4 address
> allocations in the policy.  There is no clear way to fix this problem
> within the principals of the policy.
>
> As an aside note, the problem of ipv4 allocation speedup from the RIPE
> NCC has been exacerbated by the recent RIPE NCC GM resolution: "The
> General Meeting approves the ability of RIPE NCC members to create
> additional LIR accounts".  The net effect of this is that there is now a
> divergence between intended RIPE policy and RIPE NCC implementation.
> This is probably not helpful in the long run.
>
> Nick
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20161020/92c9d13f/attachment.html>