OSF DME Rationale

1. Executive Summary
   1. A PERSPECTIVE ON THE PROBLEM
   2. AN OVERVIEW OF THE SOLUTION
   3. A BALANCE BETWEEN INNOVATION AND STANDARDS COMPLIANCE
2. Introduction
   1. DEFINING THE SOLUTION
   2. STANDARDS FOR MANAGEMENT
      1. ISO Standards
      2. TCP/IP
   3. THE DIRECTION OF DISTRIBUTED SYSTEMS AND NETWORK MANAGEMENT
3. OSF's Vision for the Distributed Management Environment
   1. CONSISTENCY
   2. INTEROPERABILITY
   3. SCALABILITY
4. DME Architecture
   1. MANAGEMENT USER INTERFACE SERVICES
   2. APPLICATION SERVICES
   3. OBJECT SERVICES
   4. MANAGEMENT SERVICES
   5. MANAGEMENT PROTOCOLS
   6. DME DEVELOPMENT TOOLKIT
   7. INTEGRATION WITH DCE AND OSF/MOTIF TECHNOLOGIES
5. The OSF Distributed Management Environment Framework
   1. CRITERIA FOR THE OSF DISTRIBUTED MANAGEMENT ENVIRONMENT
      1. Scalability
      2. Fully Distributed Functionality
      3. Interoperability
      4. Remote Procedure Call for Communications
      5. Ability to Support Policies and Roles
      6. Security
      7. APIs for Different Types of Uses
   2. FRAMEWORK TECHNOLOGY SUBMISSIONS
      1. Initial Evaluations
      2. One Approach: Adapting an Existing Framework
      3. An Alternative Approach: Combining Technologies
      4. Selection Rationale
   3. THE OSF DME FRAMEWORK OFFERING
      1. DME Application Programming Interfaces (API)
      2. Management Request Brokers
      3. Management Protocols
      4. Object Servers
      5. Event Management
6. OSF Distributed Management Environment Services
   1. SOFTWARE DISTRIBUTION AND INSTALLATION APPLICATION SERVICES
      1. Selection Criteria
      2. Software Distribution and Installation Submissions
      3. Selection Rationale
      4. The DME Software Distribution and Installation Offering
   2. DISTRIBUTED PRINT APPLICATION SERVICE
      1. Criteria for Distributed Print Systems
      2. Print System Submissions
      3. Selection Rationale
      4. The DME Print System Offering
   3. DISTRIBUTED LICENSE SERVICE
      1. Criteria for Distributed License Management Systems
      2. Distributed License Management Submissions
      3. Selection Rationale
      4. The DME License Management Offering
   4. HOST MANAGEMENT
      1. Host Management Submissions
      2. Selection Rationale
      3. The DME Host Management Offering
   5. PERSONAL COMPUTER INTEGRATION TECHNOLOGY
   6. PERSONAL COMPUTER INTEGRATION SUBMISSIONS
      1. Selection Rationale
      2. The DME Personal Computer Integration Offering
7. Appendix A -- A Brief History of the DME RFT
   1. THE DME EVALUATION TEAM
   2. DME CONSULTANTS
   3. DME EVALUATION TEAM
8. Appendix B -- The Open Process
9. Appendix C -- The DME Request for Technology
   1. User Requirement
   2. Scope
   3. Management Framework
   4. Management Applications
   5. What Is Not Covered In This RFT
   6. Mandatory Requirements
   7. Standards Conformity
   8. Portability
   9. Documentation
   10. Validation and Testing Support
   11. Product Readiness
   12. Reasonable and Equitable Licensing Terms
   13. Key Evaluation Criteria
   14. Evaluation Process and Milestones
   15. Review Process

Executive Summary

Through its fourth Request for Technology, OSF solicited technologies that could be integrated to simplify the management of systems in heterogeneous computing environments. Using its open process for evaluating proposals, OSF worked with its membership, technology providers, standards organizations, and other expert consultants to define the OSF Distributed Management Environment (DME).

A PERSPECTIVE ON THE PROBLEM

AN OVERVIEW OF THE SOLUTION

In addition to serving as a solid foundation for systems and network management, the DME will enrich the management of OSF's open computing environment, a portfolio of enabling technologies designed to ease the development, use, portability, and management of software in heterogeneous computing environments. This portfolio includes the OSF Distributed Computing Environment (DCE), the OSF/1(TM) operating system, the OSF/Motif® graphical user interface, and the OSF Architecture-Neutral Distribution Format (ANDF) for portable distribution of applications. Like all OSF offerings, the OSF DME will comply with relevant international standards -- both existing and emerging.

A BALANCE BETWEEN INNOVATION AND STANDARDS COMPLIANCE

Every computing constituency will benefit from the synthesis of technologies in the DME offering. For the end user and system administrator, the DME will

• Reduce the time, training, and costs required by management tasks
• Improve the reliability and availability of systems and networks
• Increase the portability of user skills between different platforms
• Reduce the skill level required to perform management tasks
• Provide the flexibility to adapt the system to local management policies: for example, centralized or distributed
• Extend the interoperability of open systems utilizing common management services.

• Provide tools as sophisticated as those available for proprietary systems for the simplified development of portable management applications
• Create an expanded market for systems management applications
• Provide for the development of applications that manage stand-alone and distributed systems.

• Provide a consistent management environment for heterogeneous systems
• Reduce development and maintenance costs associated with systems management applications.

Appendices A through C include a history of the DME Request for Technology, an overview of OSF's open process, and more on the technologies OSF solicited to address the problems of distributed systems management.

Introduction

The precursors of today's open systems were the UNIX® operating system and its derivatives. Because these early systems were designed for use by programmers, management of as well as interaction with these systems required technical proficiency. Users of those systems typically performed several functions -- as administrators, systems programmers, operating system kernel specialists, and end users.

Over time, a larger community adopted these early UNIX systems, mostly in scientific environments. As in earlier settings, these users, who were more technically proficient than the typical business user, performed system administration. Most of the extensions and enhancements made to those systems were cryptic. Users who knew what they were doing found the systems to be efficient and simple to use. For the uninitiated, however, using or administering them proved almost impossible.

The reputation of these UNIX systems for availability on a wide range of platforms, network connectivity, and portability of applications caught the interest of computer users in commercial settings, taking these systems beyond academe and scientific environments. Commercial users were accustomed to using the elaborate management facilities of proprietary operating systems. They soon learned that the business advantages they gained with UNIX systems had a price: Administering those systems was extremely difficult. Management tools and expertise developed for academic environments had to be adapted for use in commercial environments, which forced commercial users to hire systems management experts. The complexities of networks made up of personal computers, mainframes, workstations, and other equipment from various vendors further aggravated the situation by increasing administrative costs.

