In the referenced message, Craig A. Huegen said:
On Sat, Feb 10, 2001 at 06:53:41AM -0800, Randy Bush wrote: ==> ==>>> Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if ==>>> no one else IANA) and apply for multiple appropriately sized CIDR blocks ==>>> under the current registry allocation guidelines. ==>> While I fully agree with this approach to deal with the issues mentioned, ==>> it will only exhaust the new address space more quickly. Why should we ==>> give up on 128/2? ==> ==>because when the registries have different allocation policies in 128/2, ==>the isps will follow. just as we did in old A space.
That doesn't address the point -- the point is that these ISP's are forcing the exchange of these blocks for new, previously unallocated space, and leaving holes in the old 128/2 space. These ISP's are massively contributing to the depletion of immediately available address space.
Returning a /16 which the organization is not entirely using for a smaller block seems to be anything other than depletion. Perhaps I've misread Dani's original message, but it appeared that the /16 is not being completely used.
Why not adopt a reasonable policy to accept up to /20's or up to /19's in the old B space so that organizations who already have these blocks can use them?
Most people who filter feel that filtering on registry boundaries is reasonable. There are people who feel that their version of reasonable is more reasonable. What makes /32 less reasonable than /20? If one filters on registry boundaries, the only time you don't have access to an entity is when they are not announcing the allocation they have been assigned.
/cah