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] New Charging Scheme
- Previous message (by thread): [members-discuss] New Charging Scheme
- Next message (by thread): [members-discuss] New Charging Scheme
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Simon Lockhart
s.lockhart at cablecomnetworking.co.uk
Thu Aug 4 11:39:11 CEST 2011
On Thu Aug 04, 2011 at 09:39:28AM +0100, Daniel Suchy wrote: > On 08/03/2011 12:46 PM, Simon Lockhart wrote: > > Why should an LIR having a /16 (I assume you mean /16 not /18) pay more > > than an LIR having a /17? Does it cost more for RIPE to support the LIR > > with a /16 than the LIR with a /17? Possibly the answer is yes, but it's > > not because they have a /17 rather than a /16. > > One of expected RIPE NCC tasks is analysing proper use of allocated > resources by each LIR. Mainly, this happens when LIR asks for new > resources - but also in other case like LIR audits. And analysis of /16 > block is more exacting than /17 analysis. > > Mentioned audits aren't classic LIR support - members usually doesn't > ask for their audits and of course, these audit costs some money :-) Oh, indeed, and I see that this is part of what either the "per allocation" fee should cover. I strongly believe that RIPE should not set a "price per IP", as their role is not to create some sort of commercial marketplace for internet objects (be they v4 or v6, or other sorts of things which RIPE allocate like ASNs), but rather to be the registry for these allocated objects. Yes, I accept that a larger allocation request will take more of RIPEs time than a smaller allocation, but we should agree whether a one-size-fits-all pricing model is what we want, or some sort of sliding scale based on the amount of effort which goes into evaluating and registering an allocation request. For example, here's another pricing model which could work (prices completely made up on the spot, so don't judge fairness on the numbers I use): Membership Fee (per year): EUR 1000 Per allocation costs: First Year Subsequent Years IPv4 (up to /22): EUR 100 EUR 50 IPv4 (/21 to /20): EUR 200 EUR 50 IPv4 (/19 to /16): EUR 400 EUR 100 IPv4 (/15 to /12): EUR 800 EUR 100 IPv4 (over /12): EUR 1500 EUR 200 IPv6 (/32): EUR 100 EUR 50 IPv6 (Over /32): EUR 400 EUR 50 ASN: EUR 100 EUR 50 Other objects: EUR 400 EUR 50 In here, the membership fee is designed to cover all the other RIPE services - Atlas, Labs, Meetings, etc, etc. There is of course the option to have a "Membership Lite" at a reduced rate with restrictions (only one IPv4, one IPv6 and one ASN allocation, no access to other services or RIPE meetings). An analogy here is IX charging (I'll use LINX as an example, as it's the one I'm closest to). You pay a base 'membership fee'. The ports you take on the exchange are like allocations - they come in broad sizings - 100M, 1G, 10G. LINX tried usage based charging (i.e. like paying per IP), and it was hard to bill, and disliked by the members. There's a higher cost to the IX when you first take a port (i.e. get an allocation) - install fee plus service fees - but the ongoing running costs - just service fees - are lower because there's less work to do. Simon
- Previous message (by thread): [members-discuss] New Charging Scheme
- Next message (by thread): [members-discuss] New Charging Scheme
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]