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]/
[members-discuss] VL: IP transfer (in)security
- Previous message (by thread): [members-discuss] VL: IP transfer (in)security
- Next message (by thread): [members-discuss] VL: IP transfer (in)security
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
William
william at william.si
Wed May 16 22:31:06 CEST 2018
>I see no problem with paying for services based on fair share of usage. But your example of reverse DNS as a yardstick for measuring fair share is a poor one. The burden on RIPE to maintain such records does not change with size of address space. If we calculate it down to just legacy users that do not pay a LIR account or PI fees the operating costs are double/triple digit €/year *at most*, i'd commit just out of spite to pay them for some years for everyone. >So on any price increase that you know a loophole for to avoid. Well, obviously he/others/i do? I do not see this as any problem, it is nothing forbidden or 'wrong'. Hell, if RIPE charges me per size for legacy i can pay it as PI, if they do it for PI or increase PI fees insanely... it's still mine, it might end up with APNIC or "DB fixed" unchangeable but free/lower cost (and everyone else that has no choice to move will be punished). >Well, then we should plug said holes. Sure? You seem to understand how the process works within RIPE, but this will ultimately just end as above, our loophole is not really fixable (i think we now all know "taking legacy IPs away" is theft de-jure, right?). --William WeberConsulting, Security & Management - Tel-Aviv, Israel / Rijeka, Croatia https://ip6.im (https://ip6.im/) - No RIPE LIR? Still read this email for some reason? Grab a /40 *free* IPv6 space for BGP usage. Or just get it anyway, can't hurt to have. On Wed, May 16, 2018 at 19:27, Floris Bos wrote:On 05/16/2018 02:04 PM, Muntasir.Ali at newham.gov.uk (mailto:Muntasir.Ali at newham.gov.uk) wrote: I shall reply because I am being misquoted. I did not say my employer would drop membership due to _any_ price increases. Only that within the context of if the charging model were to change to be based upon size of IPv4 allocation, then in that scenario it makes financial sense to spin off a 2nd LIR to separate registration of Legacy and non-Legacy space, then drop membership for the Legacy owner. So on any price increase that you know a loophole for to avoid. Well, then we should plug said holes. We would then retain membership under the lower-cost 2nd LIR. But again, this only applies to the charging models being proposed in the discussion at that time, and is not how I expect our organisation to behave under the current models. Yes, since the board seems unwilling to put up any proposal to change current model up to vote, you are indeed pretty safe for now. Only thing us folks that are not satisfied with the current situation can do is vote against the 2019 charging scheme today. But no alternative to vote on instead is provided... Oh well, could try to get the 2% of members necessary to put a voting point to the agenda (with or without the board's blessing) next year. Now, allow me to remove my employee-hat: I see no problem with paying for services based on fair share of usage. But your example of reverse DNS as a yardstick for measuring fair share is a poor one. The burden on RIPE to maintain such records does not change with size of address space. There is no burden to create and update records when you have automated systems. And would argue that your /16 causes more lookups, than the /22 we have. I also think it's kinda interesting to have this conversation with a city council. Don't you set the rate of council tax on factors like property value as well? Yours sincerely, Floris Bos -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20180516/5b27bd16/attachment.html>
- Previous message (by thread): [members-discuss] VL: IP transfer (in)security
- Next message (by thread): [members-discuss] VL: IP transfer (in)security
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]