Today systems and network management encompass many incompatible approaches, often performed by separate departments. In a typical organization, the two are perceived as entirely separate realms. Each has its own management model, traditions, and vocabulary, as well as means of defining and storing data. In the DME, OSF has brought together those approaches to simplify both types of management and reduce the associated costs.

DEFINING THE SOLUTION

In both systems and network management, an administrator manages by modifying information related to a resource or a service, and by invoking operations on some service and data. The classification of this information and these operations into objects leads to a well-defined and structured approach to managing resources and services. An object, in this context, is the consolidation of data and operations into one entity -- a managed object -- which represents the resource or service to be managed. In this way, all management operations can be carried out through the same interface and with the same style of interaction -- by communicating with objects. The concept of managed objects unifies the seemingly different approaches of systems and network management. Many organizations currently addressing problems associated with management are considering this object-oriented approach.

STANDARDS FOR MANAGEMENT

ISO Standards

A management protocol such as CMIP alone does not solve the problem of managing distributed systems. Standards also are required to address how management data is organized, how operations on this data are defined, and how the managed resources can be found in the network. These areas are partially covered by the ISO standards for the Structure of Management Information (known as the OSI SMI): Management Information Model, Definition of Management Information, and Guidelines for the Definition of Managed Objects (GDMO). These standards define the conceptual model of how management information is to be treated abstractly. A managed object is a representation of the resources and services to be managed in terms of its current state (attributes), its behavior (operations) and the event notifications it
may generate.

ISO standards leave open many details and implementation issues, which are being addressed in implementors' workshops and profile documents as well as by industry consortia. Some examples are the OSI (Open Systems Interconnect) Implementors Workshops (OIW, EWOS, and AOW) and the OSI/Network Management Forum (OSI/NMF).

Although the adoption of OSI standards has been slow in the past years, the momentum behind them is gaining. OSF is committed to following relevant industry standards; therefore, the OSF DME will support the relevant OSI standards for distributed management.

TCP/IP

While the ISO/OSI management standards were evolving slowly, the use of TCP/IP grew rapidly and the industry sought a lightweight solution for the management of TCP/IP networking that could be implemented easily without the large resource requirements typically required by OSI implementations. The result of this effort is the Internet Simple Network Management Protocol (SNMP), and the Internet Management Information Base (MIB). Because of their inherent simplicity, these standards have a number of limitations; for example, they do not address all areas of systems and network management in a consistent, complete fashion, and work remains to be done in the area of security. However, these de facto standards do solve a significant number of problems related to the management of TCP/IP networks. As a result, they are implemented in many variations and are in relatively wide use today. The Internet management standards can no longer be considered an interim solution but will continue to be used and coexist with formal standards. For all these reasons, these de facto standards serve a valuable purpose and will be supported in the OSF Distributed Management Environment.

THE DIRECTION OF DISTRIBUTED SYSTEMS AND NETWORK MANAGEMENT

Current developments in distributed computing, such as OSF's DCE or the Object Management Group's Object Request Broker (OMG ORB(TM)) specification, address areas which are not covered by management standards. For example, security is not yet properly addressed in CMIP. Object naming in the OSI SMI follows a strictly hierarchical approach that is not well suited for all distributed services, and support for transactional operations is minimal.

The OSF DME complies with current standards and incorporates innovative technology. It eliminates some of the idiosyncrasies of the OSI standards, yet is more generally applicable than SNMP while addressing the requirements of emerging distributed computing environments.

Common to most systems and network management approaches is the object-oriented model of a distributed system. The model used for each approach assumes a dichotomy of roles: managers (management applications) and agents (object servers) represent the different roles objects carry out. There are, however, three major differences between the models, each related to the capabilities those objects have. First, intelligent objects respond to requests; dumb objects, or data containers, leave much of the work to management applications. Second, the management protocols have different semantics. Third, the two models take different approaches to locating objects in the network.

The OSF DME technologies will bring together the worlds of network and systems management in a consistent superstructure that builds on functionality from OSF DCE and the work being done by OMG(TM) and OSI/NMF. The following sections explain OSF's vision for this environment.

OSF's Vision for the Distributed Management Environment

CONSISTENCY

With a consistent graphical user interface, clicking on the "ENABLE" button of a menu related to a router icon and hitting the "ENABLE" button of a menu related to a printer queue will have comparable effects, namely, enabling the router or the queue, respectively. Dragging a user icon onto a collection object representing a group of users will have the equivalent effect of dragging a node icon onto a domain object representing a domain of computer nodes: the user is added to the group, the node is added to the domain.

Consistency applies not only to user interfaces, but to the syntax and semantics of application programming interfaces as well. Accessing a user object with the OSF DME will not be different from accessing a router object anywhere in the network. The management system will ensure that the appropriate management protocol is used to communicate with the object requested. The inherent differences between object models will be masked from the application
programmer.

INTEROPERABILITY

Interoperability with other proprietary management systems will be possible through the use of gateway technologies such as proxy agents, which translate management protocols and object models. The DME will protect management data and services through sophisticated security mechanisms that authenticate users and limit access to authorized personnel.

SCALABILITY

The OSF implementation of the DME will follow a three-level model that addresses this problem by breaking a large system into smaller units, creating a more manageable environment for users. Like the OSF DCE, the DME adopts the notion of a cell, a group of systems administered as one domain. This model allows the management of single systems as well as entire enterprises, and although it appears to be centralized, it is, in fact, distributed. The entities within each tier need not be managed from a single point. In fact, if an organization is decentralized, the model may become that of a federation. In such a case, management of each domain may be centralized; however, the different domains may share management information and
cooperate.

• On the lowest tier are single nodes, each of which always requires some small amount of management attention. Depending on the configuration, managing them through the DME as federations of individual systems may be feasible in small environments. Where necessary, management data can be replicated over the systems without threatening its consistency.
• On the second tier are the cells. As the number of entities in a cell grows, management services must be provided cellwide, scaling to the hundreds and, possibly, thousands of systems. Except for cases in which management data is pertinent to each individual node and has to be maintained locally, management operations will be carried out through a distributed service. Managing the services in the distributed environment rather than the individual node leads to consistency among nodes and greater possibilities for scalability.

• nThe third tier normally does not access nodes directly. Instead, it delegates management tasks to an agent in a cell. In keeping with its high-level function, this management tier should not be overwhelmed with data. It should instead process management information that already has been accumulated at the cell level. An enterprise management system is one example of a third-tier system.

DME Architecture

In order to unify the worlds of systems and network management, OSF has defined the architecture for the Distributed Management Environment as the common foundation for integrating information and applications. This architecture provides for the services needed to manage diverse systems.

MANAGEMENT USER INTERFACE SERVICES

The DME user interface model follows the object model used by the DME architecture, providing two advantages. First, it reflects the underlying objects, thus providing a clear view of the system structure. Second, it provides a consistent model that allows the industry to enhance it.

