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.