Buzz roundtable: The entire transcript, 09/27/99

Buzz: The columnists speak

The entire transcript

Network World Fusion, 09/27/99

Separating hype from the reality, in addition to being the central idea behind the Buzz issue, is the bread and butter for Network World columnists, many of whom work full-time as analysts and consultants. We corralled four of our regular columnists to give us their opinions on many of the issues tackled in this year's Buzz issue.

As can be expected, they don't always agree with each other or with the conclusions reached in some of the stories in our Buzz issue. But, as always, they do serve as another source of informed opinion that you can use to reach your own conclusions on topics ranging from Application Service Providers to XML.

Participating in the roundtable were: Scott Bradner, a consultant with Harvard University's University Information Systems in Cambridge, Mass.; Dave Kearns, a former network administrator who is now a freelance writer and consultant in Austin, Texas; James Kobielus, an Alexandria, Va.-based analyst with The Burton Group, an IT advisory service that provides in-depth technology analysis for network planners; and Thomas Nolle, president of CIMI Corp., a technology assessment firm in Voorhees, N.J.

The roundtable was moderated by Paul Desmond, the former features editor of Network World who is now vice president of King Content, a strategic publishing company focusing on high technology.

XML is being incorporated into everything from Web browsers to network management applications to directories. It is being called the lingua franca that will enable data to be easily read and understood by various computer systems and applications. How important do you expect XML will be to enterprise users – and when?
Bradner: XML will be an interesting exercise in frustration. That fact that you can write in the same language doesn't mean you're writing the same thing in the same format, or with the same meaning. Unless there's much more agreement on the meaning of the terms and the format and the conceptual background, it's mostly going to be frustrating.

Kobielus: One of the things we're finding is a need to educate the industry as to what XML is and what it isn't. It isn't a lot of things. It isn't a protocol or a set of APIs. Rather, it's simply a very adaptable, handy markup syntax for defining documents, objects and formats by which the network can expose the structure and functionality of various resources.

XML is in many ways a great success in terms of being adapted for many different application domains. But XML, like Java, will not absorb the sum total of all standards that are out there. It's just yet another set of standards that are very handy and are filling a particular niche.

Nolle: XML offers something that Java has not offered and none of the other strategies that we've talked about have offered and that is, because XML does provide a mechanism for defining more than just Web pages – you can define objects and databases – XML lets us define behaviors of systems. Not in the same sense as a procedural language like Java, but in a sense that allows cooperative processes to share information with one another. And an awful lot of what we're talking about in new generation network services, both in the voice space and the data space, really comes about as a result of a relationship among cooperative processes inside the network. A call-forwarding function, for example, is a cooperative process. We can use XML to define not only how call-forwarding works for both the originating or forwarding switch and the final destination switch, we can also use XML to define the syntax or message that's used to exchange calls between the devices. Because XML is extensible, it could relieve us of some of the burdens that SS7 [Signaling System 7] and some of the other protocols have placed on us. Protocols are usually used to arbitrate information between cooperative systems but since they're not readily extensible, protocols often become the big brake on this.

Realistically, XML is more likely to affect users in the way that ATM has, which is to say behind the scenes, rather than something that the user will himself adopt. I wouldn't be terribly surprised if the average user, three or four years from now, was still not doing anything with his own Web development in XML. But I would be very surprised if within the next three years or so users weren't consuming XML indirectly, in the form of services or functions that are arbitrated through XML.

Kobielus: Right. XML is enabling a more loosely coupled application architecture. It's really doing an end-run on the likes of DCOM and CORBA. In other words, any two systems that can exchange XML objects can conceivably interoperate whether or not they're under the same operating system, or even whether they use the same object protocols. As long as they can generate, receive, process and parse an XML document, and understand the basic semantics that are encoded therein, you have the means for loose couplings of different systems. So voice and data systems can work together without being, for example, both Windows NT-based systems or being both Java or CORBA-based applications.

Bradner: All of you are pointing out the very important strength and the very important weakness of XML. It is not a defined thing. It is an extensibility platform. That means the likelihood of getting incompatible understandings of how to describe a call forwarding sequence, for example, is extremely high. The probability of that is close to 100% in XML and it's going to take a long time to work out the subsets for individual applications that make sense.

Nolle: I agree with that. Look at HTML, which is the only version of a markup language that people understand broadly. HTML has not only a predefined syntax, a non-extensible syntax, but it also has sort of a virtual machine associated with it. What you'd need to have XML drive the behavior of a cooperative system is define a virtual machine that represented the elements of that cooperative system. Otherwise your XML namespace is going to name variables which everyone agrees on but which no one can manipulate because they don't mean anything; there's no context to provide the meaning.

Let's move on to policy-based networking. This is ability to set corporate policies for network and application access and for bandwidth privileges, to determine who or what applications get priority. There have been lots of issues raised as to whether implementing all these policies is worth the trouble, especially in the LAN where bandwidth is relatively cheap, or if it's even feasible in a multivendor network. So what's your take on policy-based networking? Is this an idea users should be trying to pursue?
Kobielus: What policy-based networking needs is very strong meta-directory capabilities across different environments. You need to have a master meta-directory that incorporates the NOS directory, the e-mail directory and all the other directories in use in an organization.