APPLICATION SERVICES

• License Management Services. As the number of computer sysems installed in distributed environments grows, the management of software licenses becomes increasingly cumbersome. The distributed license management services of the DME, supporting many different license modes, will offer an effective means of tracking software licenses and provide protection for the software supplier, as well as improved management capabilities for the system manager.
• Software Management Services. Keeping the installed software base in a network up-to-date is one task a system administrator performs. This DME service will ease the packaging, distribution, installation, and management of software.
• Printing Services. The facilities for network printing available today are inadequate for sophisticated distributed environments in terms of both functionality and manageability. The DME printing system, designed with distribution and extensibility in mind, will combine superior functionality with the flexibility and security needed in heterogeneous computer networks.
• Host Management. This application and its associated services make up a prototypical example of distributed management. In the OSF DME, it has been extended to work in a distributed environment with diverse services.

This initial set of application services provides essential technology and enables the DME to help solve user problems. In addition, it serves as a model for how the industry can extend and add value to the DME. Extending the set of applications and application services thus creates market opportunities for the computer industry.

An extension to the host management application, for example, would be user and group management. It might include the local standard UNIX user/group management concepts of /etc/passwd and /etc/group files, the DCE user registry and the Network Information Service, each of which uses its own management strategies.

OBJECT SERVICES

The data these objects contain must sometimes be kept in nonvolatile storage. To meet this requirement, the framework includes a data repository for OSF DME object attributes.

Management applications and their users need to be notified about events occurring in managed objects. Event services handle the forwarding of event notifications between systems, the filtering of events, and the subscription to specific events by management applications.

MANAGEMENT SERVICES

MANAGEMENT PROTOCOLS

DME DEVELOPMENT TOOLKIT

The OSF DME is designed to accommodate the large number of management services and applications deployed in networks and computers worldwide. As a result, services and applications currently in use will not be made obsolete by the DME, but will coexist with their DME counterparts. The DME framework accommodates existing management applications and allows co-existence with proprietary schemes. In this way, it permits smooth migration to a fully integrated distributed management environment.

INTEGRATION WITH DCE AND OSF/MOTIF TECHNOLOGIES

• All OSF DME application services -- license management, printing and software distribution, as well as their associated management interfaces -- will be based on the DCE Remote Procedure Call services. In the OSF DME framework, RPC will be used, in addition to standard management protocols, to access application and managed objects, and to forward notifications between systems.
• Object access via the OSF DME framework can be authorized on a per-request basis. Authentication is provided through the OSF DCE Security services.
• Objects and services in OSF DME will be named and located through the OSF DCE
  Directory services.
• Many service providers will be multi-threaded through the use of the DCE Threads function.
• Many DME services will use the DME graphical user interface based on OSF/Motif. The management user interface toolkit in the DME framework complies with the OSF/Motif Style Guide.

The OSF Distributed Management Environment Framework

Many of the submissions OSF received in response to the DME Request For Technology could implement such a framework or parts of it. This section outlines the key selection criteria OSF defined for the framework and describes those technologies that fulfilled most of these
requirements.

CRITERIA FOR THE OSF DISTRIBUTED MANAGEMENT ENVIRONMENT

Scalability

In addition, management services must be able to delegate tasks to other services anywhere in the network. In OSI terminology, the entity requesting a service is called a manager or is said to be acting in the role of a manager; the entity that provides the service is called an agent. Therefore, to achieve symmetry, the entity acting as an agent must be able to act in the manager role as well. Using this symmetric approach, the DME will provide for the multi-tiered management necessary in large environments.

Fully Distributed Functionality

Interoperability

Remote Procedure Call for Communications

Ability to Support Policies and Roles

Security

APIs for Different Types of Uses

FRAMEWORK TECHNOLOGY SUBMISSIONS

• British Telecom submitted parts of its CONCERT(TM) product portfolio. It provides an OSI agent development toolkit and an implementation of the CMIP management protocol.
• The DECmcc(TM) Director and Common Agent, from Digital Equipment Corporation, provides a complete framework for management, including event services, graphical and character-oriented display services, support for SNMP and CMIP, and an object server primarily
  for CMIP.
• Groupe Bull's implementation of the Consolidated Management application programmers interface (CM-API) offers a consistent means to access the CMIP and SNMP
  management protocols.
• Hewlett-Packard's OpenView(TM) Network Management Server is a communications infrastructure supporting the standard network management protocols (CMIP and SNMP). It includes the Postmaster, a management request broker, and graphical services for display of
  network maps.
• IBM's Data Engine, an object server environment geared to multi-threaded, high-performance monitoring and control of resources, includes SNMP gateway services. OSF also evaluated IBM's System Resource Controller (SRC), a service to consistently monitor and control
  system processes.
• Moira,(TM) from the Massachusetts Institute of Technology's Project Athena, is a management environment for controlling and configuring network services.
• NCR submitted a proposal to develop an OSI agent development toolkit.
• Tivoli's WizDOM(TM) is an object-oriented framework with a set of services that governs object interaction, providing a cohesive model of management, along with graphical display services and a command-line interface.
• Touch Communications' Alliance OSI is an OSI agent development toolkit.
• Wang Laboratories submitted Network Event Logger (NeL), which provides event services such as filtering, forwarding, and logging of information. NeL also includes support for event management for personal computers based on the DOS operating system. (This technology has been acquired by Banyan Systems.)

Initial Evaluations

Two of these submissions -- Moira, and the OSI agent development toolkit from NCR -- do not meet mandatory evaluation criteria for the DME framework. Moira does not meet the requirements of a three-tiered architecture; it is suitable only for the second tier, the cell. It is geared mainly towards configuration management; other management functional areas are not addressed. Moreover, it is not suitable for real-time management. The framework submission from NCR was too early in its development life cycle and therefore did not meet the product-readiness requirement.

Some of the submissions were designed to perform centralized management. Others were designed to meet the needs of distributed systems management without supporting all of the network management standards. The remainder were designed to perform distributed network management, supporting the relevant standards yet not meeting the needs of distributed systems management.

This situation presented OSF with two options:

• To take an existing framework that offers a comprehensive set of base functionality and add the required features.
• To build a distributed management environment by integrating technologies that provide innovative functionality in a coherent framework.

Each alternative presents benefits as well as potential pitfalls. The amount of work needed to integrate different technologies could pose some risk; however, the development effort needed to extend an existing base framework could present comparable problems. And although beginning with a homogeneous framework might produce a coherent solution, the inherent limitations of the framework might prohibit the addition of features necessary to meet critical requirements.

One Approach: Adapting an Existing Framework

The modular architecture of this submission provides for

