[members-discuss] A summary for Proposal for New RIPENCC Charging Scheme Model

Vladidlav et al.,

Am 15.07.2012 um 13:51 schrieb <poty at iiat.ru>:

> Hello all,
>  
> I think the members forgot several things about RIPE NCC, which has been pointed out in the Charging Scheme Task Force Report (it seems nobody read it):

I didn't, could you please point me to it?

>  
> 1. IP addresses is not goods. Nobody has transfered the rights to sell IPs to any RIR and nobody is able to do this.

I don't understand why charging on resources (e.g. IP addresses) is always linked to selling them in this discussion. RIPE is not selling IP addresses, RIPE is providing registry services. These services are charged per unit, e.g addresses. 

This view also invalidates the tax issues raised on the list several times. As well as the argument that taxes have to be paid on profit and RIPE should be non-profit.

> 2. From the point 1-> RIPE NCC earn money only for services.

No conflict.

> 3. Taxation of services could be rather difficult, as soon as the expenses is not really easily confirmed. In case of reselling (IPs) RIPE NCC will have to pay taxes for the "goods" (IPs) which the RIR "owns".

See above, RIPE is not sellig addresses, RIPE is charging service fees measured in underlying unit.

> 4. IPs are for the Internet, not for the companies. Nobody prevents any company to develop to any size (in IPs count), so thee is not any monopoly on them.

Yep.

> 5. There are many other resources (ASN, PI, reverse DNS...) which RIRs give. It's not possible to name one of them as main, the others - as not important.

a) It is possible to name one of them as main. This is a community definition process. PI is just addresses, so no special case. Reverse DNS is directly related to addresses, so covered by  address registration fees.

b) ASN registration fees should be definex as well.

> 6. RIPE NCC exist many years. There are many historical principles of distribution of IPs. Some of them are "legacy space", "minimal size", "2-year planning"... Many honest companies will be trapped with such big changes in the policy (for example, when our LIR got our first block the "minimal size" was /19, we use about 50% in assignments from the block now). Most tough question is the legacy space which is very unstructured and companies used the blocks not paying anything for them. So the counting of RIPE NCC IPs is not very accurate.

Sticking to history kills innovation and evolution. "Already done this way" is not a valid argument. If someone doesn't utilize its /19 completely, we should define procedures to return unused space (and motivate it by saving registration fees). I never understood the "minimum allication size" principle anyway. Along that line, pre-RIPE space should be counted as well - or revoked.

What I also don't get: why do we all implicitly agree to the amount of money RIPE requires/spents per year? This is what actually causes our fees. We should limit that and split NCC services into basic community services (e.g. registration services, root DNS) which should be covered by basic fees (flat per member or resource-depending) and professional services which should be covered by seperate fees being paid by those members that really use these services. 

One example: I don't get why we as a community fund R&D activity and staff of RIPE. I just want to register resources.

Regrads
Sebastian

>  
> There are several other reasons covered in the abovementioned report. I'm surprised that in spite of Leader Telecom representative took part in the TF, in the list there are thoughts like the company speaker has not read the document.
>  
> Regards,
> Vladidlav Potapov
> ru.iiat
> ----
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.ripe.net/ripe/mail/archives/members-discuss/attachments/20120715/bba2c9b8/attachment.html>