[members-discuss] A summary for Proposal for New RIPE NCC Charging Scheme Model
Lu Heng h.lu at anytimechinese.com
Sat Jul 14 15:29:45 CEST 2012
Hi I think this discussion is going a cycle in past few days, I think I'd like to do a little here for fellow colleagues so make more people understand what have been going on. Let me start with a summary here, every time I saw two argument together with two main charging suggestions. Argument 1: fees should related to Ripe NCC workload rather than address distribution.(in the sense that Ripe NCC is in fact NOT RIPE, it is just a secretary service offered to people who need help from the community, the more help you have, the more you pay). Argument preferred model: work-load based, or at least everybody pays same. Argument 2: Fees should related to address distribution because the more address you have, the more valuable you are, and you of course should pay more.(in a time IPv4 are almost ready to become trade-able commodity, this might make sense). Argument preferred model: IP address share based.(at present time, since IPv6's trade value are not clear in future 10 years, this mostly refer to IPv4) p.s. since every time this argument being bought up always being followed by reply like "someone still stay in ipv4 will die", just to make clear that here is pure discussion in a business cost sense in which has nothing to do with the discussion if we should go for ipv6 or not. And Let's do a quick calculation to see which argument preferred to which party. If we charge people by price per address..then...here's a simple math: Total Ripe address:32.78 /8=549957140.48 about 550millions. Total Ripe expenditure each year: 20millions Euro. 20/550=0.0367 per address each year. So most small LIR(2048 address) will pay ...74 Euro/year. and if you are media LIR(with /16), you will pay... 2405 Euro/year. And if you are large LIR(people with /8), then you will pay 615723.8272Euro/year(for people agree on argument two, companies in real world with over /8, of course should be very well above millions income level, so it shouldn't be a problem for them). However, please note, if a charging model based on IP address number is being done, then the total Ripe expenditure might increase due tax changes. Let's say the premiums are 50% additional cost. For small LIRs, they will pay 130Euro a year, for media, it will be 3700 euro a year, and for real large ones, it will be around 1 millions euro a year. And if everyone pays same: 20,000,000/8000=2500Euro/year So, in term of pure cost assumption, media and large LIR will prefer a model close to "everyone pays the same", while for small and extra small LIRs, cost per IP is much more preferred even Ripe starting pay taxes. Since theoretically every LIR has one vote regardless their size, cost per IP model might get passed consider the number of small and extra small LIRs. But...there is a reality that most small and extra small LIR never attended any Ripe event...not even come to vote while most large ones always do. So in term of that, large ones are in fact paying more for make community more active(sending one person to Ripe meeting will at least cost 2000 euro a time consider the working time loss and all the other expenditures), and of course they have more power in the vote, as no matter how much voting power there is for small LIRs, if they don't use it, they don' have it. Hope this summary can help everybody have more clear view of what is going on in past discussions and future better future discussion. -- Kind regards. Lu This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received.