Since people seem interested in personal stories and
anecdotes about the struggle for IP allocations, I'll
leap in headfirst and mention our struggles from back
in February of this year...
(I'm leaving Chris and Kim's remarks included at the end
of this, as further emphasis, and as a restating of what
I found out in attending the Feb. NANOG meeting--Kim
really is a real person, not a huge, pale-skinned vampire
attempting to suck the life out of quivering little ISP's. 
We went through the same problems at the beginning of the
year; our growth rate was ramping up exponentially, our
customer base was doubling twice as fast as we had
expected, we were running low on address space in our
existing blocks, and we begged for more. We had been
lax in the recent use of SWIP entries for many of our
blocks, because we issue /32's for ISDN terminal
adapters, and figured "we don't need to mark those,
because there's no way to indicate ownership of the
/24 properly."
When our requests were turned down time and time again,
we blew up--I mailed Mark, Kim, and anyone else I could
think of, I called, I moaned, I wept, and finally I
bit the bullet, and downloaded a very early, barely
supported beta version of rwhois, and wept and cried
and pulled my hair out some more. It seemed ridiculous
to try to put all the data in, but as it turned out,
three weeks of putting our records straight, looking
information up, and then finally sending a long list
of referral records to the NIC, pointing to our newly
installed rwhois server paid off, they agreed we had
met the requirements, and allocated our next block
to us.
(I'm skipping the intervening pain and suffering I
went through in getting 6000+ records into the early
version of rwhois--those of you on the rwhois mailing
list can read through the archives and relive the
experience yourself. At the Feb. NANOG, I met not
only Kim herself, sans fangs, but also Mark, who I
gave several pieces of my mind to, for the state
and condition of the rwhois code. I will congratulate
him, and the rest of his team, on getting the code
into a far more usable state, but it's still not
yet to the point of being trivial to implement
at an ISP. At least they're listening, and working
on improving it now. Anyhow, in meeting Kim
down in San Diego, I realized she's actually got
one of those jobs that must make you hate to
answer the phone--you know what you're doing is
necessary, but it doesn't make it any easier to
face the poor network engineers who are ready
to blow a gasket at the beaurocracy being thrust
upon them. 
Let's not drag her through the
muck too harshly about this--after all, we're
the ones staying locked into the limited IPv4
space like this. 'nuff said, back to the story--)
We found out in the process that we had multiple
blocks that we thought were allocated that no
longer had customer records associated with them,
we had blocks that were doubly allocated (?!), and
we had FAR too many blocks that we just didn't have
customer info on altogether. It actually helped
our accouting group immensely having to comb through
all of our address space, and account for as much
of it as possible, because it forced us to confront
all the random "back door deals" and legacy allocations
that nobody had every really bothered to keep track of
because "you could always just get more IP blocks."
We also sent copies of the Hubbard draft to all
corporate customers that were currently in the
pipe awaiting /24's, and explained that they would
instead be given /28's for fractional T1 frame relay
service, /27's for full T1's, and /24's for T3
service, by default, unless justification for
larger allocation was received in writing, with a
complete network diagram showing current utilization
and future growth. We highlighted and underscored
the section that indicated that "administrative ease"
was NOT considered sufficient reason for a larger
allocation, and we've held to that restriction
very well since then. Yes, customers have grumbled.
Yes, some customers left, or cancelled pending
orders when they found out the restrictions. Our
only hope is that as more and more ISP's go back
for new allocations, and find out that these rules
apply to everyone, the unruly companies that are
shopping around for and ISP that will hand them
IP blocks carte blanche will realize that there
ain't no such thing as a free IP block--if everyone
follows the rules, customers will fall into line
as well.
We have also taken the step of charging a nominal
fee for additional IP blocks, to prevent companies
from simply fabricating supporting documentation.
The one lone person in a garage tends to be much
less casual about requesting larger and larger
blocks when the find out that each additional
block comes with a recurring monthly fee. It
also lets us keep track of usage much more
closely, because if a customer stops paying
the monthly fee for an IP block, we give them
notice, in the usual way, and eventually we
KNOW we can reclaim the block. Previously,
it was much harder to tell if a customer was
still using a block, albeit infrequently, or
had totally forgotten they requested it.
Anyhow, enough rambling, this is turning out to
be a far longer missive than intended, and the
wet towel is getting REALLY cold, so I'll wrap
up by simply saying "This is life in IPv4 space--get
used to it, or move on to IPv6." I don't mean
that in a harsh way, and I don't intend it as a
snub to anyone. We have a scarce resource that
needs to be rationed. We have an alternative
resource that is much less scarce, and needs far
less rationing. If you wish to continue working
with the scarce resource, you need to accept that
rationing is part and parcel of utilizing that
scarce resource, and as such, documenting your
usage of the resource has a much higher priority.
The only thing I WOULD reccomend is having the NIC
sign an NDA for your company. This way, if information
provided to you that you pass on to the InterNIC leaks
out, or is used in a mass mailing, you DO then have
a leg to stand on in taking the NIC to task for
releasing confidential documentation. But that's
standard business practice, so it hardly bears
repeating.
Again, 'nuff said, just wanted to throw in our
personal testimony into the grist mill, and say
"we were there, we went through the suffering,
it CAN be conquered, and it will probably help
your organizational record keeping in the process.
Yes, it's painful, but so is juggling MED's at
4 am."
We're not in a hedonistic business, and
this isn't the Elysian Fields. Once you've got
the software and processes in place, changing
entries, and adding new ones isn't NEARLY as
bad as having 3 /24's left, and taking your
FIRST look at rwhois. I wish you the best
of luck in getting everything straight with
them, but as far as we've seen, don't expect
to get around the requirements--they're here
to stay, as long as IPv4 is around.
Thanks for putting up with my ramblings,
Matt Petach
Network Engineer