Hi Geert, thanks for taking the time, you and Sander, to get this discussion started. I will dive into just one of them with some feedback. :) On Fri, 2011-10-28 at 19:16 +0200, Gert Doering wrote:
* yearly recurring cost "per block of numbers", independent of size(!), reflecting the cost of handling the address space request, documentation, RIPE database, etc., which increase if you need "many blocks"
This was an interesting suggestion. Going straight for the details of one point, I wonder, what's the most fair way to reflect the handling cost of an address space request? A /24 telco request for a larger national / european / pan-european access network takes (on average) a much higher toll on IPRAs) than say, a (good) /48 single site allocation. Similarily, I'm not convinced that a /24 with a couple thousand more-specific objects of various kind in the database, should (or should not) have a higher "RIPE database maintenance cost share" than a single /48 with one of each. That's only the database maintenance however. So I guess I disagree with your conclusion from the arguments you iterated over. Out-of-the-box counter-proposal: IPRA interacting work (including address space requests) == [IPRA hour fee] * [IPRA-time spent on application], Infrastructure cost sharing (yearly recurring cost) == [RIPE NCC specific registry / IPRA related costs] ----------------------------------------- number of LIRs at billing year end (*) registry / IPRA related costs, for example: * DB upkeep, org. * overhead for strictly registry-related org functions, *) number of LIRs at billing year end. (LIRs paying quarterly could pay Y1Q1, Y1Q2, Y1Q3, Y1Q4 by end-Y1 projections done quarterly, for a final adjustment of Y1 Y2Q1. mmmm details) This obviously does not take into account how to share RIPE NCC's costs of all its non-IP registry related undertakings. This is on purpose. Cheers, Martin