[arin-ppml] Clarify /29 assignment identification requirement

William Herrin bill at herrin.us
Sat May 5 08:47:45 EDT 2012


On 5/5/12, John Curran <jcurran at arin.net> wrote:
> On May 5, 2012, at 12:22 AM, William Herrin wrote:
>> In fact, unless I'm prepared to pick up the phone and start polling
>> the folks on that customer list, I have just as much confidence that
>> you're telling the truth this way as I do from demanding a customer
>> list.
>
> With all due respect Bill, it is not quite as easy to produce a
> set of customer reassignment data as you would think, and there
> are ways of spot checking individual entries short of directly
> contacting them.

Hi John,

I never claimed it was easy but I doubt it's particularly harder than
I think. The keys are: expectations, consistency and error.

The expectations are for a healthy mix of assignments: dynamic pools
and static assignments of various sizes with the larger static
assignments properly swipped. Staking a claim of 90% /32's is foolish
unless true. Might even be foolish if true because it invites
scrutiny. Submit a claim that "looks" right and you'll get only a few
cursory questions.

Consistency is the hard part of any lie. I won't belabor it or the
methods for achieving it.

Error is important. A surprisingly large amount of information in an
ISP's billing database is missing or wrong and obviously so. The
smaller the ISP, the more true. A faker really has to have seen enough
such databases to understand the kinds of error that are present and
introduce similar error into his faked data. Too-perfect data is a red
flag.

Back when I was in the business we acquired a bunch of smaller ISPs
with a few hundred to a thousand customers each. One of them was
missing complete address data for half the customers. He had most of
them on annual plans (with a believable mix of end dates) and said a
number of them dropped by his shop and paid in person. Ended up in
court because the contract called for us to pay him for essentially
the opportunity to bring these customers into our system yet for many
he didn't provide enough information to reach out and contact them.
Meanwhile we carried these customers and continued service for them
because even if we couldn't get in touch with them there was a decent
chance they'd get in touch with us when the annual contract came due.
No more expensive really than acquiring a customer through
advertising.

Point is, you expect goofy crap like that to be reflected in the
customer data. If it isn't there then it may be faked. In my opinion,
though, you can get the same feel from the de-identified data. It's a
little more effort, but only a little.

Heck, you can infer from just the list of plan durations and end
dates. If there are annual subscriptions but no cluster around
Christmas and no late-summer dip then something is odd. And you don't
need the slightest bit of PII to check.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



More information about the ARIN-PPML mailing list