[address-policy-wg] concept document: IPv6 PA/PI unification

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