Towards an Internet NOS
The Internet gives us many truly wondrous things, some of which were only dreamed of just a few short years ago. The IP protocol gives us the ability to connect almost every imaginable type of device together on an unprecedented scale. Using SMTP, we also have access to a ubiquitous electronic mail service that just plain works. And we've even been able to implement such futuristic technologies as omnipresent hyper-linked document services.
Prior to the Internet's breakaway from the technology-enthusiast and early-adopter markets, many vendors had attempted to deliver on these promises using their own privately-developed technologies. While many were successful to a certain extent, none managed to reach mainstream market status on the scale that Internet technologies have.
For example, before the Internet hit the mainstream, Novell was out pushing for their own private Internet, with their own IPX-centric network/name registration service and backbone connectivity agreements. A variety of e-mail vendors were also pushing to get their technologies adopted as the industry standard, such as Microsoft's efforts through bundling a crippled version of Microsoft Mail with Windows for Workgroups and Windows NT. Meanwhile, LEXIS-NEXIS did their best to corner the on-line document-retrieval market through per-page charges and pervasive distribution.
Consumers love commodities (ie, free), regardless of the competitive advantages a value-add may carry. Once it was shown that the Internet just gives us this stuff for free, and "Hey! It works!", the game was practically over for the proprietary vendors. Although they still have room to sell their wares, no longer can they realistically envision becoming the standard which all others must license.
But whereas Internet technologies have delivered on these services, they have not done so for many others, particularly in areas one would expect from such a utilitarian environment. In particular, many of the NOS-related services found in the proprietary solutions are simply non-existent within the Internet community today.
For instance, there is no "standard" protocol or service for sharing files on a network. Sure, NFS and SMB are pseudo-standards with a large number of implementations, but they aren't truly "open standards" along the lines of HTTP or SMTP. Vendors wishing to implement these technologies have to pay homage (in the form of either cash or credence) to the organizations behind them. Just try adding a feature to the NFS spec. Go ahead; I'll wait.
There are also serious shortcomings in the areas of authentication and access control, especially in terms of consistent implementation among the most common Internet services such as mail. And, of course, there's also that niggling little problem of a universally-available, full-function, distributed and secure directory service in which to publish and restrict access to the various resources.
The Need for an Internet NOS
The value that a NOS provides is readily visible in any organization with more than one device on the network. A contemporary NOS (whether it be intraNetWare, Windows NT Server, or UNIX-based) provides a centralized authentication service, access to shared system resources like files and printers, and some sort of directory service (whether it be distributed like NDS or NIS+, or local like NetWare's SAP or Microsoft's WINS).
The problem with these implementations, regardless of how good they may be, is that they are completely proprietary. They are owned by the vendors behind them. And, as were the earlier efforts at protocols, e-mail and document retrieval, they are non-interoperable for anything other than basic functionality.
I'm tired of trying to make all my systems speak NFS when they all do such a poor job of it. Novell's NFS service is infamous; meanwhile, Microsoft doesn't even have one. Likewise, I'm sick of trying to synchronize my NDS-, NIS- and NT-based authentication services when each of the NOSes demand on being the primary source, refusing to even boot without a local copy of the data. So much for cross-platform networking!
If we are ever to fulfill our shared destiny of complete interoperability, we must find a way to deliver on these technologies in a vendor-independent, cooperative manner. Having transports and applications that communicate effectively is a wonderful thing alright, but it is not enough. We have to find technologies that can provide the same kinds of general network services found in the contemporary NOSes as well.
This includes an authentication technology that is both acceptable and easily-deployed (why am I still logging in to my local FTP server?). We also need a robust and mature directory service that functions equally well in local and distributed environments. We also need a resource-sharing service that provides cross-platform connectivity without reducing access control to the lowest-common-denominator platform.
This is a big challenge. However, a solution to this problem already exists, is widely available, and is supported by almost every major system vendor. With a little bit of help from some well-funded vendors, it could easily step up to the challenge, providing an acceptable, low-cost solution to the cross-platform connectivity problem.
That solution is DCE.
DCE is the Best Choice
Yeah, I know, DCE has gotten a bum rap due to its development complexity and overhead. But I'm not suggesting that we adopt the entire DCE development environment. Rather, I'm suggesting that we steal DCE's integrated directory, security and resource-sharing components, make them IETF-sanctioned, and then use this as a framework to build an Internet-centric NOS. Let's look at the advantages that this would provide:
- DCE is already implemented on just about every computing platform one could imagine. IBM has DCE products running on everything from LAN Server to their biggest of iron. Digital and Hewlett-Packard have ports for everything from Windows 3.x to VMS. There's even a port for Linux. DCE is already pervasive.
- DCE is already standards-centric, relying on Internet-based protocols and services for the majority of its functionality. The heart of DCE's authentication service is Kerberos, for heaven's sake! There won't need to be lots of work done to make it IETF-kosher.
- DCE already has a fully-functional directory service that works well locally while not shying away from inter-organizational connectivity. The directory service is even capable of using DNS to locate directories in other domains, a feature not found in ANY other directory service, apart from NIS+. Further, the native Kerberos security service is integrated directly into the directory service, providing scalable authentication that works inside your local network as well as with inter-organizational connections.
- DCE also has a distributed file service that's well understood, widely-supported, and light years ahead of the other filesystems commonly found on LANs (nevermind WANs) today. That's another bird we can kill with just this one stone. However, DFS' reliance on DCE's RPC interface may be too much of a step to take, especially considering the IETF's seeming aversion to APIs in general, and my own concerns regarding the DCE development environment in general.
I don't want to come across as a zealot; I realize that DCE lacks many needed services in order for it to become as acceptable and pervasive as SMTP. Yet, these holes are easily patched. For example, although there are no DCE standards for printing, there are Internet-based technologies that could easily be integrated into the DCE framework, providing better distributed printing than LPD alone can offer. Think about it: LPD integrated into DCE's directory and security service would be awesome. So would an integrated IMAP server. And RADIUS integration would be great, too. Jeez, come to think of it, just about ALL of the Internet-based technologies would benefit tremendously from being integrated into DCE's directory and security services. Hey! I wouldn't have to login to my FTP server anymore!
DCE also has a fundamental problem in that it lacks visibility. This is because the OSF doesn't have the marketing resources to promote it aggressively against the proprietary vendors. Still, for having no budget, DCE has a remarkable amount of market share already. All that's needed is a well-funded and highly-visible vendor to promote it as an Internet-based solution to the cross-platform networking problem.
Memo to Barksdale
That company should be Netscape. Simply put, they are the only people with enough clout and money to drive this effort to success. They also have the skills to build cross-platform Internet-centric DCE products. In short, Netscape is uniquely positioned to do this.
- First of all, Netscape already recognizes that its future lies in server technology. Although they offer many server-based applications already, the critical missing components are the NOS-based glue that ties them all together. DCE's integrated security and directory services provide this glue. I'm not saying Netscape should give up on client-based certificates and LDAP, but instead that they should leverage the existing DCE technologies to speed up the delivery of the benefits promised by these other technologies. Certs and LDAP are okay, but DCE gives us better technology now.
- Second, Netscape is uniquely positioned to accelerate the adoption of DCE as a commodity technology along the lines of IMAP. Novell and Microsoft won't do anything to promote DCE as long as they're married to their legacy technologies. However, Netscape has nothing to lose—indeed they only have mainstream markets to gain—by promoting DCE as a "standard" NOS platform. Once this message is "out there" then the other vendors will fall in line, just as they have with IMAP, LDAP, and other orphaned technologies that gained prominence after Netscape endorsed them.
- Netscape also has the necessary partnerships in place already. By leveraging their existing relationships with IBM and Sun, it would be easy to pick up the ball and start running with it. In addition, Netscape would gain increased access to companies such as HP and DEC through those firms' back-door support of DCE. There's no downside here, either.
- Mission Control promises to make managing directory-based objects easier than ever through the use of open standards to build portable and rich management tools. These tools could also be very useful in managing DCE's directory and security servers. Please?
- Netscape's expertise with cross-platform development means that they can accelerate the deployment of a consistent DCE platform to a variety of systems quickly. Although DCE is already implementated on more platforms than any other NOS, these implementations aren't always consistent. Netscape excels at cross-platform consistency.
- What DCE lacks—namely a variety of off-the-shelf network services that take advantage of it—the Internet provides and Netscape can integrate. So, whereas there is no DCE standard for printing per se, Netscape can integrate LPD into DCE, providing access to printers around the world using the existing directory and security controls. The same can be done with RADIUS, IMAP, etc. These ports wouldn't have to vary from the standards in any manner, and could still be compliant with the RFCs regardless of their low-level code. This would result in a truly Internet-centric NOS that folks like me would gladly pay for.
Overall, Netscape has the opportunity and the expertise required to bring the robust nature of DCE and the wide variety of Internet services together into a full-service, standards-centric network operating system. This package can be built quickly by leveraging against the existing technologies, and promoted as a vendor-independent NOS similar to the way in which other technologies like HTTP and SMTP have been.
As history has shown, the companies that accelerate the commoditization of technology typically become the winners. Netscape is uniquely positioned to do this acceleration. By driving the adoption of DCE within corporate and workgroup networks, Netscape can bring the power of the Internet to a larger market faster and with more profits than the proprietary vendors could even imagine.
Copyright © 2010-2017 Eric A. Hall.