Firstly, let me state that I am not strongly attached to any charging mechanism in particular... as long as whoever it is that ends up running the thing doesn't lose money on the deal, it's fine by me. However that is priced out is basically irrelevant to the basic goal here. It is basically correct that giving someone a /18 isn't going to be much more work than giving them a /19 or a /20. It takes a bit longer to forward all the PTR records correctly, but that will probably be a very small part of the total effort. The primary work involved in any allocation is going to be working with the provider long enough that the allocation is "correct" in terms of meeting the enough space over the specified time requirement without wasting space. That will scale somewhat with size of block, and a whole lot with how new the provider is... established ISPs with years of growth they can document are easy to allocate, you just do the math. Some new provider which hasn't got that length of experience you need to look at more carefully, lest you give them a block they won't use in years (or ever, if they fold). But I don't want to keep them from getting a right sized block... I just am pointing out that they will have to do porportionally more legwork than someone with more established basis for their growth claims. I don't know for sure what the "best" way of allocating the costs among the users would be. It is my suspicion that doing so based on the size of the allocation is the most fair way to balance things short of charging on a per-hour basis during the allocation setups. As most people like pre-established fee structures, I think it's better off to set something in stone. I am willing to listen to alternatives to the proposed mechanism though. I think this should be understood to be a distinct issue not directly related to the rest of the proposal... if it's a good idea, we can talk some about the charging mechanism (probably somewhere else rather than these lists). If it is technically a bad idea, the charging mechanism is irrelevant. -george