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:

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.