This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Support for 2016-03 v2.0
- Previous message (by thread): [address-policy-wg] Support for 2016-03 v2.0
- Next message (by thread): [address-policy-wg] Support for 2016-03 v2.0
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Suchy
danny at danysek.cz
Sat Jun 18 23:38:38 CEST 2016
Hello, even I uderstand motivation, I cannot aggre with Ondrej. IP address was, is and always will be only technical resource - and we're loosing that point in APWG.... And such policy is quite unfair to "new" LIRs (holding only last /22) - as it's trying to revoke rights, which have "old" LIRs holding old allocatios before "last /8" policy was introduced. I think we cannot make difference between "old" and "new" allocations - in terms of last /8 policy, where we're taking care only about address space allocated after certain date. There's RIPE analysis about address really available: https://labs.ripe.net/Members/marco_schmidt/taking-a-closer-look-at-the-last-slash-8 - and I don't undersand such "panic", as numbers about space available are pretty clear... Do we really want do block new organisations with new allocations, but allow old (happy) one to do anything with addresses tehy have...? That's not fair. Motivation mentioned above is shift movement to IPv6 - but, basically holders of smaller/never allocations have IPv6 implemented already (or at least are trying to implement) - or in IPv4, they have deployments of CGNAT solutions already. There're organisations, which have large allocations and they're sometimes not taking care - they have enough IPv4 addresses, nothing is pushing them to implement IPv6, or save address space by implementation of some NAT solution. If they decide to sell their business, policy will allow that - but, if "new" resource holder will try similar thing, policy will ban then? My point is simple - there should be ONLY ONE POLICY - independent on time of allocation. Such policy must limit not only new LIRs (using addresses from last /8), but also old LIRs holding addresses from old allocations. And if we really want to reclaim some address space, we should review current allocations - in terms of current situation in IPv4 world. With regards, Daniel On 18.06.16 22:45, Ondřej Caletka wrote: > On Thu, Jun 16, 2016 at 04:14:08PM +0200, Remco van Mook wrote: >> Basically the only restriction left is to disallow transfers on all "last /8 space"* going forward, and there is some language added to the policy that tries to raise awareness that if you just go and parcel out that entire allocation to endusers, you might end up feeling a little bit silly a couple of years from now. > > Hello list, > > I support this version of 2016-03. I think the allocations made after > entering the post-depletion phase (that could be maybe a better name > than the "last /8") should be either used for operating a network or > returned to RIPE NCC. > > Since there used to be a needs-based policy for pre-depletion > allocations, stockpiling addresses for the sole purpose of selling them > in the future was not as trivial as it is now. One had to not only have > enough money but also cheat in the needs evaluation process.Now, when > the needs-based approach is gone, we need something else to conserve at > least something for new players for as long as possible. > > I also like the idea of special status "ALLOCATED FINAL". I think it is > a good starting point for the AGM to adopt a charging scheme which would > require additional recurring fee for LIRs holding more than one such > allocation. This is IMHO the only way how to prevent people from opening > new LIRs as a better alternative to the IPv4 market. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: OpenPGP digital signature URL: </ripe/mail/archives/address-policy-wg/attachments/20160618/a46d94a9/attachment.sig>
- Previous message (by thread): [address-policy-wg] Support for 2016-03 v2.0
- Next message (by thread): [address-policy-wg] Support for 2016-03 v2.0
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]