Verizon Offering Naked DSL in Northeast...

Tue Apr 19 00:23:50 UTC 2005

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