• Presentation modules that can be viewed as the applications responsible for user interaction
• Function modules that provide common services such as alarm or performance management
• Access modules that communicate with the agents and map the different external object models to the internal entity model.

The framework provides SNMP and CMIP access modules. Presentation modules include an iconic map graphical user interface as well as a forms and command-line interface.

A template language, MSL (Management Specification Language), and supporting tools allow for the specification of object definitions. This language also allows the presentation modules to generate command-line parsers and generic iconic representations for objects automatically. It is not based on the ISO Guidelines for the Definition of Managed Objects.

Additional services include the historian, which is responsible for maintaining historical data; scheduling, which provides for timely invocation of services; and alarm management, which provides for handling of events generated by objects.

The Common Agent provides for the implementation of object servers, supporting both SNMP and CMIP. Additional services include a managed object location directory, and managed object support services.

An Alternative Approach: Combining Technologies

After evaluating many possible combinations and integration alternatives, one combination emerged as the superior solution. The framework for that alternative, in Figure 2, shows how the APIs, the two management request brokers, and the communication protocols are arranged.

A CMIS-oriented API, the CM-API from Groupe Bull, provides access to the management protocols, SNMP and CMIP, and the management RPC. The two higher level APIs -- objcall, an ANSI-C API provided by Tivoli Systems, and a C++ API based on IBM's Data Engine technology -- hide the complexity of the communication protocols.

Routing, address resolution, and authentication are handled by the management request brokers: Hewlett-Packard's Postmaster for applications using CMIP or SNMP, and Tivoli's Object Dispatcher for applications using the DME management RPC. The DME communications infrastructure can be interfaced to various network communication transports. The services common to both management request brokers are provided by the OSF Distributed Computing Environment. In the OSF DME reference implementation, Hewlett-Packard's CMIP implementation will use the DCE's upper-layer OSI stack.

The DME management request brokers support the SNMP SMI (Structure of Management Information) and OSI SMI. As described in the introduction to this document, the DME provides a third model that is more powerful than the SNMP model but is not as complex as
the OSI SMI.

Applications and object servers plug into this framework in the same manner (see Figures 3 and 4). From the framework point of view, there is no difference between a manager and an agent; they use the same APIs and protocols. One difference exists, however: applications make use of the display services, whereas object servers typically do not. Important benefits of this symmetrical design are increased flexibility and support for the multi-tiered architecture of the DME.

Two object servers, IBM's Data Engine and Tivoli's Object Dispatcher, perform complementary roles. Tivoli's is most suited for short-lived, task-oriented operations and application integration. The Data Engine is more appropriate for monitoring and control operations.

The event management system can be viewed as a special object server. Wang's NeL is responsible for creating event notifications, filtering them through sieves provided by applications, forwarding them to interested applications, and logging them.

Selection Rationale

OSF has defined the DME architecture to be symmetrical and fully distributed. These characteristics are required to support the multi-tiered architecture described earlier and to fulfill the scalability requirement. The framework of combined technologies fully meets these requirements. The Digital architecture, however, is inherently asymmetrical, and although it provides for distributed operation, the DECmcc implementation is not distributed. In addition to not fulfilling the scalability requirement for very large distributed environments, the DECmcc does not scale down to a single system or small systems easily.

OSF also considered how the two alternatives -- the combined technologies and the DECmcc -- would evolve. To do so, the DME evaluation team looked at the planned DME offering, comparing it with the current implementation of the DECmcc and its likely evolution. It is OSF's judgment that the combined technologies will provide more advanced support for local definition of policies and administrative roles and security.

Finally, OSF compared the programming support offered by each alternative. For the developer, a rich set of APIs is very important. The combined technologies offer objcall and the C++ API, which greatly reduce the effort required to develop applications and objects. The DECmcc submission, which also offers a high-level API that is dependent on an underlying data model, can be confusing for programmers.

Thus the framework of combined technologies fulfills all the requirements OSF defined for the DME. It also offers advanced functionality not provided with other frameworks, such as multi-threaded object servers and C++ interfaces. Furthermore, many of the components that form the base technologies of the framework are available today. Currently, Tivoli's WizDOM is used for system-management tasks; Hewlett-Packard's OpenView, including the Postmaster technology, is used to manage SNMP and CMIP networks; and IBM's Data Engine is used for the management of the National Science Foundation Network.

Unlike the integrated framework proposed by OSF, DECmcc did not meet several important requirements. Moreover, its architecture encompasses communication and presentation services in a way that does not offer clear migration paths for other technologies. Therefore, it would be difficult for OSF to integrate into the DECmcc technologies that would provide missing functionality, such as support for policies or authentication and authorization. For the same reasons, extracting technologies from the DECmcc submission for use in an alternative combination was found to be impractical.

The technologies that will be integrated to create the DME framework have a sophisticated design that hides their complexity behind object boundaries. This and the quality of their source code suggest that the risk involved in integrating them will be low. Furthermore, no single component of the framework could delay the integration, since most components can be handled separately. Consequently, the functionality gained through integration far outweighs the risks.

THE OSF DME FRAMEWORK OFFERING

DME Application Programming Interfaces (API)

The Consolidated Management API (CM-API) provides for direct access to the management protocols, SNMP and CMIP, and management RPC. The access to different protocols and object models is supported by an approach called packages, which implement the specific semantic requirements and encoding conventions used in each model. Thus, for developers requiring direct access to the idiosyncrasies of a specific management protocol, the underlying management paradigm is not completely hidden, but is presented in a consistent way.

Tivoli's objcall API provides an easy-to-use, object-oriented API. Its purpose is to invoke methods on objects on a coarser level than CM-API. It is more suited for application development and integration than for instrumentation access.

OSF recognizes that C++ is becoming a widely used implementation language. Development in object-oriented environments is done most naturally with an object-oriented language binding. The C++ API provides such a binding and can hide much of the complexity of the data types and data structures used in management.

Management Request Brokers

• mapping names to locations using an external directory service
• choosing the right communication protocol to route messages between applications and/or object servers
• authenticating a requestor using an external security service
• registering and controlling object servers.

The selected management request brokers will use external services provided by the OSF Distributed Computing Environment: the global and cell directory services, security, and RPC. IBM's System Resource Controller will be used to support automated server control facilities (such as starting and stopping the servers).

Two implementations of management request brokers will be provided with the DME offering, each optimized to satisfy different requirements.

• Hewlett-Packard's Postmaster, from the OpenView(TM) network management offering, provides access to standard management protocols, SNMP and CMIP.
• Tivoli's Object Dispatcher, part of the WizDOM(TM) offering, provides a secure, RPC-based systems management framework.

Management Protocols

The DME framework provides two means of accessing SNMP: through Hewlett-Packard's Postmaster and IBM's Query Engine. This engine, accessed through Tivoli's management request broker, provides a higher-level view than the raw SNMP protocol. In that way, SNMP management is completely integrated with the Tivoli and Data Engine object server
environments.

