Verizon Offering Naked DSL in Northeast...

Date: Mon, 18 Apr 2005 16:14:01 -0700
From: Steve Sobol <>
To: North American Networking and Offtopic Gripes List <>
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.


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. :wink:

"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

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.