<html><body>Why should a large company with many employees and/or high revenue pay more than a small company if they both eat up the same amount of resources at RIPE NCC ? If both small and large LIRs get a /32 IPv6 block they will "never" need anything more as it is sufficient for ~4,29 billion customers. With todays general /32 prefixallocation policy, all LIRs would in simplified terms end up being the same LIR size. If you want to pay less than a big LIR, you simply can't. Perhaps this is good as we would stop having discussions about who should pay what and just divide the bill by the amount of members. If you must discuss something, discuss what RIPE NCC projects that should cut or receive funding instead. I'm sure there are plenty. Cheers, At 13:00 17/07/2012 (UTC), Paolo Di Francesco wrote: <meta charset="utf-8">I support a model that will charge accordingly to "company size" or how much money is made From my point of view, it's not a matter of IPv4-vs-IPv6 allocation war, this should be more a policy based issue and I would support that who does not implement NOW IPv6 and present a plan to implement dual stack in 2 years should loose the IPv4 address space (*). At the same time we should choose a realistic way of measuring the size of a company: bigger will pay more (much more) than smaller. This is because from the small-lir perspective, the percentage of money to be "free and competitive" for a huge LIR is ridicolous compared to what small LIRs are paying today to RIPE. Therefore I do not find scandalous that a bigger LIR that probably makes billions per year (e.g. mobile companies) should pay to RIPE 50K Euros per year. RIPE is not useful only to me, but to EVERY SINGLE EUROPEAN LIR. Moreover, the more resources (e.g. IPv4, AS, etc) you allocate, the more you use the DB, the more you open tickets, etc. Regarding the number of LIRs, the point is very simple: I do not buy directly from a bigger LIR just simply because most of them are not efficient of they would charge me even more than RIPE. It's also a matter of market and etic: the more you wait to have resources that the same LIR is going to provide in hours to your customera the less competitive you are. I do not think it would be a good idea to start a resource suballocation and SLA policy asking to RIPE to be the judge of every suballocation issue between LIRs. So the bigger is the number of LIR, the better is for the WHOLE telco market (and European competitiveness). Now regarding the vote I have some questions: 1) can we delegate somebody to go and vote? If so we could ask to other Lirs or Associations of Providers to step in and do vote for N LIRs. I do not think that would be a problem to delegate somebody who will represent your company, isn't it? 2) do we have a remote mechanism to participate and vote? Thank you (*) big companies in Italy are telling us small LIRs that "there is no device supporting IPv6 we cannot give it" or "mobile phone dop not support IPv6" or "nobody uses it, we do not neet IPv6 we need ONLY IPv4" and "we will discuss about about IPv6 in a few years not now". This is why they told us they are going to implement asap IPv4 NAT on operators side instead of dual stack, interesting hu? > 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. > > ---- > If you don't want to receive emails from the RIPE NCC members-discuss > mailing list, please log in to your LIR Portal account and go to the general page: > https://lirportal.ripe.net/general/view > > Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. > -- Ing. Paolo Di Francesco Level7 s.r.l. unipersonale Sede operativa: Largo Montalto, 5 - 90144 Palermo C.F. e P.IVA 05940050825 Fax : +39-091-8772072 assistenza: (+39) 091-8776432 web: http://www.level7.it ---- If you don't want to receive emails from the RIPE NCC members-discuss mailing list, please log in to your LIR Portal account and go to the general page: https://lirportal.ripe.net/general/view Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses. </body></html>