[address-policy-wg] 2015-05

Sylvain,

I wasnt lecturing, just outlining my postion,

the point of the policy is that is is a form of reprieve to allocate more
Ipv4 resources to Lirs, and I think that any Lir as I have said before that
have benefited from merging with another lir to get Ip address space to
assign to end users or other wise, shouldnt be allowed to benefit from this
policy.

I hope in this context you understand my position

Thanks

Tom Smyth

On Fri, Oct 23, 2015 at 4:30 PM, Sylvain Vallerot <
sylvain.vallerot at opdop.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 23/10/2015 16:51, Tom Smyth wrote:
> > The policy is centered around LIRs
>
> Which is the basis of your further deductions, but I disagree with this
> first statement. I do not means it is not the case, nor deeply understood
> as this, I just disagree on the relevance of this lecture regarding to
> the spirit and goal of the last /8 policy.
>
> LIRs are delegated some authority from the RIR (that is delegated authority
> from ARIN), LIRs are not those who are supposed to use the ressources in
> the End. So distribution of ressources to LIRs is a wrong perspective, the
> goal being to have ressources available to End Users, the last /8 that
> limits
> available ressources to a /22 per LIR would be better deserving their goal
> by fixing some ressource quantity to be available to End Users. Of course,
> this is difficult to do, and most participants here seem not to consider
> the difference between LIR and operator/end user.
>
> So according to the last /8 policy goal (spirit if not letter), LIRs
> merging to get End Users to be able to access some little ressources is
> perfectly legitimate.
>
> We as a cooperative LIR do no use ressources for ourselves, but for End
> Users
> only, so as a LIR, being limited to a /22 is not relevant to us, because it
> just has the effect to limit the number of End Users that can have access
> to
> a minimal part of the IPv4 last bits to bootstrap. Is it the goal of this
> policy ? No it is not.
>
> So to allow new comers to emerge (with a single /24 sometimes) the only
> possible way today is (several of) them to create a new LIR together and
> later merge it to ours. And this does perfect sense if last /8 policy is
> there to allow newcomers to emerge.
>
> You thinking as LIR = End User having a /22 means a /22 per newcomer. When
> you have in mind that a /22 is a potential of 4 x /24 end users instead,
> then you deserve the last /8 policy 4 times as much.
>
> Maybe limiting the M&A to PAs containing space already assigned to enough
> independent (maybe even routable, with an ASN ?) operators, and garanteed
> to
> remain so for quite a long time) would be fine.
>
> Best regards,
> Sylvain
>
> - --
> 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
>
> iF4EAREIAAYFAlYqUq0ACgkQJBGsD8mtnRGnowEAkJ9DTr65tpRap+4tTLTfO+jK
> 2wXLItRWhxFWnw2t3U4A/j6d7Hb3nJKSQN72lSGCsEHq0QSxSFSIXPL9KvxGbIo8
> =N+ff
> -----END PGP SIGNATURE-----
>



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
---------------------------------
PLEASE CONSIDER THE ENVIRONMENT BEFORE YOU PRINT THIS E-MAIL
This email contains information which may be confidential or privileged.
The information is intended solely for the use of the individual or entity
named above.  If you are not the intended recipient, be aware that
any disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic
transmission in error, please notify me by telephone or by electronic mail
immediately. Any opinions expressed are those of the author, not the
company's  .This email does not constitute either offer or acceptance of
any contractually binding agreement. Such offer or acceptance must be
communicated in
writing. You are requested to carry out your own virus check before opening
any attachment. Thomas Smyth accepts no liability for any loss or damage
which may be caused by malicious software or attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20151023/84c95974/attachment.html>