The communication infrastructure within the OSF DME implementation also will support the management RPC. This specific layer -- syntax and semantics -- on top of the DCE RPC implements a management protocol optimized for secure, distributed systems management. It is based on Tivoli's protocol.

Object Servers

The WizDOM object server is geared toward short-lived management operations performed through processes outside the object server. Every operation is authorized by the server. This object server also accommodates applications developed outside the OSF DME.

IBM's Data Engine is a multi-threaded server that supports objects residing within one server. Thus communication between objects is very efficient. This server allows for long-lived management operations such as monitoring of a system resource.

Event Management

OSF selected a generalized solution, Wang Laboratories' Network Event Logger (NeL). It supports all the event types defined in the OSI management standards. A template language allows for the addition of new event types. An easy-to-use API and a well-architected implementation permit efficient sieving of events as close to the source as possible. Events can be filtered on a variety of fields and conditions.

Communication is done via local IPC (interprocess communication) or RPC in the remote case. Interoperability with OSI systems is gained by means of an OSI gateway that transforms NeL events into OSI events and vice versa. A NeL library for generating event notifications on DOS systems also is available.

OSF Distributed Management Environment Services

The application services offer enabling technology beyond that of the framework, providing higher-level services that enhance distributed systems management. Moreover, they are distributed, allowing for consistent management in heterogeneous environments. Each of the application services provide leading-edge enabling technology, delivering the necessary functionality to meet current requirements and designed to be extensible to meet future
requirements.

The specific management applications provided with the application services allow for the basic management of OSF's technologies. They make it easy for independent software vendors and system vendors to provide value-added management applications. In addition, they provide a proof-of-concept of the DME framework by making use of its functionality.

The application services and corresponding management applications addressed in the DME offering are

• Software Distribution and Installation Service and Management
• Distributed Print Service and Management
• Distributed License Service and Management
• Distributed Host Management.

The following sections describe the criteria used to select each of these application management services and provide an overview of each DME service offering.

SOFTWARE DISTRIBUTION AND INSTALLATION APPLICATION SERVICES

Selection Criteria

• Define software products. This definition describes the grouping of files that make up a product and specifies additional administrative information.
• Create software products on a development system. Utilities must be provided to construct distribution media according to a defined software product structure. This involves collecting the various parts that make up a product and bundling them into an interchangeable format.
• Distribute and store software products. The system must be capable of transferring software products using any form of distribution media. The technology should allow storage of any number or type of software products throughout the network in software product depot servers.
• Install software products. Customers must be able to specify the products and/or sub-products they want to install on any system(s). All necessary checks and customizations before and after the installation must be able to be performed automatically. The installation should be capable of being either interactive or unattended.
• Administer software products. The technology must provide the ability to manage updates and different versions of software products on the various systems that are controlled by the administrator as well as the management of the software storage. Information about the location of installed products and their history should be available.
• Provide for installation and updating of operating system software. From the administrator's point of view, there should be no distinction between operating system software and layered software products.
• Provide PC integration. Installing software on PCs depends on the user environment, which determines whether a product should be stored on a local PC disk or in a private or shared disk area on the supporting file server. A software distribution and installation application should be sufficiently flexible to support different PC environments.

Software Distribution and Installation Submissions

• DEC setld, Diskless Management Services (DMS) and Remote Installation Service (RIS) (Version 4 of each) from Digital Equipment Corporation.
• HP Software Distribution Utilities; part of a joint submission from Hewlett-Packard and IBM.
• SAX Software Administration for Open Systems, Release 3.0, from Siemens Nixdorf Information Systems.

The HP Software Distribution Utilities are part of a joint submission from Hewlett-Packard and IBM. These utilities are implemented using NCS(TM) 1.5.1, Hewlett-Packard's remote procedure call facility.

The utilities provide a compact set of commands to create, copy, install, list, and remove software products. They support both pushing and pulling models for distribution of software products. Monitoring and checking of the installation is carried out by a daemon process that communicates with the manager process and surveys the agent process installing the product on the target system.

SAX, the submission from Digital and Siemens Nixdorf, provides utilities for creating, distributing, and installing a software product. It provides tools for administering the storage of software in depots and archives and configures the mapping of product profiles to systems. The software is transferred in a product interchange file format and distributed by pushing it from software depots to agents. PCs based on DOS can pull the software from their supporting agent servers.

Selection Rationale

In addition, the submssions from Digital and Siemens Nixdorf do not support the two different software distribution approaches required by today's networked environments. Digital relies on a model in which software is requested from a server (the pull model), whereas Siemens Nixdorf technology requires sending software from the server to the target system (the push model). Moreover, unlike the Hewlett-Packard submission, neither product provides a graphical user interface to represent a distributed service. Thus, the Hewlett-Packard submission best meets the requirements for a distributed software management service.

• Of the three submissions, it best provides the flexibility needed to support different software distribution policies. Software products can be administered from any location. This allows software product installation to be pushed from a software depot to target systems, or pulled to a local system from a depot system.
• The implementation model of the HP SDU provides a distributed service. As a result, administrative tasks are not bound to dedicated systems, and services can be allocated to several systems -- for example, multiple software depot systems can reside in a network.
• Information about installed software products resides only on the target system and can be queried on demand. This provides consistency of management information, which should be co-located with the resource to which it refers.
• The managing system can act primarily as the supervisor and initiator of software management tasks. It is the responsibility of the target systems to determine the parts of the software products that need to be transferred, depending on information about installed software.
• The approach for installing operating system software is well designed. The HP SDU supports the notion of critical file sets for kernel building, which are loaded first, and supports the rebooting of systems.
• The HP SDU is a mature technology that has been ported to several operating system platforms. It is based on a client/server model providing an easy-to-use command line and graphical user interface.

The DME Software Distribution and Installation Offering

DISTRIBUTED PRINT APPLICATION SERVICE

Criteria for Distributed Print Systems

• The extent to which the technology provides for portability to different open system platforms
• The degree of support for the ISO Document Printing Application (DPA) standards, rapidly maturing standards that address the needs of sophisticated printing environment requirements
• Interoperability in heterogeneous environments
• The ability to support the wide range of sophisticated printer hardware and software technology available as well as new printer environments
• The degree to which the technology makes the benefits of distributed computing available to the print environment
• Extensibility to different print applications, queuing policies, and specific printer capabilities
• The ability for the technology to allow vendors to add value to support product differentiation while maintaining interoperability.

Print System Submissions

• OpenSpool/UX from Hewlett-Packard
• Palladium,(TM) version 2, from the Massachusetts Institute of Technology's (MIT) Project Athena, developed with Hewlett-Packard, Digital, and IBM
• Xprint, version 1.2, from Siemens Nixdorf Information Systems.

