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@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