If a Lir has merged "legitimately" with another lir, they have benefited from the addtitional space, from the merger, and it would be legitimate to say that the Merged Lir is getting the same space as a Lir that didnt merge with anyone else.
I would be infavour of this policy if there are constraints, so that it does not give ip space to Lirs that used other mechanisims to increase their ip entitlements,
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Good evening,
On 22/10/2015 09:48, Tom Smyth wrote:
> I think it would be reasonable that if an entity has merged from
> another lir... they have already recieved one or more /22s over and
> above what ripe intended. So these entities have already benefited
> from gaining additional ips
>
> So it would be fair to exclude such lirs from getting another /22
> under this policy proposal
I don't, because there is a confusion here between the LIR and the
End User, the LIR being limited to a /22 whereas several End Users
having the same LIR would be legitimate to have, say, a /24.
So, some level of need-based criteria should not have been abandonned
here and the trivial case where a LIR is a single entity that uses all
of its allocations for itself should be questionned, since the PA and
assignment system is clearly made to distinguish LIR and operator and
is supposed to be the normal case.
Therefore, creating and merging LIRs can be a very legitimate way to
allow new entities to get a minimal IPv4 space, regarding the spirit
of the last /8 policiy.
Also, policies should not be studied from the only point of view of
a LIR but also from the End User's viewpoint, which could be a much
more legitimate approach.
Best regards,
S. Vallerot
- --
http://www.opdop.fr - mutualiser et interconnecter en coopérative
Opdop - Société Coopérative d'Interêt Collectif sous forme de SARL
sur IRC réseau geeknode #opdop - tél: 0950 31 54 74, 06 86 38 38 68
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlYpR2QACgkQJBGsD8mtnRFbcwD9FYxfB1xUzWiJzIljySVPOJMi
g5za8bCmCAvlFzzUJv4A/jKSpFup9xH/J+XlqNgN1ZuS6f1/4j9f8pfFO/kYr43X
=K42N
-----END PGP SIGNATURE-----