[arin-ppml] Clarify /29 assignment identification requirement

[William Herrin]

On 5/5/12, David Krumme <david at airbits.com> wrote:
> I like your ideas which are quite clever.  However, my situation doesn't
> match your expectations.  Maybe I am unique...?

Hi David,

Maybe unique. Or just moving through an early phase where certain
kinds of expedience still make sense.


>> The expectations are for a healthy mix of assignments: dynamic pools
>> and static assignments of various sizes with the larger static
>> assignments properly swipped.
>
> All my customers are assigned individual /32's.  I don't know why I would
> be using dynamic pools for customers who are permanently connected and who
> tend to use the Internet every day.

Doesn't scale up and its a nuisance to keep track of. When you have
10,000 /32's and redundant paths in your network, you'll find that
some of your edge equipment has trouble dealing with the routes.
Dynamic pools aggregate better and with the right software you can
give the assignments some stickiness so the customer tends not to get
a different address unless he moves to a different pool. Assignment
and revocation via dynamic pools also automates easier than static
/32's.


>> 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....Too-perfect data is a red flag.
>
> Our billing database is almost perfectly error-free.  We audit it once a
> month because it's less work to keep it straight than to deal with the
> fallout from billing errors.

I'll bet you anything you want it's not as perfect as you think.
Somewhere in there Bob's niece Clara has free service as a courtesy to
the very valuable Bob. It wasn't deleted when Bob left you for
Verizon.

Also, your typos and goofs will have a different character than the
ones I'd get from a bulk mailing list. Mr. Ben Dover and Ms. Richard
Johnson are probably not to be found. Ralhp Jone likely is.


>> 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.
>
> We don't have any plan durations or end dates or annual subscriptions.

At some point you send out a bill or auto-debit a credit card. That's
the end date. Then service begins again.


> So I'm just saying that your techniques are based on certain assumptions
> about how an ISP is run, assumptions that do not characterize my
> situation.

One size doesn't fit all. The PII method works for you. I heard you
loud and clear the first time. I just can't do anything about it
unless John finds a way around his pronouncement that anything between
the extremes of using PII whenever and not using PII at all is out of
bounds at the policy level. He has us boxed in.

I hope you'll forgive me but if I'm forced to choose between you
playing show and tell with the routers and a hospital either
reorganizing its network or coughing up patient ids, I'll choose to
inconvenience you.

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