Eliot Lear wrote:
Nigel,
V3 of the policy was explicitly issued to address the main ETNO concern, that is the "need" requirement. If you carefully look at V3 you will see that the RIPE NCC now has to apply exactly the same checking and approval process that it does for a "normal" allocation.
This brings 2007-08 closer to ARIN's 2008-2, and in fact "improves" on it by not prohibiting disaggregation. While you very reasonably point out that the routing table could explode under such circumstances, having such a prohibition along with needs justification can lead to perverse impacts where holders of large blocks are only able to unload them to large users like ISPs.
Are there additional mechanisms that could be put into play to limit that explosion? For instance, could one cap the deaggregation rate per aggregated block to some number per anum? What work has been done in this area. If you look closely at 2007-08 you will see that the minimum size of block that can be transferred is the minimal size of block that RIPE NCC can currently allocate. This allows the deaggregation of larger blocks, but also puts a cap on the amount of deaggregation that can occur.
Nigel