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/members-discuss@ripe.net/
[members-discuss] Complaints against LIRs ignored by NCC
- Previous message (by thread): [members-discuss] Complaints against LIRs ignored by NCC
- Next message (by thread): [members-discuss] Complaints against LIRs ignored by NCC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William Weber
ripe-members-discussion at edisglobal.com
Fri Nov 22 15:00:16 CET 2013
>> There is clearly a personal vendetta >> here, and it's getting tiresome for the rest of us. Tiresome in what way? The RIPE mailing list is always empty (the last discussion before was from 22nd October, the last one before that on 8th April according to my client) and even this has just a small number of replies considering the receivers. I actually find this discussion and replies very amusing, in special the very different opinions throughout the LIRs (yet in my count most sided with and not against me in most points). It gives me some insight in some LIRs (and data for comparisons based on opinion, LIR size and allocated space as well as service provided, this is absolutely great data for profiling and storage) and possible alliances or more networking for the future. (and before someone asks, metadata or knowledge usage to profile companies or persons and try to predict or analyze future/past is not illegal in any way and protected by the guaranteed business freedom in the EU) This is also not personal in any way, the LIR could be at.telekom or the German government for all i care (In fact, one EU government is the next on my list), it matters exactly zero if sigint and humint sources show up possible (or clear) misusage or violation of RIPE policies . >IPv4 is over. Move on. Focus on deploying IPv6. One of my companies uses *only* native IPv6 and a NAT64 (along with DNS64) gateway for IPv4 access which NATs currently 100 customers per external IPv4 which can be varied up to 2500 per IPv4 stable and without port limitations (unless v4 filesharing is used or large ranges of ports are allocated by the client). I think this is already a *very* good deployment. Please also don't think i don't have an eye on v6 - I already monitor larger than /29 v6 allocations given out by RIPE automatically (like some for years unused large /27s allocated to at.upc and nl.upc, ex. 2a04:2400::/27 (upc.ro)) and assignments in large allocations (larger than /48 and not sub-allocated, /32 and larger not sub-allocated) semi-manually. >> Even if IPs are reclaimed from an LIR as a result of an audit, what difference >> is it going to make? It's not as if RIPE will start allocating from them >> again... That can be changed - It just needs a redesign of the policy and votes for it, woho, democracy. > +1 And please do not reply to his RHETORICAL questions. > > Thomas I can reply to whatever i want with what i want at any point in time i want and so can anyone else that may wants - This is freed Europe, not Cuba. -- William Weber | RIPE: WW | LIR: at.edisgmbh william at edisglobal.com | william at edis.at | http://edis.at | http://as57169.net EDIS GmbH (AS57169) NOC Graz, Austria Am 22.11.2013 um 13:26 schrieb Simon Lockhart <s.lockhart at cablecomnetworking.co.uk>: > If you believe there's fraud being carried out, report it to the law > enforcement agencies - nothing said on this list can fix it. > > IPv4 is over. Move on. Focus on deploying IPv6. > > Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20131122/d2cf0fb4/attachment.html>
- Previous message (by thread): [members-discuss] Complaints against LIRs ignored by NCC
- Next message (by thread): [members-discuss] Complaints against LIRs ignored by NCC
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]