The Palladium, version 2, technology provides a second-generation printing system technology specifically designed to work in a distributed environment. It was designed in accordance with the emerging printing standards.

The Xprint version 1.2 technology provides a complete distributed print system solution. It aims for high reliability and recovery, ease of use, and flexible configuration.

Selection Rationale

OSF selected the MIT Palladium Print System, version 2. Palladium delivers a printing service that was designed with distribution in mind. It combines superior functionality with the flexibility and security needed in heterogeneous environments.

Palladium offers a superior enabling technology for open systems, meeting the requirements of end users, independent software vendors, and system vendors. It provides a comprehensive basis for building specific print system solutions for many print environments. OpenSpool/UX and Xprint, on the other hand, only provide solutions for a specific print environment. Xprint relies on distributed database services on clients and servers, which limits scalability and interoperability in large environments and wide area networks.

Palladium offers additional advantages.

• It was developed to conform with the Document Printing Application standards. The design provides a robust and extensible set of services and APIs. It affords tracking of the print application standards and proprietary enhancement without jeopardizing interoperability. This support is crucial for the ever-widening set of printers on the market. The ISO/IEC 10175 DPA standard likely will become an international standard in 1992. Palladium supports the ISO DPA style of specifying and validating objects, attributes, and values, which permits interoperability among diverse print systems based on the Palladium design. For example, print clients (such as applications using the print library) can access new facilities and features from print servers without updating client code.
• Explicit porting layers with well-defined internal interfaces exist for all external services. This isolation makes Palladium highly portable to a wide variety of environments. For instance, the print service interface layer isolates the specific underlying communications mechanism used. The current implementation uses DCE RPC (and related services) as the underlying communications mechanism; other implementations (e.g., using BSD sockets and NCS 1.0) also have been developed. In addition, the print service interface parameters follow the Abstract-Syntax-Notation-1 structures of the ISO DPA. This makes support for an ISO/OSI transport (ROSE) implementation straightforward, retaining the current call interface.
• Palladium was designed and is integrated with the services offered by RPC, security, naming, and threads of the OSF DCE.
• Palladium provides a powerful enabling technology allowing software vendors to add additional functionality beyond the reference implementation provided by OSF. Such technology could include new or enhanced scheduling policies, queuing designs, security services,
  user notification services, file transfer capabilities, document production services, and
  printer capabilities.
• Palladium uses a strict client/server model, allowing client applications to reside anywhere in a network, requiring only a communications mechanism to access servers. The architecture leaves open the possibility for local client access to configuration information (for example, by way of a distributed database), but does not depend on this capability. This allows for interoperation between different print system domains.
• The embedded task-oriented design of Palladium provides an implementation that can take advantage of a multi-threaded environment. In fact, Palladium has threads support for each embedded task, such as receiving requests and scheduling.
• Another important feature is the ability to take advantage of various file transfer methods so that documents can be transferred efficiently to the server. Palladium supports several methods, allowing documents to be transferred to the server by being pushed or pulled, or within the print request.

The DME Print System Offering

DISTRIBUTED LICENSE SERVICE

The next step in the evolution of licensing is distributed license management. License units are obtained dynamically at run time, which effectively separates licensing from having physical access to a copy of a software product. License units are supplied by a license server, a trusted entity, which is controlled through a license password issued by the software supplier.

Software licensing offers several benefits.

• Software vendors can tailor licensing business practices to meet the requirements of
  their customers.
• System administrators retain full control over when, where, and by whom the license units can
  be allocated.
• Revenues of software suppliers and their distributors are protected because applications are only used according to terms of their licensing agreements.
• Distribution of software by suppliers and within end-user organizations becomes easier
  to control.

Criteria for Distributed License Management Systems

• The amount of flexibility available to the software supplier and end user in the selection of the appropriate license modes or business practices (for example, allocative or consumptive licenses and license delegation)
• The degree of security available with each component of the management system and in the relationship between them (e.g., security of the license database, mutual authentication of clients and servers, and license checksums)
• The additional features available to the system manager and/or application developer (for example, license reservation, queuing for licenses, license status information, and logging)
• The availability of PC-based technology allowing PC applications to be included in an OSF DME distributed license management environment.

Distributed License Management Submissions

• DDSLA/PDLMF from Digital Equipment Corp. and Microsoft
• NetLS(TM) V2.0 from Hewlett-Packard and Gradient Technologies.

The Digital Distributed Software License Architecture (DDLSA) V2.0 is the company's second-generation software license management system architecture. The Portable Distributed License Management Facility (PDLMF) V1.0 is an implementation of DDSLA V2.0. It supports a very wide range of license modes, uses digital signatures on license tokens and provides for auditability.

The Network License System (NetLS) V2.0, developed by Hewlett-Packard, is a well-established distributed license management system. It is available on many open system platforms, both UNIX and non UNIX systems. Its main strengths are a wide range of business modes, strong security features and comprehensive management capabilities. Gradient Technologies submitted technologies that allow PC applications to be licensed through NetLS.

Selection Rationale

• NetLS is a proven, mature product that has been available on several heterogeneous operating system platforms. At the time of the laboratory evaluation, PDLMF was still under development, and substantial pieces of the DDSLA were not implemented or scheduled for availability in time to be included in an OSF DME offering. As a result, it did not meet the mandatory criterion of availability.
• The NetLS API provides the application developer with more control over license allocation (queuing) and in cases when licenses are becoming unavailable. Although this minimally increases the complexity of the API, the additional capabilities allow for more sophisticated feedback in the application.
• NetLS addresses PC integration through a full-function NetLS client library for PC application developers that communicates to a PC Ally server. This solution is applicable even to PCs with limited memory. The client library can be called directly by applications, or incorporated into "wrapper" front-ends or modules that allow licensing of existing, shrink-wrapped, unprepared PC applications.
• NetLS offers additional features like license queuing and comprehensive systems
  management tools.

The DME License Management Offering

HOST MANAGEMENT

The chosen technology handles both stand-alone systems and networked systems. The selection criteria provide for the addition, modification, and deletion of hosts in a network. The representation of hosts by host objects is independent of the underlying topology of the
network.

Host Management Submissions

• MIT Moira Service Management System is built around a relational database and provides centralized management of services.
• Tivoli WizDOM Host/User/Group/Subnet (HUGS) Services is an object-oriented, distributed system manager solution.
• UniSolutions SysAdmin(TM) performs administrative tasks by calling the application locally on the connected system.

Selection Rationale

• It provides distributed management, not bound to dedicated systems, and manages heterogeneous networks.
• All managed entities are modelled in an object-oriented way.
• The management of objects is facilitated by supporting management domains, i.e., collections of managed resources, and collection objects, which contain references to managed objects and can be organized hierarchically.
• Policy can be bound to managed objects in a management domain.
• The selection also provides both a command-line interface and a graphical user interface.

