Date: Mon, 18 Apr 2005 16:14:01 -0700
From: Steve Sobol <sjsobol@JustThe.net>
To: North American Networking and Offtopic Gripes List <nanog@nanog.org>
Subject: Re: Verizon Offering Naked DSL in Northeast...Andy Johnson wrote:
> My speculation is that their billing/accounting system is based on a
> POTs number, and since these customers will not need one, they will have
> administrative errors managing accounts.Yeahbut.
SBC was happy to assign me something that looks like a phone number, but
wasn't, so I could make monthly payments on a Yellow Pages ad a few years ago.
I was in area code 216, and the account number was 216 R01 XXX YYYY (I forget
what the rest of it was).So I'm not buying that argument.
"Speaking from experience" with Ameritech (pre-SBC, that is) in Illinois,
*before* any form of "shared-line" DSL was available, the ILEC required a
phone number _at_the_service_location_ -- for reasons of insuring that the
DSL line was delivered to the "right place". (I don't know what they did
if the phone belonged to a CLEC; I _do_ know that "no land-line service"
caused all sorts of commotion.)
There _is_ a reason for that -- particularly in larger multi-family buildings,
there may be _more_than_one_ "service entrance" for that building. With
different parts of the building reachable only from a given service entrance
point. Thus, a need to ensure that the DSL is provisioned on the "right
cable", going to the correct service entrance point.
A "phone number" at the premises is something that the end-user _can_
reasonably be expected to know, and *does* "uniuqely identify" the path
for service to reach that premises, *AND* can be reliably parsed by a
computer.
A 'street address' is considerably less reliable -- all sorts of inconsistant
formats are used, user input may not match the structure in the database,
etc., etc. Then you have the situation where a building may have multiple
street addresses (e.g. a corner lot, and separate entrances), and the
address for the 'service entrance' point is *not* the same as the service
delivery address.
There's a whole nother layer of database to rummage through, when there is
no _existing_ service to a given location. One that is *not* -- at least
anywhere near as easily -- amenable to automated 'validation' look-ups.
It can be 'worked around', but it takes _manpower_ to do it. "people time"
is _expensive_, vs machine time.
I had an extended go-around on this with a DSL provider and the ILEC when I
ordered DSL for a company employee who was using only a cell-phone -- no land-
line service at all. The DSL provider computer wouldn't accept the order
without a phone number -- so we gave it the landlord's number (the other
side of the 2-flat). Then the ILEC computer wouldn't accept the order,
because it _knew_ that there was no phone in service at that address. As I
recall, this got escalated up the food chain, until a Sr. VP was talking to a
Sr. VP, whereupon it _finally_ went through. The installers that came out
(one from the ILEC to 'tag'/test the pair, and then the DSP provider guy to
do the actual equipment hook-up) both remarked that they'd *never* seen an
order like that one -- the 'premises phone number' read "000 000-0000". <grin>
I suspect that the 'technical difficulties' that Verizon ran into, in
implementation had to do with difficulties in _automating_ "address-based"
queries into the physical plant database.