[address-policy-wg] concept document: IPv6 PA/PI unification
- Previous message (by thread): [address-policy-wg] concept document: IPv6 PA/PI unification
- Next message (by thread): [address-policy-wg] concept document: IPv6 PA/PI unification
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Martin Millnert
millnert at gmail.com
Sat Oct 29 16:56:40 CEST 2011
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
- Previous message (by thread): [address-policy-wg] concept document: IPv6 PA/PI unification
- Next message (by thread): [address-policy-wg] concept document: IPv6 PA/PI unification
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]