The DME Host Management Offering

PERSONAL COMPUTER INTEGRATION TECHNOLOGY

The DME personal computer integration technologies address systems based on the DOS operating system because their inherent architectural limitations -- for example, memory constraints and single tasking -- require an integration strategy different from systems based on more powerful operating systems. To take advantage of these DME components, PC systems must be equipped with the appropriate hardware and software to operate in a local
area network.

The DME personal computer integration offering will allow PC systems to participate in management activities on host systems. The services provided are

• Event forwarding
• Fault monitoring
• OS configuration management
• Software distribution
• Network licensing.

PERSONAL COMPUTER INTEGRATION SUBMISSIONS

• NCR Corp. submitted PC fault and configuration management technology with its PC Agent and DOS TSR implementation.
• Gradient Technologies submitted the NetLS PC Ally and PC client library. The rationale for the selection of this technology can be found in the section on Distributed Licensing Services.
• The Network Event Logger from Banyan Systems, which has been selected as the Event Management Service in the DME framework, provides a PC library that can be used in PC programs to filter and log events locally, and send them to a NeL server on another system, where they may get processed further.

Selection Rationale

OSF selected the Gradient Technologies PC Ally Communications Layer, the foundation layer of the PC Ally and PC client library for network licensing, to provide this crucial functionality. OSF will integrate the NeL PC library from Banyan Systems with the PC Ally Communication Layer.

Gradient will provide a PC Event Component, consisting of a TSR program running on the PC and an ally program running on a host. This PC Event Component will be integrated tightly with the DME Event Management Service, monitoring PC events and errors and handing them over to the NeL for further processing. There will be two versions of the PC Event Component, a sophisticated version that does filtering and logging locally on the PC, and a stripped-down version that exports events and errors to the ally to be handled there.

Gradient will deliver a PC Agent Component that provides to a remote PC systems manager a number of services, provided as a set of object methods, such as changing and listing of directories, file transfer, command execution and reboot. The agent must be started manually by the PC user on demand, but can be made to work as a background task in a Windows® 3.0 environment.

Gradient's implementation provides a better path for integration with the DME framework than the NCR PC Agent and DOS TSR, although the functionality of the submissions is equivalent. It also provides the potential for making additional DME services accessible from the PC.

The DME Personal Computer Integration Offering

Software distribution to PCs can be accomplished by distributing and installing software packages onto a DME based PC server with the DME Software Distribution and Installation Services. Applications then can be accessed from the PC or forwarded to the attached PCs through PC file-sharing technologies. PC configuration files can be modified subsequently through the file-transfer capabilities provided in the PC Agent Component.

Appendix A -- A Brief History of the DME RFT

OSF issued the Distributed Management Environment RFT on July 31, 1990. It distributed 5000 copies of the RFT, announced it in academic and trade publications, and posted it on numerous electronic bulletin boards. By September 21, OSF had received 42 letters of intent to submit technology.

Two weeks later, OSF hosted a meeting of technology submitters, Management SIG members, the DME evaluation team and consultants, and representatives of relevant standards bodies to review the initial evaluation criteria recommended to OSF by its management special-interest group (SIG), as well as executive summaries of all submissions. This meeting established equal opportunity for all DME RFT participants by making these criteria and technology summaries available to all the groups represented.

At the November OSF Member Meeting, in a dedicated DME Track, each submitting company was given the opportunity to present its technology to OSF membership and the OSF DME team and consultants. More than 250 people participated in the four days of review that included four panel discussions, 34 presentations by submitting companies, and informal discussions. Participants returned to their companies with questionnaires on the technologies presented and the scope of the DME. The deadline for full submissions was December 15, 1990. OSF received submissions from these organizations:

• Bolt, Berenek, Newman Communications Corporation
• British Telecom
• Dialogue Switching Technologies USA, Inc.
• Digital Equipment Corporation
• DSET Corp.
• Fraunhofer Gesellschaft
• Gradient Technologies
• Groupe Bull
• Hewlett-Packard Company
• IBM Corp.
• Legato Systems, Inc.
• Massachusetts Institute of Technology (Project Athena)
• Microsoft
• NCR (Network Products Division)
• NeXT Computer, Inc.
• Quality Software Products
• Quantum Gesellschaft fuer Software GmbH
• Sceptre Corp.
• Siemens Nixdorf Information Systems
• Stollmann GmbH
• Systar
• Tivoli Systems, Inc.
• Touch Communications, Inc.
• UniSolutions Associates
• Wang Laboratories

In February 1991, after careful analysis of the submissions, the DME evaluation team met with its consultants to review several initial proposals for an approach to a DME architecture and to discuss which submitted technologies might support it.

After this meeting, the team documented its ideas for the composition and functionality of the initial DME offering in a paper that was distributed to OSF members for review. On April 8 in Cambridge and April 11 in Munich, OSF met with technology submitters, industry consultants, and representatives of standards bodies. The group discussed this architectural vision paper and OSF received positive feedback on the direction the DME evaluation team had taken.

The laboratory phase of the RFT took place from mid-April through July 1991 in OSF's Munich office. During this time, the evaluation team conducted an in-depth review of the technology submissions, including code and documentation review, which resulted in OSF's decisions on the DME technology components.

On September 17, 1991, at press conferences in Boston, Paris, and Tokyo, OSF announced the selection of technologies that will comprise the DME offering, a comprehensive and cohesive management model consisting of a user interface, a management infrastructure with object and event services, application services, such as software licensing, installation and printer management, plus a host management facility.

THE DME EVALUATION TEAM

DME CONSULTANTS

• R. Scott Butler, E. I. DuPont Information Systems
• Daniel Geer, Digital Equipment Corporation
• Martin Kirk, X/Open; Chairman of IEEE POSIX 1003.7
• Professor Lindsay Marshall, University of Newcastle upon Tyne
• George Mouradian, AT&T Bell Labs
• Bruce Murrill, Network Management Forum
• David Passmore, Ernst & Young
• Karsten Prey, Diebold Deutschland
• Phil Shevrin, Locus Computing Corporation
• Daniel Stokesberry, National Institute of Standards Technology
• Hans Strack-Zimmermann, iXos Computer GmbH

DME EVALUATION TEAM

Dr. Andras Balazs

Kathryn Birkbeck

Martin Gosejacob

Jonathan Gossels

Steve Knight

Norbert Marrek

Dr. Franco Miralles

Michael Santifaller

Arno Schmidt

Hartmut Streppel

Appendix B -- The Open Process