In terms of bringing the network transport QOS environment into it, you need to have connections into your backbone. Let's say you're using Cisco routers, you need to have a directory that encompasses all those router objects and links. And that directory needs to be part of the meta-directory environment. Whatever policy tools you have then need to tie in to those low-level physical internetworking objects. They also need to tie into the directories that control access to your corporate applications and databases and whatnot.

That's quite an effort, integrating all those systems. But policy-based networking is a laudable goal. It's another way of talking about permissions management and application security. But in terms of a general purpose policy networking infrastructure, it depends first and foremost on meta-directories and secondly it depends on public key infrastructure technologies. Neither of which – metadirectories or PKI –is widely deployed in enterprises yet. So these are big things to bite off and chew.

Nolle: Before you get to the implementation issues, you've got to address the value issue.That's where the major problem associated with policy based networking is. The problem is that if we make a directory or a policy networking environment relatively confined, then the benefit of the environment is so small that the expense of linking this with the equipment to bring about the changes that the directory is supposed to bring about really aren't justified.

On the other hand, if we expand the scope of policy based networking, for example into the QOS space, to open up the value proposition, we expose ourselves to a lot of complexity in terms of maintaining the policies. And we also expose ourselves to a lot of complexity with regard to the multivendor interpretation of directory contents. It seems to me like we're caught here in policy management. We can either dumb it down to the point where we can understand it, and then it's useless; or we can kind of ramp it up to the point where it's useful in which case we can't understand it. In neither case is the user very likely to do anything with it.

Bradner: The IETF has actually been working on policy based management and the policy schema in the quality of service and security areas for a while now and is certainly having trouble figuring out what exactly that means.

Kobielus: In policy based networking, one of the big hitches is the whole issue of certificates and how broad those certificates should be. Should you stick with standard x.509 certificates that simply identify a user or entity, or should you somehow also store attribute certificates that define various levels of access control, applying to particular users and entities. There are many people, including myself, who would argue that the best place to put dynamic information, such as access controls, is right in the directory where they're available to multiple applications. You don't want to have to revoke and reissue certificates if you can help it. When you're dealing with something as volatile as user permissions and privilege levels, that's an area where you would want to stick with just a basic identity certificate, put the permissions information in the directory and make that permissions information available generally to all applications.

Nolle: If we were to let the users listen to the last description here, which I agree with completely at a technical level, the interpretation of the average user is going to be that the cure of policy management is a lot worse than the disease is. I don't believe that a certificate gives any significantly better assurance of identity today, without the availability of smartcards, than passwords over a secure link.

Kearns: Let's not get caught up in the benefits or drawbacks of certificates. All we really need to specify here is an authentication method of some sort.

Bradner: I would agree.

Kearns: We've been talking about policy management in the security arena and the licensing arena for many years. It's not something new. It's just a new term that somebody invented when they tried to throw QOS in, which still really isn't defined very well. What we're talking about is extending the policy management and I have a feeling that, give it a year or two and we'll be down to calling it rules-based management where we apply rules to everybody's access to everything.

It sounds like there was some agreement that directories would play a key role here, and that's another topic I wanted to hit on. It seems like there are significant hurdles to overcome with respect to directories – the whole idea of integrating all your existing directories, internal politics over who controls what, just in general getting your directory house in order. What steps do you think users should be taking with respect to directories?
Kearns: You have to draw a line between the so-called meta-directories and what I like to call virtual directories. Meta-directories of the type Zoomit sells represent the master directory model. That's as opposed to the NetVision Synchronicity virtual directory model, where you use the directories you have, you simply connect them in some way to data that resides in other directories. In that case, there is no master model, there is no single point of control of the entire directory space. Whoever owns each directory continues to own it, you're just sharing information back and forth.

Nolle: That seems to be, to some degree, dodging the benefit along with dodging the issue. If independent ownership of directories is maintained, then even providing a technical mechanism to ensure the synchronization of the information content wouldn't necessarily provide any practical synchronization because the owners of the directories might not elect to operate that way. To a degree, if one assumes that we're going to move into some form of integrated directory environment, then at least part of the benefit is associated with the assumption that it's going to eliminate the inconsistencies among directories that tend to plague operations today.

Bradner [ON META-DIRECTORIES]: That would demand reengineering to a very large extent in many organizations, to an extent that I would find to be implausible.

Nolle: I agree with that. That really goes back to the higher level question of policy management and directory enabled networking and all of the other buzz words that are associated with these directory functions. We are confronted by the problem of either doing next to nothing and getting it by the current user mindset, or biting off a reasonable and justifiable chunk and colliding with so many existing implementations, political domains and other factors, that the implementation of it becomes implausible. So this is a technical remedy that's probably useful, but I don't know that we can really expect anything of it in the near term because the impact on the organization is too great.

Bradner: That's barking up the right tree. Having had to worry about some of this at Harvard, it's not something that I'm looking forward to getting too much further into.

Kearns: You have to decide which way you want to go. Do you want to change the culture of the organization and wipe out all those political differences…..

