Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Frank Coluccio Technology Forum - ASAP -- Ignore unavailable to you. Want to Upgrade?

To: Frank A. Coluccio who wrote (1703)	5/31/2000 10:28:00 AM
From: ftth	Read Replies (1) \| Respond to of 1782

re>>...seldom implemented, to the best of my knowledge, exactly the way it is spelled out by the consortium... That answers one of the questions I had. So in essence it's more of a politically correct public face to appear aligned strategically, when in fact there is little cohesiveness. Also, because of its age, I presume there are no provisions for "competitive access" designed in. It would have to be a retro-fit band-aid like it is to all existing networks, true? I suppose the argument would be "it's ATM, it can accommodate anything, therefore there is no issue." Would you agree that all networks going forward must include carefully thought out architectural constructs to include multiple service provider add/drop capability? In a sense this leads into your next comment: "...networks that were conceived by the telco regime...were ONLY designed to target residences...and were never, however, conceived as full service platforms to "all" potential end users" This would seem to add value to the "classful lambda" approach where wavelength partitioning is by service class. In many (maybe most?) cases, this is synonymous with service "provider", and the classes/providers could be added/dropped at will, and grouped into all permutations of class bundles to any given segments of the network. This would necessarily mean that a) we have lambdas out the wahzoo, and b) we don't care how efficiently the bandwidth within a given lambda is used. So, "lambdas" become the resource, and bandwidth is just a by-product and sort of loses its significance. It's hard to imagine--assuming we could have hundreds of lambdas to end users and thousands at higher tiers--lambda exhaust, but I'm sure it would be made an issue "by design."

To: Frank A. Coluccio who wrote (1703)	6/1/2000 10:48:00 AM
From: KW Wingman	Read Replies (6) \| Respond to of 1782

You wrote: <I think that SilkRoad Inc. deserves some more coverage than it's currently getting, maybe in its own space. ahhaha, what do you say we co-host a thread on it, I can be the good guy, and you can be the bad guy. What say? [grin]> As you know, Silkroad is dead after taking a lot of money from investors. Considering these peoples' losses, do you now have any regrets or shame for your part in cohosting and thus promoting the Silkroad thread and company? Did you ever reach the conclusion that Silkroad was a scam company. siliconinvestor.com