[members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
- Previous message (by thread): [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
- Next message (by thread): [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friacas
cfriacas at fccn.pt
Thu Sep 15 09:46:01 CEST 2016
Hi, On Thu, 15 Sep 2016, Bastien Schils wrote: >> Ultimately RIPEs "job" is to maintain a list (DB) and as a community, >> set policy for getting things onto that list. >> >> Each LIRs "cost" to RIPE is administrative (membership management, >> sending letters etc) and _somewhat_ proportionate to how much data >> they have in that database (and how much support/manual-work they need) >> >> The numbers in the "starting ip" and "ending ip" fields don't change >> that cost, effectively a /32 "costs" no more or less than a /8 - 1 >> record in a db is 1 record in a db >> > "We're an independent, not-for-profit membership organisation that supports > the infrastructure of the Internet through technical coordination in our > service region. Our most prominent activity is to act as the Regional > Internet Registry (RIR) providing global Internet resources and related > services (IPv4, IPv6 and AS Number resources) to members in our service > region." > > It clearly states "providing global Internet resources and related services" > and not "maintaining a DB". Isn't maintaining a DB part of "related services"? > The more you use resources, the more you cost to maintain. That seems fair. > >> > Goal: Kill off IPv4 by 2025? >> >> A goal to have all "publicly accessible internet devices accessible >> over ipv6" makes sense, but there is (and never will be) a "need" to >> kill off ipv4. > We are drifting off topic here. But I suggest that you reconsider your > position. "Kill off IPv4" doesn't sound like a useful motto... >> > I believe a full switch to IPv6 is everyone's long term interest. >> >> It's certainly not in "everyones" interest - there are millions of >> IPv4-only devices out there, it's not in the owners interest to have >> to buy (even if it was possible to replace) new ones. > It is in the greater-good's interest. For me, the thin line (that needs to be crossed) is going from a situation where IPv4 is dominant (and IPv6-only devices need translation services), to a (global) scenario where IPv6 is dominant (and IPv4-only devices need translation services). Translation is kind of costly, afaik, also performance-wise... >> > If another LIR has a hundred times more IPv4 addresses than we do, >> > then I'd expect them to pay 100 times (or more) than we do. >> >> And therein lies the difference in thinking - if one LIR uses 100 >> times the "resources" than another then yes, a larger bill could be >> appropriate. But a range of ips is ultimatley just "1 resource" - it >> doesn't matter about the size of that range. > Let's take it from another perspective: > If a LIR has 100 more IPs than another, wouldn't it be expected to think that > this LIR is 100 times more likely to need actions from the RIPE? > > Well, in my opinion: Yes. I'm not sure about that..... newcomers (which by the current policy only get a /22) are probably where the NCC is spending the largest part of their effort. Is there any measurement already? Maybe a topic for RIPE Labs? :-) >> Making IPv6 resources "cheaper" might be an incentive to adoption, but >> I doubt it. >> >> Getting the bulk of "end users" on IPv6 is (and always has been) the >> only real way to drive usage up, and in general end-users neither know >> nor care, IP is IP is IP at the end of the day >> > Agree. Yes, transparency to the "end users" is key in this process. I'm also not sure how IPv6 resources could get any cheaper. Cheers, Carlos (pt.rccn)
- Previous message (by thread): [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
- Next message (by thread): [members-discuss] Input from Membership on RIPE NCC Charging Scheme Model
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]