Bradner: ... You mean the ones that have taken 370 years to develop?

Kearns: Exactly. Or, do you want to find a way to work within that culture by allowing people to keep ownership of that data and yet still ensure that the data is replicated?

Bradner: I don't have any choice but the latter.

Kearns: Good. Then virtual directories are the way to go.

Let's shift gears again to integrated access services, meaning things like Sprint's ION and AT&T's INC, which enable you to pool various kinds of traffic over a single access line. They stop short of offering true integration because voice, frame relay and Internet traffic each goes its own way once it gets to the carrier's central office. Do you see much to get excited about when it comes to these services?

Bradner: If you believe that people want to have a phone jack on the side of their data modem so that their teenage daughter can use the telephone, sure. That certainly is the fundamental model that the telephone companies have. It's not the one that's proven successful for DSL, for example, in the data market.

Nolle: Integration, whether you're talking about access integration or transport integration, is really only an indirect user issue. Integrated access as in the case of ION, INC and [MCI WorldCom's] On-Net - all of those strategies are really directed by the service provider at achieving account control in a user environment. They're not anything that a user is particularly valuing, nor are most of the service provider planners naive enough to think they can make the user value it. The user doesn't care whether Tinkerbell carries his packets on little tiny silver wings.The only thing they care about is price and the service guarantees. The same thing is true with integrated transport. For us to sit back and say this is not a really converged network because it doesn't meet the following criteria, begs the question, why would the buyer care if it was a converged network? What's the intrinsic value of convergence to the user?

That isn't to say that integrated access isn't useful. Integrated access strategies like ION and INC and so forth offer one benefit to the buyer indirectly. By justifying the service providers' over-provisioning of access bandwidth, they allow the user to acquire a tactical service like a data service without the provisioning delays that would ordinarily be associated with running access lines.

So what's the upshot – are these integrated access services a good thing for users or not?

Bradner: They're irrelevant to users. Users are looking for price/performance and functionality. You can put that combination together with an integrated package, maybe you can change response time, that's great. Maybe you've changed the price, that's great. But if you do it with two separate wires or do it with one wire, what's the difference?

Nolle: I had specifically criticized all of these strategies in a column I did for Network World and the basis of my criticism was to say pretty much that, which was that either this is nothing more than a pricing play, in which case we don't need to understand its technology, we only need to understand its cost. Or it's aimed at providing more flexible data services, in which case it's incumbent on the carriers like Sprint, MCI and AT&T to give us some kind of an indication of what sort of tactical services are going to be available over this access bandwidth.

Bradner: None of them have done that and they give no indication of doing it. I'm certainly not going to hold my breath for Bell Atlantic to do it.

Kobielus: If integrated access services bring down the cost of provisioning and speed up the time to provision a new circuit or service for the customer, this is ultimately good for the customer. What it does in a very competitive environment like telecommunications is it brings down the general cost structure for providing these services. Let's say one carrier brings out an integrated access service and the service significantly reduces the carrier's cost structure. Then that carrier will pocket a fairly tidy profit initially but then as other carriers come along and duplicate this service, they're all going to theoretically experience significantly lower cost structures providing this service. Ultimately, with competition, that's going to bring the price to the customer down.

Bradner: You're making an assumption that I don't agree with. I do not assume that an integrated system, as provided by a Baby Bell, will show any significant cost savings.

Kobielus: It'll show cost savings to the customer when there's enough competition in a given market that carriers can compete and bring the price to the customer down.

Bradner: I don't see why the integration makes any difference to that.

Kobielus: You're denying that integration of circuits and services and equipment in the back-end network can bring down costs for the carrier?

Bradner: I don't believe carriers will integrate most of the equipment in the backbone network for a very long time to come, if ever.

That gets to one of the other issues I wanted to discuss, which is convergence. Obviously there's been a lot of buzz about that for some time now, the idea of supporting voice, data and video over a single IP network. What's your take on the whole status of the convergence movement?
Bradner: It's a religion thing.

Nolle: Convergence is crap.

Bradner: The same people who are telling you that IP is going to solve all your problems are the ones who told you three years ago that ATM was going to solve all your problems and ATM was going to get rid of IP. Now IP is going to get rid of everything. It makes just as much sense.

Nolle: Which is to say no sense.

Bradner: Which is to say no sense at all.

Nolle: The real question with the whole idea of convergence, to the extent that there was any utility to it all, is based on an assumption that in an age when optical networking is bringing about potential for massive declines in unit cost of transport bandwidth, we would nevertheless find it useful to save money by consolidating traffic. Now, it doesn't make any sense to me if bandwidth cost per unit is declining why the value of traffic consolidation is not similarly declining. Then what we would be saying is, if there was any cost associated with migrating to a converged infrastructure, that cost would probably be less and less justified as optical technology improved. And therefore convergence is a dumb idea.

Bradner: That's exactly right, but that won't stop many folks from continuing to talk about it.

Nolle: I agree. Reality has never been particularly useful to the industry. It certainly isn't any fun.

