[address-policy-wg] 2015-05

Hello Sylvain,

The policy is centered around LIRs and  granting additional IP space,

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-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20151023/b6e3a173/attachment.html>