The open process provides a level playing field that ensures every submitter equal opportunity to participate. OSF relies on that process to make decisions in an open, timely, vendor-neutral manner. The Request for Technology (RFT) process is one means OSF uses to evaluate and solicit technologies that may be incorporated in OSF offerings. OSF actively solicits member input in the preparation of the RFT as well as in the review of the proposals submitted. OSF's open process rests on four cornerstones:

• Member Special-Interest Groups (SIGs). Made up of experts from member companies, SIGs have a powerful voice in the open process, helping to define the scope and requirements for Requests for Technology as well as suggesting preliminary evaluation criteria.
• Open Technology Acquisition. Through the RFT process, OSF solicits and evaluates proposals from the worldwide computer industry as well as educational institutions, government agencies, and end users. All OSF members, submitters of technology, and other interested parties are invited to contribute ideas on technological and market needs as well as recommend evaluation criteria. At RFT review meetings, OSF accords nonmembers who have submitted proposals the same privileges members enjoy. Taking into consideration the recommendations of its membership as well as those of nonmember submitters, industry consultants, and standards groups (such as X/Open), OSF selects technology for use in its open computing environment.
• Member Meetings. OSF regularly meets with its membership to exchange ideas on open systems technology. In addition, members review proposals submitted through the RFT process and provide input to OSF evaluation team.
• Equal and Timely Access to Technologies under Review and Development. OSF's RFT and development processes provide members timely access to open systems technologies. Snapshots, copies of code still under development, enable members to evaluate the software, provide feedback to OSF, develop their own applications in parallel with the efforts of OSF, and port the software to their systems. OSF's snapshot program thus ensures rapid transfer of technology to the industry.

Appendix C -- The DME Request for Technology

User Requirement

Users need to manage an assortment of stand-alone and distributed systems in a coherent and cost-effective way. They require a consistent administrative approach and management tools, as well as facilities for managing distributed systems.

The user requirements present an opportunity for the open systems industry to work together to ease the cost and complexity of systems administration. They present an additional chance to bring into alignment system administration and network management technologies. The convergence of these two technologies will provide distributed system management.

Scope

Management Framework

In this model, the entities representing the system to be managed are called managed objects. They include system resources (such as devices and file systems), system services (such as mail and print services), network services (such as TCP/IP) and system users. These managed objects are accessed via common management services.

Common management services form the basis for the secure, distributed, and integrated management of systems, networks, and software applications. These services could include implementations of management communications protocols, event services, and access to management information. These components of a management framework provide an environment that supports management applications.

Management Applications

OSF will review technologies that address a distributed management environment and can be integrated with OSF's operating system, user environment, and distributed computing environment. Submissions that partially address the scope of this RFT, or provide alternate concepts, services, tools and utilities are welcome. The OSF Request for Technology process evaluates software technologies for inclusion in the OSF application environment.

What Is Not Covered In This RFT

Mandatory Requirements

Standards Conformity

The application programming interface must support applications written in ANSI-C and must not preclude other language bindings.

Portability

Documentation

Validation and Testing Support

Product Readiness

Reasonable and Equitable Licensing Terms

Key Evaluation Criteria

Qualifying submissions will be evaluated on

• Coherence and extensibility of the underlying management framework
• Scalability over a range of machine types, resource volumes, and network sizes
• Reliability in providing operation without loss of data or excessive downtime
• Security in allowing only authorized access to information and services
• Behavior in case of failure or overloading
• Provision for diagnostics, error detection, and recovery
• Diversity of supported machine architectures, networks, and operating system environments
• Conformity to relevant international and industry standards
• Provision for automated testing and quality metrics
• Quality and completeness of specifications, product documentation, and test suites
• Completeness of validation suites to ensure integrity of implementation against specification
• Adherence to good software engineering practices
• Support of national languages.

Evaluation Process and Milestones

• An Executive Summary of the proposal (1 to 3 pages)
• An overview of the technology architecture
• A discussion of the basic design philosophy
• A list of core services and applications provided by the submission
• A statement of your willingness to license the described technologies openly.

After the Letters of Intent have been received, OSF will distribute copies of the Executive Summaries and OSF's preliminary evaluation criteria to technology submitters and the OSF membership. OSF encourages submitters to review the Executive Summaries and identify areas in which their technologies complement other submissions.

All submitters are invited to participate in a workshop to review the preliminary evaluation criteria. This workshop is currently planned for the first week of October and will be held in Cambridge, Massachusetts.

An initial Technology Review meeting will be held during the Fall OSF member meeting (November 5-7, 1990) in Boston, Massachusetts. Submitters of qualifying technologies will be invited to present their technologies to the OSF membership at this meeting.

Full Submissions are due December 15, 1990.

A completed submission must contain the items listed below.

• A response to each mandatory requirement.
• A discussion of the technology relative to the key evaluation criteria.
• A copy of relevant functional and interface specifications, including the user interface, the programming interface, the protocol specification, and sample application source that demonstrates use of the technology.
• A discussion of the appropriate technical issues for each service such as management data representation, management information storage, management interfaces and protocols, and problem detection and recovery.
• Outline of proposed license and business terms. Final terms and conditions will be negotiated during the selection phase of the RFT.
• Any other materials that the submitter deems relevant to this evaluation process.

The OSF RFT process necessitates that technology submission materials be distributed broadly for review. Technology submitters agree to distribute copies of their proposal to OSF members, other technology submitters, relevant standards organizations, and other interested and informed organizations as directed by OSF.

Review Process

Following this Member Technology Review, OSF staff will evaluate the candidate technologies. This evaluation might include examination of source code, test suites, and documentation of the submission.

OSF expects to publicly announce the selected technologies along with the selection rationale in the first half of 1991. The OSF Distributed Management Environment technologies may be generally available by the end of 1991. The specific dates will depend on the number and complexity of technologies received. As with all RFT processes, OSF may combine elements of submissions to create a consistent, complete offering. OSF will make selections only if suitable technology is available.

OSF, OSF/1, Motif, and the OSF logo are trademarks and OSF/Motif is a registered trademark of the
Open Software Foundation, Inc.
BSD is a trademark of the University of California at Berkeley.
CONCERT is a trademark of British Telecom, Ltd.
DECmcc is a trademark of Digital Equipment Corporation.
ONC is a registered trademark of Sun Microsystems, Inc.
OMG and ORB are trademarks of the Object Management Group.
OpenView, NCS, and NetLS are trademarks of Hewlett-Packard Company.
Palladium and Moira are trademarks sof the Massachusetts Institute of Technology.
SysAdmin is a trademark of UniSolutions.
UNIX is a registered trademark of UNIX System Laboratories, Inc. in the United States and other countries.
Windows is a registered trademark of Microsoft Corporation.
WizDOM is a trademark of Tivoli Systems, Inc.

© Copyright 1991 Open Software Foundation, Inc.
All rights reserved. Printed in U.S.A.