Bradner: A particular example which seems to be way off the wall is converting all of the cell phone industry to IP-based telephony. That seems to be really whacko.

Kobielus: Why is IP telephony or why is IP wireless networking whacko in your opinion?

Bradner: What does it gain you? It requires you to have a network that's significantly more complex and harder to run than the existing telephony network.

Nolle: And it displaces a huge amount of extant technology at the instrument level where the customer sees it and at the infrastructure level. And at the end of the day what you get in terms of service, if you're lucky, is only a little worse than you had already.

Bradner: I think you can get something that's the same or even better in many cases, but the point is you don't gain that much from it. I don't see any particular reason to believe convergence is going to be cheaper. I think it's probably going to be more expensive than quickly amortizing existing equipment. The voice world is hardly growing at all. Particularly if you take away fax and things like 800 calling, [many people now use the Web where they once made toll-free calls]((need to check that – I think that's what he meant.)), the voice market is relatively static and the infrastructure for it is already in place. If you pull some of that fax and 800 stuff off of the existing voice infrastructure, it can last for another 10 years with effectively no increases in investments. So why would you want to throw all that away and spend a lot of money on something else? If you go look at what Qwest and Level 3 are doing, they're actually putting in big phone switches.

Nolle: That's really the irony of the whole convergence debate. People look at convergence as though we had no extant investment in infrastructure. And no matter how you slice the technology and no matter what your technology religion is, buying something new is always more expensive than keeping the thing you've already got, assuming the thing you've already got is serviceable and is providing what the customer wants to get.

Kearns: That's not entirely true.You can always buy something new and save money if it's a good bit more efficient.

Bradner: A good bit more efficient.

Nolle: We've had a real lack of any demonstrable examples of that in public networking as far back as I can remember.

Kobielus: Consumer-based IP telephony seems to be efficient.

Bradner: It's efficient because it's cutting through regulatory crap, it's not efficient because it's a good way to provide the service.

Nolle: It's also very limited in terms of where it's applied. Consumer IP telephony is mostly used, as Scott says, for regulatory arbitrage in international calling.

Bradner: Or in students trying to talk to their friends.

Nolle: In all the surveys we've done and in all the the straw polls we've participated in at conferences, the business users and premium users who account for most of the revenue have always come back and said, basically, "We're not willing to pay the price of moving to an alternative telephony strategy in terms of quality and compatibility with our existing equipment because there's not enough money on the table to make it worth the effort."

All right. I think we've sufficiently beat up on convergence. How about VPNs, which we're defining as a secure path carved through an otherwise public network. What's your take on where VPNs stand today and where they're headed?
Bradner: VPNs for the most part, certainly big corporate VPNs, are a feel-good for the corporate IT manager who doesn't really want to use the Internet but is told they have to use the Internet somehow.

Kobielus: VPNs are very much an enabler for extranets, an extranet meaning a closed network environment for a specific group of trading partners to exchange information securely with each other. When you get into the e-commerce world, these closed environments are starting to break up. In the Internet e-commerce environment you want to have secure communications between yourself and any number of other partners that you can't foresee, due to the freewheeling nature of commerce. So the concept of VPNs, being closed commerce communities, just seems a little bit creaky, a little bit antiquated. You really want secure communications in a very public forum, without the need for a dedicated VPN, leased line kind of environment.

Bradner: You don't want to have to pre-guess who you want to talk to.

Nolle: VPNs make sense if you call a VPN something consistent, but it's clear that the customer, the service provider, the equipment vendor, the media and the analyst community have not converged on a single strategy. And as long as that's the case, as long as we can't even get the nomenclature right – and I think Scott you wrote a column about this at one point in time – then pretty obviously this concept isn't going to go anywhere.

Bradner: I did get a response back from that column, which was "How do spell VPN?" A dozen different ways. I got a response back saying, "He is absolutely wrong. We know exactly what a VPN is. It's what our product does." (See the column).

Let's shift gears to application outsourcing. Application Service Providers claim to be able to rent users access to applications at a lower overall cost as opposed to users providing the applications on their own. There are are more than 150 companies calling themselves ASPs now, selling applications ranging from e-mail to Enterprise Resource Planning systems. What kinds of companies, if any, could benefit from ASPs? And what should customers be concerned about with respect to ASPs?
Bradner: The sensibility of doing it.

Kobielus: Clearly, small and midsize customers can get the service right away without having to buy, install and manage the internal infrastructure – software, services and whatnot.

Bradner: They do have to maintain the internal physical network infrastructure to make use of such a service. And you need to be willing to trust your corporate family jewels and future to an independent third party.

Nolle: I'm very comfortable with the idea of application service outsourcing in a general sense and I'm very uncomfortable with all of the people who propose to do it because they seem to be attempting to outsource applications based on technical convenience instead of based on some objective buyer requirement to provide the thing on an outsource basis. I saw two presentations recently that were just surpassingly stupid. One of them was a company that proposed to provide SAP applications to small businesses. Now I'm a small business and I would find it extraordinarily difficult to even guess what I would do with an SAP application. And the other one was somebody who proposed to outsource components of Microsoft Office. Now here we are with people going out and buying high-performance Pentium systems to get good response from applications like Word and Excel and we believe we can run these applications at acceptable levels of performance by brokering them over a network connection? I don't think there's any logic in either one of those two perspectives.

Kobielus: That's why the application outsourcing model makes sense only if the provider also provides consultation services to help you manage and train your users to use these services. Some of the higher-grade ASPs are such shops – they are outsourcers and they are also consultants. And most applications that are being outsourced are not totally outsourced. The administration of the applications, whether they be e-mail or whatnot, still usually are handled in-house by the customer, by a browser via SSL connection or whatever in a secure way.

Nolle: But if you look at the applications that are actually being outsourced today with any degree of statistical significance, they were derived from the popularization of things like e-mail and the Internet. In many cases those applications were never insourced. Most most small organizations never had electronic mail internally until they ended up having electronic mail on the Internet. And it's not that they were outsourcing this application. They were simply extending existing Web site hosting and e-mail hosting agreements into, for example, hosting internal e-mail and some e-commerce applications that derive from the Web applications. But those are really not application outsourcing. Those are really new applications that were developed out of the Internet experience. And because the buyer has neither a political investment nor a technology or financial investment in these things, there isn't any resistance to doing them on a service basis as opposed to doing them on a capitalized basis.

Kobielus: Right. In many cases, as you indicated, these outsourcers are providing infrastructure that the customer never provided for themselves in the first place. But in other cases, for example e-mail outsourcing, you're finding the messaging service providers are targeting companies that are going through a lot of flux in terms of mergers and acquisitions and whatnot. They're providing a common message gateway infrastructure. Each of the individual companies that were merging had their own e-mail system but maybe one of them was using Exchange, another was using Domino and so on. So the outsourcer comes in and provides the gatewaying function, that common infrastructure that wasn't there, but only as a stopgap until the corporate customer says "Hey, we're going to take this in-house now, we've decided to consolidate on this or that system." Most companies as they scale up don't necessarily want to keep outsourcing these services. They want to at some point bring them in-house.

Nolle: If you look at the total revenue of all application outsourcers and, in fact, the total value of all of Internet services put together, it's less than the revenue from custom calling. So we're saying there's a lot of this, but there still isn't a lot of this in a financial sense and in a sense of the total amount of application expense that's actually outsourced. This is one of those areas where there's a good fundamental idea at the bottom of a whole bunch of industry crap and, unfortunately, a lot of the buyers are so engrossed in trying to dig through the crap that they're never going to get to the kernel of value.

Let's move on to corporate portals, which are intended to make it easier for people to find the information they need to do their jobs as compared with a plain vanilla intranet or Web site. How well do you think portal products, meaning development tools for building these portals, live up to this promise and how important do you expect this technology to be going forward?
Bradner: The concept is a valuable one. It's one that we're using with the students at Harvard and it looks quite impressive and quite good. I don't know about the products per se.

Nolle: I've only had a little experience with the products and the biggest problem I've seen in user applications with portals has been that a lot of organizations are not really aware of the fact that only 10% or 15% of their workers are really generalized information consumers. There's no point in spending a lot of money to information-empower somebody who has a job that is not information empowerable. For example, if you've got a bank teller, what's the value in giving them access to an information portal? Obviously, zero.

Bradner: Not quite zero because the portal has the business-related and employment-related information like retirement plans and health plans.

Nolle: But that's a personal value to them as an individual, it's not a value to their mission as a company employee.

Bradner: No, but it could be a cost savings for the company to do it this way vs. having a larger personnel office that the people take time off to go visit.

Nolle: Well one would have to ask in that instance if what you're doing is really a portal or an intranet.

Bradner: A portal I would define as something that's specific to the individual user, so that when I connect up I identify myself and it gives me my information – the information that either I've said I need or it's my retirement and my health information, not generalized information, which is definitely an intranet.

Kobielus: There's a real use for corporate portals as being basically just a template that a corporation has for its individual users. The company says, "You can use this standard template as your startup page or you can customize your own startup page to the needs of your own job. We plugged into this all the basic information sources that people in our company and our industry generally need." That makes a lot of sense.

Nolle: It makes sense for the high value employees. And I agree in theory, Scott, with your comment about cost reduction. But the problem is that, all of these technologies like portals are never going to achieve anything like the market success that people want them to achieve if one makes the assumption that there is a cost reduction benefit. That's because the cost associated with, for example, providing employees with retirement information by having them call the personnel office is not going to measured in the hundreds of billions of dollars.

Most of the products that I've seen have tended to be rather trivial in the way that they operated. And the trivialization was justified by the assumption that we were going to have a non-specialist worker use it. Well a non-specialist worker is probably not the target of portals in most cases. The truth is that there's only 10% to 15% of the workforce that's really going to gain value out of this.

Bradner: As I said at the beginning, I think the concept can be quite valuable. What the Harvard faculty of Arts & Sciences is doing with students is something which will be very valuable to effectively all the students. Students can get their course list and where they're supposed to be right now, their grades and all of that sort of stuff. Effectively, all the students will be empowered by this. But I don't think all the employees will be.

Kobielus: A corporate portal has to be eyeball glue, essentially, and it has to recognize the fact that the chief place where eyeballs are attached is to their e-mail. When I think of the right model for a corporate portal, I think of something like what Lotus has done with Release 5 of Domino and Notes. The Notes desktop now is wonderful because in one very nicely designed desktop you have their headline pages, which are basically pushed from the Internet or the intranet, you have their e-mail lists, you have their calendar. It's all in one format. That is the portal, that's the one place my eyes are always glued to.

Bradner: That's the concept which I think is reasonable.

Nolle: I agree – I think that's a reasonable concept. But the thing that's interesting is, the discussions we're having about what constitutes reasonable portals sound more like Lotus and Outlook than they sound like any of the portal products.

[At this point, Scott Bradner had to drop out of the discussion to return to the conference he was attending.]
The next topic is PDAs in the enterprise. Up to now most would agree that PDA purchases have been made pretty much on an individual basis. But 3Com says that about 80% of the Palm Pilots it sells are used in a work environment and about half are ultimately paid for by companies, not individuals. Is it time for network managers to start worrying about incorporating various types of handheld computing devices into their enterprise networks?
Nolle: I don't think it's time for them to start worrying about incorporating them in as much as it's perhaps time to start worrying about whether all these things that we're charging to the company are actually generating any company value.
I do think there is a likely value to integration of PDAs in a network context. But the problem we have right now is that all of the purchasing trends being discussed by 3Com really don't have as much to do with the value of PDAs as they do with the political influence of the PDA buyer. I can get a PDA justified if I can sign for it or my boss is willing to sign for it, but that doesn't necessarily mean that I've proved the use. It only means that I'm useful as an employee and, in effect, this is kind of a technical perc that I'm getting.
Some of the more recent activity by vendors in integrating cellular PCS transport with PDAs offers some potential benefits for a new class of portable device and a new application for portable computing technology. But we're just at the infancy of that right now and it's too early to judge how far we're going to be able to go with it.
Kobielus: PDAs are very good toys, they're a lot of fun to use. They'll only prove their worth in corporate environments if people can use them to gain faster access to their messages and appointments from the road. If that's a value to companies, and I think it probably is, then MIS should at least consider how they're going to integrate their existing messaging and calendaring infrastructure with these PDAs, and define what class of user can justify having a PDA and who can wait to get back to their office and use their "real" computer.
Corporations should simply extend the value proposition of the pager in this regard. Pagers have been justified for ages and ages in corporate environments. If you have a PDA that's enabled with CDPD or some other wireless data protocol, it's just a more versatile pager in a great sense.
Kearns: And it's a two-way pager, with a calendar.
Nolle: In fact, calendars and message management may be the big issue here because a PDA that was equipped with a communications interface would be able to not only arbitrate e-mail messages but also appointments, phone-mail messages and other things. It's that kind of time management and communication function and the ability of the PDA to serve as kind of a rule-based proxy for the PDA owner, and make decisions on when it beeps and when it doesn't beep and what it stores and what it forwards and so forth, that could really make the PDA valuable.
With the proliferation of corporate Web sites has come a proliferation of e-mail generated by those sites. Lots of users are struggling with how to respond to all this mail. Vendors such as Aditi, Brightware and eGain Communications claim to have the answer, with products that help users route and even automatically respond to e-mail. How important do you see these e-mail management products as being to enterprise users?
Nolle: That's a tough one. From my experience with those products, it's been very difficult to set them up so that they don't require almost as much manual attention as if you didn't have the product at all. You can look at them as a special case of an e-mail filter. And I'm sure every single one of Network World's readers who has employed an e-mail filter has spent a significant amount of time going to a directory where the supposed junk e-mail was put, and pulling out the legitimate messages that got trapped by it, and then getting rid of the junk ones that came in and looked legitimate. In the long run it's hard to say whether there was any benefit provided.
The challenge we have with e-mail is that there is a personal nature to human communications that we all seem to recognize. Most of us recognize junk e-mail by the lack of that personalization. So I'm afraid that if we get into a process where you're trying to manage e-mail generated by a site, generate automated responses and such, except for very certain and specific functions like order tracking, it may be counterproductive to try to go very deep into this because I'm afraid you're going to lose the sense of touch with the customer.
Kobielus: Content filtering technologies like this, as you've indicated, need a lot of human care and feeding because there are a lot of false positives. When you're talking about scanning the content of messages and then routing those message to the appropriate human beings, the list of what is considered an appropriate human being or department to handle any number of e-mails is always in flux and is always very ambiguous in any organization. No organization, no MIS department is going to have a firm grasp on who are the resource experts within the company who need to get this message or that message. I wouldn't trust MIS to tell the larger organization that certain messages are junk because they consider them junk. MIS knows computers and networks. We shouldn't generally give them the authority to decide what people need to know and don't know within an organization. So these content filtering technologies are just fraught with subjective issues.
Nolle: Yeah, I agree with that a lot.
The next topic is Windows 2000. Someday I'm sure Microsoft will deliver this. Should anyone care? Is there any reason to implement it right away?
Kearns: To implement it right away? No.
Nolle: I think there's a lot of reasons to not even think about implementing it right away. The big problem associated with any operating system change, no matter what it is, even from Windows 95 to 98, is the concern about software compatibility and the time it's going to take to reinstall the new stuff on a system. I know when we went from Windows 95 to Windows 98, even though we're not a large organization, we encountered a number of little nitpicking problems that made the process anything but completely painless. I can only imagine what it's going to be like to do a more dramatic upgrade. Organizations are going to have to do a pretty careful cost/benefit analysis on what they're going to get out of this process and they're going to have to move carefully on a trial basis to upgrade islands of people who relate a lot to one another until they get a feeling for exactly what the consequences of this are going to be.
Kobielus: Companies are going to have to batten down the hatches first and foremost for Y2K. Once that's behind them, then and only then should they start to consider even a trial rollout of Windows 2000. And before they do that there are some major issues in terms of, for example, deploying Active Directory and redefining the domains around Active Directory.
You take one big infrastructural project at a time. Y2K should be first and foremost. Then, if Windows 2000 makes sense for the company, maybe they're an NT 4.0 customer and they see great need to integrate a general purpose directory into their infrastructure, then and only then should they seriously consider upgrading to something like Windows 2000. But there's a lot of advance planning and design issues that they're going to have to deal with. Implementing it right away – that'd be insane. Yes, they need to evaluate it right away but start to implement it probably mid-year 2000 at the earliest.
Kearns: They should put it in their lab in mid-year 2000. Spend six months at least in the lab, playing with Active Directory, learning Active Directory, manipulating Active Directory and maybe around the first of the year 2001, start planning small rollouts.
Nolle: I'm of a mind that Active Directory in and of itself is not going to justify a migration to Windows 2000. What's going to justify it is some new set of applications built around Active Directory that the buyer values enough to pull Active Directory and Windows 2000 through.
Do you expect those applications will evolve?
Nolle: They'll evolve, but in a very specialized way that's not going to impact all users. And the adoption of Windows 2000 is probably going to be not significantly more than the percentage of total Windows desktops than the adoption of NT was.
The next topic is PKI. This seems like a technology that hasn't really caught on with the masses, as only those with the most stringent security needs have implemented it. But it seems necessary if you're going to have security in e-commerce applications that involve large amounts of money. What do you see as PKI's future?
Kearns: Security is what you need. PKI is just one way of getting security.
Nolle: I agree completely. The problem with public key encryption is, if you look at the history of crypto security, the problem from the user's perspective is that every time somebody announces a new security strategy, somebody in Denmark announces that they've cracked it in three weeks. That kind of performance is not conducive to building a lot of trust on the minds of the buyer. And one of the things that buyer research has shown is that the buyer tends to fall back on the concept of physical security of his network, which is to say partitioned facilities rather than something like an Internet type of an environment. What's going to happen with security is we're going to solve the security problem by keeping these highly secure transactions off of public IP networks like the Internet and we're going to create a different kind of public IP network that has a different technology basis and therefore is viewed by the buyer as being more intrinsically secure. Or we're going to go down to a virtual circuit network for this stuff.
Kearns: So VPNs are the key.
Nolle: VPNs are the key to the extent that VPNs are not simply tunnels over the Internet because if you're tunneling over the Internet or over any public IP network that's based on connectionless routing, you have the same problems with tunnel security as you have with traffic that's in the clear in a security sense. Tunneling doesn't create a secure connection. It only creates a partitioned network. If you want to partition the network in the true secure sense, you'd have to move down to the virtual circuit level. All the frame relay carriers have told me that buyers are no more likely to encrypt frame relay traffic than they are to encrypt leased line traffic, which means that buyers view frame relay virtual circuits to be as secure as leased lines. On the other hand, nobody views the Internet as being secure. What we're really saying here is, if public key confidence can't be built, and at least in the surveys we've done the user doesn't seem to be inclined to accept any technology as a convincing solution to this, then these secure applications are not going to run on the Internet.
Kearns: Why isn't the user accepting PKI, though? Is it because it's too complicated for him?

Nolle. In part. It's our mission as the insiders in this industry to educate users to a point of making them comfortable and we do not seem to have been able to do that up until now and I have my doubts whether it's possible. So somehow or another the process has got to be brought within the confidence grasp of the buyer. And if the only way to do that is to emulate private lines, then that's the only way to do it.
But even if you bring this traffic off the Internet and you create some other network and call it something else, don't you still have the same security problem?
Nolle: It depends on the technology. Certainly if I create something that's based on connectionless routing I have the same security problem. One could argue perhaps that the buyer's belief that virtual circuits are intrinsically secure is misplaced, but they believe it nevertheless.
Kearns: This is getting us pretty far afield from PKI, though.
Nolle: As somebody already said, PKI is just a mechanism for guaranteeing security. And it's a remedy that is useful only if the buyer believes in it and if the buyer doesn't believe in something simpler. I don't think buyers do believe in PKI. They clearly haven't demonstrated their belief by buying into it in any economic sense. But I also think that buyers believe that a simpler strategy, which is to say private line or virtual circuit networking, is the way they want to go.
Kobielus: Most of the market believes that whatever security mechanisms are built into their existing environments are good enough. When you're taking about creating a new infrastructure that is in some sense functionally redundant with existing infrastructure within your existing e-mail systems and NOSes, that's where the value proposition for PKI gets awfully questionable. You're talking about setting up all these certification authorities, registration authorities, validation authorities and you've got to integrate it with your directory and you've got to manage this new workflow within your MIS and networking shop in terms of issuing certificates when you create user accounts and renewing them and revoking them and sending out certification revocation lists. It's like, "OK, you're getting me into a new realm of rocket science, Mr. Vendor, but you're not telling me why I should be traveling to that planet."
Nolle: That's my point. What we've got here is a very complicated process and the buyer feels not so much that he is concerned as that he should be. He's afraid that a lack of concern is a politically indefensible position and so he's looking for some easy answer to the security problem. As you pointed out, correctly, maybe the problem is that PKI really isn't an easy solution to the security problem and for that reason it doesn't meet the buyer requirements.
Kearns: The strange thing is that the only encrypted and signed e-mails I've ever received were not strategic. Strategic information comes in the clear. So what we're finding is that there's a certain group of people who are tied closely to this technology and are using it for everything. And there are other people who perhaps need to use it and are put off by it so they don't use it for anything.
Someone mentioned certificate authorities. I see no reason in the world why I should put my trust in Joe's Certificate Authority to verify and validate some other user that I've never seen before because I don't know Joe either. These things are going to have to be centralized, they're going to have to be done at a much lower level in the application or in the network than they are now. It's got to be done without me really having to pay attention to it. And we're nowhere near close to that.
Nolle: I agree.
Let's get to the last question about controlling the buzz within the enterprise. We've talked about a lot of technologies that are generating a lot of buzz. It seems the buzz itself can make things tough on network managers, given upper management hears about these technologies and likely wants to implement them tomorrow. What can users to do control the buzz within their own organizations?
Nolle: You should go to the mailroom and prevent any trade magazine from being delivered to anyone with a title higher than director.
Kearns: You have to construct your portal correctly so that the right information is flowing to the decision makers.
Kobielus: And get them to stop watching the evening news and reading the general circulation newspapers, too.
Nolle: Unfortunately I agree with you and I don't think there's any answer to it. The problem today is really not so much buzz as it is the lack of a credible mechanism for building any real consensus on anything. We're always going to have a lot of issues and a lot of debate. Those are good things. What's bad is we don't have any mechanism for resolving those issues or that debate in favor of a position that is validated broadly in the marketplace.
Kobielus: Then it comes down to the need for a CIO or that kind of a person within an organization whose fundamental job is to survey the environment of technologies being buzzed about and explain to the non-technical and technical people how these issues fit into the company's broad strategic plan. That person may not be able to give a lot of substance in all of these areas, or to really lay out a clear battle plan for addressing those areas. But at least this person has a mental model that he or she can share with the rest of the company, saying, "I know what's important on this list and I can tell you what's less important."
Kearns: You cannot posit that every corporation will have a person with the capacity to thoroughly understand every hot new technology that comes along. No one has the time to do that. We don't have the time to do that and it's our job, essentially. We all specialize in certain areas. People in corporations are going to be specialized in certain areas. They have to learn to trust opinioned sources and find opinioned sources who are generally speaking in tune with the way they think. Think of it as the same way you read movie reviews or restaurant reviews. You find a restaurant reviewer who is somewhat attuned to your taste and you believe him. Same thing with movie reviewers.
Nolle: Sure, but here's an information industry which we are all a part of which has not been right about one major trend in the whole decade of the 90s. I would say we're sending our readers to the wrong restaurant in some respects.
Kobielus: But you get to the point where you validate a source, an authority, and you stick with that person, provisionally, conditionally, and that person filters the buzz until such time as that person's filters prove to be dysfunctional. Then you find another source of expertise.
More of the roundtable

In RealAudio
Hear the discussions.

Back to the Buzz home page

Send this article to a colleague

Back to the Buzz home page

absurd buzzword competition

Hear what or columnist say

related links

more stories

Intrusion detection

Policy-based switching

Feedback
Tell us your thoughts on this article or the issues it raises.

ICANN board approves reform agenda

House committee subpoenas WorldCom executives

KPMG Consulting to hire Andersen IT staff, not unit

Xerox accounting troubles may total $6 billion

Analysis: Ciena/ONI deal done

All of today's news

A good .plan
Plus: Porn credit-card site hacked.

Prioritizing voice over data in VoIP
Nutter helps a user make sure voice gets priority on a Cisco net.

E-comm Innovator of the Year Award
Know someone with a groundbreaking e-commerce project? Nominate him or her for our annual award.

Home
Contact us
Site Map
Today's news
This week in NW
Research

Free newsletters
Forums
Opinions
Careers
Terms of Service
Network World, Inc.

Seminars & Events
Advertiser Index
Product Showcase
Vendor white papers
NW Subscriptions

Copyright, 1995-2001 Network World, Inc. All rights reserved.