[members-discuss] Input from Membership on RIPE NCC Charging Scheme Model

I agree with Lu and I think everyone is missing the point and Lu made a 
very valid post.

If you shift the burden of cost from where it is effectively 'equal' 
based on per LIR, to based on IP consumption. Small LIR's with say just 
the single /22 would be paying a couple hundred euro per year. RIPE is 
*not a for-profit business*. It is there to provide services, and cover 
the costs of those services which in the whole grand scheme of things is 
a big fat phone book of who has what IP space. Nothing more, nothing 
less. You can't expect RIPE, ARIN or any other RIR to try and use money 
as a leverage point to force IPV6, they just don't have that kind of 
power. Do you really believe that if they tried something like that, 
they wouldn't be sued into the stoneage? Why do you think legacy IP 
space still exists, because contracts had been formed and signed giving 
ownership of those blocks to the purchaser prior to the RIR's existence 
and the RIR's don't have a legal leg to stand on to get that back.

Everyone just needs to keep in mind what a RIR really is, respect that, 
and go on with life, and not try and make it something it isn't or can't 
become.

Daniel~

On 09/14/2016 05:04 AM, Lu Heng wrote:
> Hi
>
> I think the current fee are really low enough to a point even 
> intensive some abuse of the policy in which was heavily debated both 
> in policy discussion and member discussion for past years.
>
> If we start asking big one paying 5000 euro a year(in which I don't 
> think they would care), then unless RIPE tomorrow start spending 100 
> million a year, we will have to charge small one with 1000 IP around 
> 200 Euro or 500 Euro a year...image the situation then.
>
> We will effectively finish the last /8 in a second.
>
> We have to asks for the great management of RIPE NCC, for the amount 
> of work they have done for the amount of member, they are very good 
> value for the money:)
>
> In a large picture, the cost to run RIPE NCC are really fiction of 
> what's the total value of the IP address, so there is no way financial 
> incentive in fees would change anything.
>
> My 2 cent.
>
> With regards.
>
> Lu
>
> On Wed, Sep 14, 2016 at 11:40 AM, Paul Webb 
> <Paul.Webb at clearstreamgroup.co.uk 
> <mailto:Paul.Webb at clearstreamgroup.co.uk>> wrote:
>
>     Good points Chris and I'd have to agree. The large LIR's (who
>     gained their large and largely unused IPv4 resources many years
>     ago at no cost) have many reasons not to prioritise IPv6, so they
>     aren't doing so.
>
>     Certainly RIPE, but organisations such as the IX's, could also
>     start making IPv4 more expensive and help the migration and I'd
>     argue they should be. Sadly the larger LIR's have a
>     disproportionate influence in all the important places, which
>     doesn't help.
>
>     I'd agree there are may be pinch points in many networks where,
>     for example, even *slightly* older routers have lower throughput
>     with IPv6 (we've CISCO's that route IPv4 in hardware and IPv6 in
>     software for example) and I guess that stuff has to be assessed
>     and worked though still in many networks.
>
>
>     -----Original Message-----
>     From: members-discuss [mailto:members-discuss-bounces at ripe.net
>     <mailto:members-discuss-bounces at ripe.net>] On Behalf Of Chris Smith
>     Sent: 13 September 2016 20:57
>     To: members-discuss at ripe.net <mailto:members-discuss at ripe.net>
>     Subject: Re: [members-discuss] Input from Membership on RIPE NCC
>     Charging Scheme Model
>
>     Hi,
>
>     "How you calculate these costs would of course depend on a number
>     of different factors and I can see different members proposing
>     things to their own benefit (and therefore the detriment of
>     others) without reference to a single “goal”."
>
>     It seems clear to me that LIR's that have large IPv4 resources are
>     at an economic advantage against LIR's with small IPv4 resources.
>     The current Small, Medium, Large model seems to be setup with this
>     in mind.
>     When it comes to IPv6 it's irrelevant, and perhaps a single
>     pricing model would be more appropriate in this case.
>
>     Trying to stay impartial (impossible but...), how about:
>
>     Goal: Kill off IPv4 by 2025?
>
>     I believe a full switch to IPv6 is everyone's long term interest.
>     I'd like to see some form of IPv4 switch off target date set and a
>     financial incentive model to encourage full deployment.
>     Increasing costs for IPv4's in a disproportionate way, and
>     artificially making IPv6 ready networks lower cost should do it?
>
>     My take on this would therefore be to have a notional membership
>     cost say 1 euro, and for the time being move to charging primarily
>     based upon IPv4 resources and give discounts to each LIR that
>     declares they're ready for an IPv4 switch off.
>     To compensate for the economic advantage LIR's with large amounts
>     of IPv4's have, a weighting could be applied to make each IPv4
>     address proportionally more expensive as well.
>
>     If you think about it I don't think it's that far off from the
>     thinking behind the current charging model.
>
>     Speaking as a small LIR/ISP the current charging model appears to
>     favour uptake of IPv6 by smaller LIR/ISP's, not the larger ones,
>     where in my opinion it really matters.
>     If you look at the UK for example, I can't think of any large
>     LIR/ISP that is fully IPv6 ready (there's only one I can think of
>     that isn't too far off), yet I can think of many smaller ones that
>     are 100% good to go and have been for some time.
>     I think once all the large networks are IPv6 ready, everyone else
>     will follow suit very quickly, and all LIR's should be much
>     happier once "IPv4 scarce resources" are no longer required.
>     I understand that large networks are inherently more complex,
>     however, they are usually much better funded as well, and imho
>     should contribute proportionally more to the RIPE coffers.
>
>     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.
>
>     Regards
>
>     Chris Smith
>     Subtopia Ltd
>     t.+44 (0)121 638 0888
>
>     -----Original Message-----
>     From: members-discuss [mailto:members-discuss-bounces at ripe.net
>     <mailto:members-discuss-bounces at ripe.net>] On Behalf Of James Blessing
>     Sent: 13 September 2016 12:59 PM
>     To: Nigel Titley; members-discuss at ripe.net
>     <mailto:members-discuss at ripe.net>
>     Subject: Re: [members-discuss] Input from Membership on RIPE NCC
>     Charging Scheme Model
>
>
>
>
>
>     On 13/09/2016, 12:15, "members-discuss on behalf of Nigel Titley"
>     <members-discuss-bounces at ripe.net
>     <mailto:members-discuss-bounces at ripe.net> on behalf of
>     nigel at titley.com <mailto:nigel at titley.com>> wrote:
>
>     >    The Executive Board therefore proposes to discuss this issue
>     at the
>     >    upcoming GM. We ask that prior to the GM the membership
>     discusses this
>     >    issue on <members-discuss at ripe.net
>     <mailto:members-discuss at ripe.net>>, keeping the discussion focused on
>     >    whether or not the "one LIR-one fee" model is the best model
>     for RIPE
>     >    NCC charging schemes and, if not, what the alternative should be.
>
>     Hi,
>
>     The idea of a per LIR fee only seems to be (in principle) a good
>     idea and one that I believe that should be retained by RIPE.
>
>     However, there are a number of reasons to move to move to a system
>     where 80% (a number plucked from the air) of the costs are made up
>     from *all* members and the remainder made up based on the impact
>     of individual members on the operational costs maintaining RIPE.
>
>     How you calculate these costs would of course depend on a number
>     of different factors and I can see different members proposing
>     things to their own benefit (and therefore the detriment of
>     others) without reference to a single “goal”.
>
>     I therefore propose that the remaining costs apportions are
>     focused on two separate goals “accuracy of the database” and
>     “conservation of scarce resource” if a proposal does not fit
>     within *both* of these goals then it should be rejected as being
>     not in the interest of the wider community.
>
>     If we, as a community, cannot achieve changes that meet both these
>     goals then I suggest we stay with the status quo.
>
>     Thx
>
>     J
>     --
>
>     James Blessing
>     CTO
>
>     M: +44(0)7989 039 476 <tel:%2B44%280%297989%20039%20476>
>     E: james.blessing at keycom.co.uk <mailto:james.blessing at keycom.co.uk>
>
>
>
>
>
>     ________________________________
>
>
>     Email Disclaimer:
>     This email transmission is intended for the named addressee(s)
>     only. Its contents are private and confidential and should not be
>     read, copied or disclosed by any other person. If the reader of
>     this message is not the intended recipient, or an employee or
>     agent responsible for delivering the message to the intended
>     recipient, you are hereby notified that any dissemination,
>     distribution or copying of this communication is strictly
>     prohibited. If you have received this communication in error,
>     please delete the message and any copies of it and telephone the
>     sender or email them by return.
>
>     Although Relish Networks plc believes that this message and any
>     attachments are free of any viruses or other defects which may
>     affect a computer, it is the responsibility of the recipient to
>     ensure that it is free of viruses and other defects. Relish
>     Networks plc does not accept any responsibility for any loss or
>     damage arising in any way from its receipt or use.
>
>     This email disclaimer is for all Relish Networks plc companies
>     (Company registration number 03921568) whose registered office is
>     at 20-22 Bedford Row, London, WC1R 4JS.
>
>     Please consider the Environment before printing this email.
>     ----
>     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/
>     <https://lirportal.ripe.net/general/>
>
>     Click on "Edit my LIR details", under "Subscribed Mailing Lists".
>     From here, you can add or remove addresses.
>
>
>     ----
>     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/
>     <https://lirportal.ripe.net/general/>
>
>     Click on "Edit my LIR details", under "Subscribed Mailing Lists".
>     From here, you can add or remove addresses.
>     ----
>     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/
>     <https://lirportal.ripe.net/general/>
>
>     Click on "Edit my LIR details", under "Subscribed Mailing Lists".
>     From here, you can add or remove addresses.
>
>
>
>
> -- 
> 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/
>
> Click on "Edit my LIR details", under "Subscribed Mailing Lists". From here, you can add or remove addresses.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20160914/64eb3d4a/attachment.html>