-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Marcel, I have a "bad feeling" about the new charing scheme. 1) as Daniel already wrote and you also mentioned: it looks like nearly ever LIR will have to pay more for the same resources. 2) if I understood correctly "All contracts for any RIPE NCC products or services will be between the RIPE NCC and a member. This means that Direct Assignment Users and other separate service contract holders, such as DNSMON subscribers, must be a RIPE NCC member" the current "sponsoring" of pi-space by a LIR is not possible any more. So we lose min. 10 customers having this service. 3) if 2) is right, the RIPE will have to get more stuff for all the small /24 pi-space members For me it's just "making money"; but the RIPE has enough, so why?! It's nice that they say it's making everything easier, but I guess it's making everything more complex and for all the LIR... will the RIPE pay for the customers I lost when they become members? The RIPE should fix open topics like asused for ipv6 first and try to save money before they start asking for more. Br, Patrick Am 02.08.2011 02:11, schrieb Marcel Edler (Optimate-Server.de):
Hello member,
my LIR has 2x/18, 1x/19, 1x/17 PA-Allocation. When I look right my membership category will be size L. I have to pay 5000 Euro a year, because I have one /19 over /16. I think the price step from category M to category L is to big. 2500Eur -> 5000Eur You should add a category between M and L. It should have this requirements: IPv4:
/16, <=/14 price should be 3500 Euro every year
Its not fair, that I have to pay 5000 Euro, instead 2500 Euro, only I have one /19 to much to met requirements for category M!
-- Regards, Marcel Edler
- -- ConnectingBytes GmbH - "www.kambach.net" | In der Steele 35, 40599 Düsseldorf, Germany | Telefon: 0800 / 900 2580 - 1, Fax: 0800 / 900 2580 - 2 | Email: pkambach@kambach.net | Web: http://www.kambach.net | | Geschäftsführer: Patrick Kambach | Amtsgericht Düsseldorf, HRB 60009 | Ust-IdNr.: DE815028832, Steuernummer: 106/5736/0037 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk43s7MACgkQCIR+kawbQF1hHgCfTMqwCA5P3rpQOkkStnbEZZHa CeIAoPbPr+vqwp2r/cDPBNFQgS2dOrze =yaI4 -----END PGP SIGNATURE-----