INFORMATION TECHNOLOGY STANDARDS GUIDANCE

(ITSG)

(Part 9 of 14 parts)

SYSTEM MANAGEMENT SERVICES

 

 

 

 

 

 

 

 

Version 3.1 - April 7, 1997

 

 

AREA IPSC

DISTRIBUTION STATEMENT A: Approved for public release; distribution unlimited

TABLE OF CONTENTS

3.9 System management services 3.9-

3.9.1 State management 3.9-

3.9.1.1 Independent window management services 3.9-

3.9.1.2 System startup and shutdown 3.9-

3.9.1.3 Batch scheduling 3.9-

3.9.1.4 Process management and core operating system services 3.9-

3.9.1.5 System administration and management APIs 3.9-

3.9.1.6 Scheduling 3.9-

3.9.1.7 Subsystem management 3.9-

3.9.2 User and group management 3.9-

3.9.2.1 User/group identification 3.9-

3.9.3 Configuration control 3.9-

3.9.3.1 Software distribution 3.9-

3.9.3.2 Software configuration management 3.9-

3.9.3.3 Data dictionary 3.9-

3.9.3.4 Distributed directory services 3.9-

3.9.3.5 System configuration 3.9-

3.9.3.6 Network configuration management 3.9-

3.9.4 Usage monitoring and cost allocation 3.9-

3.9.4.1 Software license management 3.9-

3.9.4.2 Accounting management 3.9-

3.9.4.3 System resource limits 3.9-

3.9.5 Performance monitoring 3.9-

3.9.5.1 Software management indicators 3.9-

3.9.5.2 Performance management 3.9-

3.9.5.3 Network flow control 3.9-

3.9.5.4 Network sequencing 3.9-

3.9.5.5 Communication of management information 3.9-

3.9.5.6 Managed information base 3.9-

3.9.5.7 Event management 3.9-

3.9.5.8 Input/Output control 3.9-

3.9.6 Fault monitoring 3.9-

3.9.6.1 Software safety 3.9-

3.9.6.2 Database recovery 3.9-

3.9.6.3 Recovery and restart services for long running transactions 3.9-

3.9.6.4 Network error recovery 3.9-

3.9.6.5 Fault management 3.9-

3.9.6.6 Storage device management 3.9-

3.9.6.7 Backup and restore 3.9-

3.9.6.8 Hardware error and event conditions 3.9-

3.9.6.9 Event management 3.9-

3.9.6.10 Process checkpoint and restart 3.9-

3.9.6.11 Error and event logging 3.9-

3.9.7 Security monitoring 3.9-

3.9.7.1 System development 3.9-

3.9.7.2 Security management 3.9-

3.9.7.3 Security risk management 3.9-

3.9.7.4 Security audit 3.9-

3.9.7.5 Security alarm reporting 3.9-

3.9.7.6 Personal authentication 3.9-

3.9.7.7 Entity authentication 3.9-

3.9.7.8 System access control 3.9-

3.9.7.9 Network access control 3.9-

3.9.7.10 Certification and accreditation 3.9-

3.9.7.11 Detection and notification 3.9-

3.9.7.12 Security recovery 3.9-

3.9.7.13 Database security 3.9-

3.9.7.14 Security association and key management 3.9-

3.9.7.15 Registration of cryptographic techniques 3.9-

3.9.8 Other management services 3.9-

3.9.8.1 Database administration 3.9-

3.9.8.2 Object-oriented database management 3.9-

3.9.8.3 Floppy disk format and handling 3.9-

3.9.8.4 POSIX tape labeling and tape volume processing 3.9-

3.9.8.5 Print management 3.9-

3.9.9 Additional areas to be added 3.9-

LIST OF TABLES

3.9-1 Independent window management services standards 3.9-

3.9-2 System startup and shutdown standards 3.9-

3.9-3 Batch scheduling standards 3.9-

3.9-4 Process management and core operating system services standards 3.9-

3.9-5 System administration and management APIs standards 3.9-

3.9-6 Scheduling standards 3.9-

3.9-7 Subsystem management standards 3.9-

3.9-8 User/group identification standards 3.9-

3.9-9 Software distribution standards 3.9-

3.9-10 Software configuration management standards 3.9-

3.9-11 Data dictionary standards 3.9-

3.9-12 Distributed directory services standards 3.9-

3.9-13 System configuration standards 3.9-

3.9-14 Network configuration management standards 3.9-

3.9-15 Software license management standards 3.9-

3.9-16 Accounting management standards 3.9-

3.9-17 System resource limits standards 3.9-

3.9-18 Software management indicators standards 3.9-

3.9-19 Performance management standards 3.9-

3.9-20 Network flow control standards 3.9-

3.9-21 Network sequencing standards 3.9-

3.9-22 Communication of management information standards 3.9-

3.9-23 Managed information base standards 3.9-

3.9-24 Event management standards 3.9-

3.9-25 Input/Output control standards 3.9-

3.9-26 Software safety standards 3.9-

3.9-27 Database recovery standards 3.9-

3.9-28 Recovery and restart services for long running transactions standards 3.9-

3.9-29 Network error recovery standards 3.9-

3.9-30 Fault management standards 3.9-

3.9-31 Storage device management standards 3.9-

3.9-32 Backup and restore standards 3.9-

3.9-33 Hardware error and event conditions standards 3.9-

3.9-34 Event management standards 3.9-

3.9-35 Process checkpoint and restart standards 3.9-

3.9-36 Error and event logging standards 3.9-

3.9-37 System development standards 3.9-

3.9-38 Security management standards 3.9-

3.9-39 Security risk management standards 3.9-

3.9-40 Security audit standards 3.9-

3.9-41 Security alarm reporting standards 3.9-

3.9-42 Personal authentication standards 3.9-

3.9-43 Entity authentication standards 3.9-

3.9-44 System access control standards 3.9-

3.9-45 Network access control standards 3.9-

3.9-46 Certification and accreditation standards 3.9-

3.9-47 Detection and notification standards 3.9-

3.9-48 Security recovery standards 3.9-

3.9-49 Database security standards 3.9-

3.9-50 Security association and key management standards 3.9-

3.9-51 Registration of cryptographic techniques standards 3.9-

3.9-52 Database administration standards 3.9-

3.9-53 Object-oriented database management standards 3.9-

3.9-54 Floppy disk format and handling standards 3.9-

3.9-55 POSIX tape labeling and tape volume processing standards 3.9-

3.9-56 Print management standards 3.9-

3.9 System management services. Centralized system management services refer to services that allow systems and/or enterprises to be managed from a single, centralized point. Distributed system management services refer to services that allow systems and/or enterprises to be managed from any node in the enterprise, in a variety of ways. In some cases an enterprise may be managed as a single unit, but management tasks can be performed at any node. In other cases, the enterprise may be split into multiple domains, each having its own management system, but the different management systems can cooperate with each other and exchange and use each others' management information.

3.9.1 State management. This requirement states the need for a mechanism that initializes the system or components of the system, to a pre-determined state where it can operate in the distributed environment. Also required is the ability to shutdown all or part of the system gracefully for maintenance, security, or component upgrade reasons. Complementing startup, the ability to suspend, synchronize, or shutdown is also required. A less invasive mechanism of enroll/disenroll is needed to allow a component to be recognized or excluded from the distributed system while not directly affecting its operation.

3.9.1.1 Independent window management services. (This BSA appears both in part 3 and part 9.) Window management services are a necessary part of any windows system to perform functions such as resizing or moving windows. These services are not to be confused with services managing individual windows as though they were separate terminals.

3.9.1.1.1 Standards. Table 3.9-1 presents standards for independent window management services.

TABLE 3.9-1 Independent window management services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Modular Toolkit Environment (MTE)

1295:1993

Informational

(Approved)

CPC

OSF

Motif

Motif 1.2

Informational

(Approved)

CPC

MIT X Consortium

X Window System (Tab Window Manager)

X11R5

Informational

(Approved)

CPC

OSF

Motif

Motif 2.0

Informational

(Approved)

Motif 1.2 is the current version of the OSF specification for GUI behavior and appearance and programming and data interfaces. X11R5 is the current release of Version 11 of the X Windows GUI standard. The IBM Presentation Manager is included to support legacy systems.

3.9.1.1.2 Alternative specifications. The following specifications are also available for legacy support:

a. APIW
b. USL/Sun Open Look Windows Manager (olwm)
c. IBM SAA Presentation Manager Window Manager.

3.9.1.1.3 Standards deficiencies. Although all window managers perform functions such as window resizing and moving (window manipulation), some do not manage their windows independently, as if each window were a separate system. Failure to manage windows independently may create situations in which an application seizing in one window may propagate the errors to other windows causing them to seize (lock up). In addition, without an independent window manager, usually it is not possible to invoke programs that run in graphical mode at the same time (but in different windows on the same screen) as programs running in character mode. Certain windows systems running under single-tasking DOS also do not support independent window managers.

Motif 2.0 is somewhat incompatible with the multi-threading implementation in X11R6.

As no significant products are as yet available for Motif 2.0, the previous version, Motif 1.2, remains as the reference standard. Adoption of Motif 2.0 will be delayed until an appropriate threshold of Motif 2.0 products are available and until resolution of potential conflicts between Motif 2.0 and X11R6.

3.9.1.1.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.1.1.5 Related standards. No standards are related to independent window management standards.

3.9.1.1.6 Recommendations. A procurement should specify a Windows Manager that accommodates window manipulation and application seizure protection. Windows systems using X Windows operating on protected operating systems like UNIX are more robust (i.e., the failure of one application will not cause other applications to fail automatically) than some running on the unprotected DOS operating system.

3.9.1.2 System startup and shutdown. System startup and shutdown refers to a standardized method for starting up and gracefully shutting down a system without losing or corrupting data or code, and in the case of a multiuser system, giving users advance notification of the shutdown so that they can save their files and log off the system in time.

3.9.1.2.1 Standards. Table 3.9-2 presents standards for system startup and shutdown.

TABLE 3.9-2 System startup and shutdown standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.9.1.2.2 Alternative specifications. The following specifications are also available:

a. Berkeley BSD 4.3 UNIX.
b. System V Release 4.

3.9.1.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.1.2.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.1.2.5 Related standards. No standards are related to system startup and shutdown standards.

3.9.1.2.6 Recommendations. No specific standards are recommended at this time.

3.9.1.3 Batch scheduling. (This BSA appears both in part 8 and part 9.) Batch scheduling refers to the ability to submit jobs to be executed when the system load permits. The "at" command allows jobs to be executed at a predefined time. Batch queuing refers to the ability to place multiple jobs in a queue for processing, and to access and manage the queue.

3.9.1.3.1 Standards. Table 3.9-3 presents standards for batch scheduling.

TABLE 3.9-3 Batch scheduling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 2:Shell and Utilities - Amendment 1: Batch Environment

1003.2d:1994

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 15: Scheduling Function

10164-15:1995

Informational

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

3.9.1.3.2 Alternative specifications. The Berkeley BSD 4.3 Unix "at" and "batch" commands are also available.

3.9.1.3.3 Standards deficiencies. The POSIX.2 and Unix "at" and "batch" commands are designed for a single machine, centralized environment. Traditional POSIX and Unix batch capabilities, such as "at" and "batch," are inadequate and inefficient for managing resources and scheduling jobs in many environments, particularly environments that manage expensive resources, because they are very limited. For example, "at" allows users only to schedule machines to run jobs at particular times. No Ada bindings exist for the POSIX.2d Batch Queuing Extensions.

3.9.1.3.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.1.3.5 Related standards. No standards are related to batch scheduling.

3.9.1.3.6 Recommendations. The mandated standards are recommended, but both provide only limited batch functionality. For international work, use the POSIX.2 standard's new "-t time" option for the "at" command to express a time for execution of the submitted job in a way to support other time conventions more easily.

3.9.1.4 Process management and core operating system services. (This BSA appears in both part 8 and part 9.) Core operating system services are basic operating system services and interfaces, including traditional process management, memory management, time services, scheduling, terminal handling, error and exception management services, file-oriented services, and generalized input and output.

3.9.1.4.1 Standards. Table 3.9-4 presents standards for process management and core operating system services.

TABLE 3.9-4 Process management and core operating system services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) Amendment 2: Threads Extension [C Language]

1003.1c:1995

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

Test Methods for Measuring Conformance to POSIX - System Interfaces

2003.1:1992

Informational

(Approved)

NPC

IEEE

POSIX-Based Supercomputing Application Environment Profile

1003.10:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: Protocol Independent Interfaces

P1003.1g

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX Multiprocessor Application Environment Profile

P1003.14

Emerging

(Draft)

NPC

IEEE

POSIX Interactive Systems Application Environment Profile

P1003.18

Emerging

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.1.4.2 Alternative specifications. Other consortia or de facto alternative specifications (such as ECMA APIW) for the Portable Operating System Interface for Computer Environments (POSIX) standard P1003.1 are available.

3.9.1.4.3 Standards deficiencies. ISO 9945-1:1996 incorporated IEEE 1003.1b Realtime and IEEE 1003.1c Threads. This resolves some of the deficiencies in the original POSIX.1, but the following deficiencies remain in the available standards:

a. Lacks batch scheduling for distributed computing.

b. Has weak event, error, and exception management services.

c. Has weak or no generalized I/O device driver services.

d. Has reentry problems when used for multiprocessing.

e. Reliability and maintainability not reflected in the standard.

f. The tasking model on which Ada is based does not map well to the process model on which POSIX.1 is based.

g. Has tape handling facilities requiring long backup times.

3.9.1.4.4 Portability caveats. Different specifications and implementations conforming with POSIX (e.g., OSF/1, SVID, SVR4, X/Open, and vendor products) often support the same function, but support them slightly differently. For example, the names of system calls may be identical, but unanticipated incompatibilities will arise because of differences in the data types of the function, the data types of the arguments, the return values, the required header files, and the symbolic error values.

Implementations conforming with POSIX may require extra header files for function calls that are ported from a system not requiring header files to another requiring header files. Although the impact of requiring extra header files is not always clear, differences in header file requirements can reduce portability. For example, if a program is ported from a system not requiring a header file for a particular function call, to a system requiring it, the call to that function may be undefined and generate an error message about the nonexistent header file.

Differences within header files can reduce portability when moving from a system that does not require a header file to one that does. For example, a header file may define attributes like data types or symbols conflicting with locally defined symbols.

Implementations of systems conforming with POSIX may refer to devices by logical names, numeric indicators, data structures, or pointers. Superset functions in implementations conforming with POSIX are important to have and convenient to use, but they reduce portability.

The meaning of ownership of "symbolic links" is not clear or consistent across different systems. Only the meaning of owning a file is consistent.

Many system attributes, such as system limits and configuration values limits, are defined by implementation .

3.9.1.4.5 Related standards. The following standards are related to process management and core operating system services or their standards:

a. IEEE 1003.2:1992: POSIX - Shell and Utilities.

b. IEEE 1003.2a:1992: POSIX - User Portability Extension.

c. IEEE P1003.1e: POSIX - Security Interface Extensions.

d. IEEE P1003.21: POSIX - Real Time Distributed Systems Communications.

e. X/Open Common Desktop Environment (XCDE) - Definitions and Infrastructure.

3.9.1.4.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. IEEE 1003.1b (section 3) standardized additional functions not in 9945-1:1990 such as memory management and clocks and timers. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies many of the implementation-defined system limits related to files and directories and input/output.

To ensure maximum portability and smooth running information processing functions, it is important to determine, at a detailed level (e.g., arguments, order of the arguments, data types of the function and arguments, return values, symbolic error numbers), the specific areas of incompatibility between POSIX and the systems bid by vendors.

To ensure that no harm will result if an application is ported from a system that requires and supports a header file to a system that does not require the "include" statement in the system call, remove the header file from the application.

Avoid the use of extensions to POSIX. However, if extensions to POSIX must be used (they may be convenient), the applications in which they are used must be designed carefully for portability (e.g., separate the portable from the nonportable code, carefully document all nonportable code).

Including those header files required by POSIX.1 will ensure that properly written programs will build successfully on all FIPS-certified POSIX.1, regardless of which header files may be optional on a given vendor's platform.

Specifying that systems must conform to the X/Open's Single Unix Specification as demonstrated by a current X/Open Branding Certificate will eliminate the portability problems identified in the first paragraph of the portability caveats section.

3.9.1.5 System administration and management APIs. (This BSA appears in part 8 and part 9.) Operating system-based system administration standards provide interfaces to traditional, centralized operating system administration services and utilities. System management APIs refer to standardized Application Programming Interfaces that can be used by system and network managers and application developers to manage a system or network. They also are used to develop a system or network management application, without having to resort to writing third-generation language code or UNIX/POSIX shell scripts to perform the same functions on different machines. In this sense, system and network management APIs are considered productivity tools for system managers and system management application developers.

3.9.1.5.1 Standards. Table 3.9-5 presents standards for system administration and management APIs.

TABLE 3.9-5 System administration and management APIs standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Management Protocol Profiles (XMPP)

C206 (11/93)

Adopted

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

NPC

IEEE

Open Systems Interconnection (OSI) Abstract Data Manipulation - Application Program Interface (API) (Language Independent)

1224:1993

Adopted

(Approved)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 3: User and Group Administration

1387.3:1996

Informational

(Approved)

NPC

IEEE

POSIX System Administration - Part 1: Overview (formerly 1003.7)

P1387.1

Informational

(Draft)

NPC

IEEE

POSIX: System Administration - Part 4: Print Administration (former P1003.7.1)

P1387.4

Informational

(Draft)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.1.5.2 Alternative specifications. The following specifications are also available:

a. Groupe Bull: Consolidated Management Architecture (CMA), on which X/Open's XMP and OSF's CM-API are based.

b. Tivoli Systems: Objcall API, which is incorporated in MRB which is based on Tivoli. NOTE: A high-level API, such as the Tivoli Systems' "objcall" API is more suited for application development and integration than for management tasks such as long-term monitoring of system devices.

c. Tivoli Systems: Application Programming Interface (API) to objects.

d. Berkeley Unix.

e. OSF: OSF/1.

3.9.1.5.3 Standards deficiencies. All traditional Unix system administration is difficult. Neither System V system administration facilities nor Berkeley Unix system administration facilities were designed for a distributed networked environment. Traditional Unix system administration is not object-based and is not easily extendable.

3.9.1.5.4 Portability caveats. The traditional AT&T/USL system administration facilities are largely different from and incompatible with the traditional Berkeley Unix system administration facilities.

UI specifies the AT&T/USL system administration for the SVID. OSF provides the Berkeley Unix system administration facilities for OSF/1, except for the System V accounting facilities. The SVID and OSF/1 system administration interfaces, configuration files, and procedures are incompatible. Most of the shell scripts written for SVID-based Unix will not be portable to OSF/1 systems. The many system administration configuration files required by POSIX and Unix are not portable across different machines.

3.9.1.5.5 Related standards. The following standards are related to traditional operating system administration:

a. ISO IS 9595/9596/CCITT X.710/711: CMIS/CMIP (Common Management Information Service/Protocol).

b. ISO IS 7498:1986/CCITT X.700: Management Framework.

c. ISO IS 10040:1991: Systems Management Overview.

d. ISO IS 10164-1:1993/CCITT X.730: Object Management Function.

e. ISO IS 10164-2:1993/CCITT X.731: State Management Function.

f. ISO IS 10164-3:1993/CCITT X.732: Attributes for Representing Relationships.

g. ISO IS 10164-4:1992/CCITT X.733: Alarm Reporting Function.

h. ISO IS 10164-5:1993/CCITT X.734: Event Report Management Function.

i. ISO IS 10164-6:1993:Log Control Function.

j. ISO IS 10164-7:1992/CCITT X.736: Security Alarm Reporting Function.

k. ISO IS 10164-8:1993 Security Audit Trail Function.

l. ISO IS 10164-12:1994 Test Management Function.

m. ISO IS 10165-1:1993/CCITT X.720: Structure of Management Information.

n. ISO IS 10165-2:1992/CCITT X.721: Definition of Management Information.

o. ISO IS 10165-4:1992/CCITT X.722: Guidelines for the Definition of Managed Objects

p. ISO DIS 10181-2.2:1993: Authentication Framework.

q. ISO 8824:1990: (Edition 2) Specification of Abstract Syntax Notation 1 (ASN.1).

r. ISO 8825:1990: Specification of Basic Encoding Rules for ASN.1 (BER).

s. NIST FIPS 146-2: POSIT (for ASN.1 and BER (related to ISO 8824 and 8825)).

t. NIST FIPS 158-1: X Window System (X11 Version 5).

u. NIST FIPS 179-1: Government Network Management Profile (GNMP).

v. IEEE P1003.1e: Security Interface Standards for POSIX.

w. X/Open: G207:9/93: Systems Management Reference Model

x. X/Open: G303:9/93: Systems Management: Managed Object Guide (XMOG).

3.9.1.5.6 Recommendations. The PM should plan to use X/Open's XMPP as a common API to CMIP and SNMP. X/Open, Unix International, and OSF specify the same API, although they call them by different names (XMP and CM-API). The XMP and CM-API hide some of the differences between CMIP and SNMP and eliminate the need to learn two different syntaxes to access both protocols.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile.

3.9.1.6 Scheduling. (This BSA appears both in part 8 and part 9.) Scheduling services and interfaces provide different scheduling policies, such as time-sharing, priority-based, and user-defined. Scheduling services initiate and terminate jobs (programs) in the computer, maintain a list of jobs to be run, and allocate computer resources depending on priority. Each process is controlled by an associated scheduling policy and priority.

Priority and preemptive scheduling standards provide interfaces to scheduling services allowing the highest-priority process to run first and to completion. Preemptive multitasking shares processing time with all running programs. For example, background programs can be given recurrent CPU time no matter how heavy the foreground load. Priority bumping is the process during a link, trunk, or facility failure where lower priority user access to network services is interrupted to offer those services or bandwidth to a predesignated higher priority user.

3.9.1.6.1 Standards. Table 3.9-6 presents standards for scheduling.

TABLE 3.9-6 Scheduling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

GPC

NIST

POSIX Real Time Extensions

FIPS PUB (future)

Informational

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.1.6.2 Alternative specifications. There are no alternative specifications available.

3.9.1.6.3 Standards deficiencies. The POSIX.1 standard is not suitable for real time applications, because it supports only time-sliced time-sharing scheduling and does not allow scheduling based on the priority of a process.

The POSIX "nice" command for adjusting process priorities is not suitable for real time applications, because the "nice" function is merely a request to the operating system to favor a particular process for scheduling. However, in traditional Unix and POSIX.1, the effect of the "nice" command is tempered by degrading priorities based on CPU usage. In addition, the "nice" interface specifies an adjustment to a "nice" value, rather than setting it to an explicit value. Real time applications usually want to set priority to an explicit value. Finally, "nice()" does not allow for changing the priority of another process.

POSIX.1 scheduling is not based on absolute priorities. A process's scheduling priority degrades as it runs. POSIX.1 does not allow a system operator or real time application developer to tailor process scheduling.

POSIX.1b does not address the priorities of "system" processes. If system processes are not running in low priority ranges, conflicts with real time processes could result.

POSIX.1b does not address the interaction between priority and swapping because swapping and virtual memory paging-related issues are extremely dependent on the implementation and nearly impossible to standardize. However, the POSIX.1b scheduling paradigm fully describes the scheduling behavior of runnable processes, including the requirement for the working set to be resident in memory.

POSIX.1b does not address the temporary lending of priority from one process to another by the system (e.g., for the purposes of affecting the freeing of resources).

POSIX.1b does not define the effect of I/O interruptions and other system processing activities because the effect of I/O interruptions and system loading is intrinsically nondeterministic.

Influence levels (restrictions on a process's ability to affect other processes beyond a certain level) are defined by the implementation.

POSIX.1b does not address the mechanisms used to control access to scheduling facilities.

POSIX.1b does not address whether a process' handling of an event with a higher priority should have its priority boosted. This may be addressed later.

POSIX.1b provides a minimum of 32 priority levels. While this number conforms to the currently accepted scheduling theory requiring at least 32 priority levels for predictable responses with acceptable processor utilization, it is less than the 256 priority levels that many real time systems need.

3.9.1.6.4 Portability caveats. POSIX.1b supports a time-sharing scheduling policy, a real time scheduling policy, and a user-defined scheduling policy, but does not define the default scheduling policy. This could cause problems in porting the scheduling, and as a result, could cause problems in the response time behavior of real time applications.

POSIX.1b does not address resource preemption. The lack of resource preemption standardization could affect the ability to port real time applications so that they maintain the same behavior between systems. However, this does not affect source code portability, because resource preemption functions lie underneath the POSIX.1b interface.

The POSIX.1b priority-based scheduling functions are incompatible with the System V.4 SVID and SVR4 real time extensions' priority scheduling. The System V.4 "priocntl()" interface for priority scheduling violates POSIX.1b guidelines since it uses an argument to define the system call function. This increases the complexity of the "priocntl()" system call because it consolidates a large collection of related but logically separate functions into a single interface. Also, the "priocntl()" interface is less flexible than the POSIX.1b interface, because "priocntl()" does not permit separate disjointed or overlapping priority ranges between policies.

The specification of only 32 priority levels could reduce the behavior of some applications that depend on multiple priority levels to have reduced portability across conforming implementations.

In a conforming implementation, the priority ranges for the FIFO and Round Robin scheduling policies (SCHED_FIFO and SCHED_RR) defined in the header <sched.h> must be allowed to overlap, because these scheduling policies are identical except for the time interval. Because the third scheduling policy permitted by POSIX.1b (SCHED_OTHER) is defined by the user or implementation, any interactions among SCHED_OTHER and SCHED_FIFO or SCHED_RR also is defined by the implementation. Therefore, any application that depends on this interaction is not a strictly conforming application, and may not be portable across all systems.

3.9.1.6.5 Related standards. The following standard is related to priority and preemptive scheduling standards:

a. IEEE P1003.1e: Security Interface Standards for POSIX.

3.9.1.6.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. IEEE 1003.1b standardized additional functions not in the original POSIX.1. FIPS 151-2 specifies many of the implementation-defined system limits and chooses among incompatible POSIX options.

Each real time functionality in the POSIX.1b standard is an option. If procurements do not call out the POSIX.1b Execution Scheduling option explicitly, vendors may provide a system conforming with POSIX.1b but not including this option.

Procurements should require implementations to document the priority ranges in which system processes run to check that conflicts will not exist between system processes and real time processes.

If a particular default scheduling policy is desired, a procurement should either specify the default explicitly or specify the ability for system operators to define one.

System processes always should execute in low priority ranges to avoid conflict with real time processes.

A portable, standardized interface for locking portions of a process in memory is necessary to ensure that paging behavior does not affect the scheduling of real time processes.

An organization-wide standard default scheduling policy should be established. Also, applications should make no assumptions about the default scheduling policy.

Although the POSIX.1b real time standard allows source code portable applications to be written, it does not guarantee that two such applications can coexist in a single system. To minimize conflicts, developers should adhere to certain programming guidelines to document the intent, rather than the syntax, of the standardization issues.

3.9.1.7 Subsystem management. (This BSA appears both in part 8 and part 9.) Subsystem Management Service (SMS) is a product that controls the execution of system processes (usually daemons). It ensures that related processes are started (or stopped) in the proper sequence. It also provides a standard systems administration command syntax to start/stop these processes, and the specification for an RPC interface that could be embedded into daemons to allow administrator interaction. Without SMS, the commands to start these processes are embedded in the system startup file. There is no mechanism to ensure that one daemon is ready before starting a related one. To stop a daemon, the administrator needs to know the syntax of the appropriate command, and needs to know which other related daemons also need to be stopped. If a daemon dies, the administrator needs to know which related processes to stop, and the proper sequence to restart them.

3.9.1.7.1 Standards. Table 3.9-7 presents standards for subsystem management.

TABLE 3.9-7 Subsystem management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Management Environment (DME): Subsystem Management Service

DME SMS

Informational

(Not Recommended (No commercial products))

3.9.1.7.2 Alternative specifications. There are no alternative specifications available.

3.9.1.7.3 Standards deficiencies. There are no products currently using the OSF DME SMS specifications. The software available from the OSF could be used as-is, although it is intended to be used by third-party vendors as the basis for products.

There are also no daemons that implement the SMS RPC interface, except for the ones that come with OSF DME. Therefore the SMS is required to use Signals to stop daemons, which may have unpredictable results if the daemon does not catch the signal correctly.

3.9.1.7.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.1.7.5 Related standards. The following standard is related to subsystem management.

a. OSF DCE Remote Procedure Call (RPC)

3.9.1.7.6 Recommendations. There are no recommendations.

3.9.2 User and group management. This requirement states the need to establish identity by appropriate authentication means for a user prior to interaction with application software, establishing a session on an application platform, accessing information storage, or establishing communication. Coupled with this identification is the association of privilege, by individual or group and requisite resource authorization, potentially across multiple components of the system.

3.9.2.1 User/group identification. (This BSA appears both in part 8 and part 9.) User/group identification services provide traditional system administration interfaces for administering users and groups. These services are mechanisms for system and network administrators to use when implementing a management policy across a system. Administrators can use the services to establish domains and policies for management throughout the system. They can provide the ability for applications to access group and user databases. Users can set up their own areas of management and policies or use system defaults that are included in management services.

3.9.2.1.1 Standards. Table 3.9-8 presents standards for user/group identification.

TABLE 3.9-8 User/group identification standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

NPC

IEEE

POSIX: System Administration - Part 3: User and Group Administration

1387.3:1996

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Computer Security Guidelines for Implementing the Privacy Act of 1974

FIPS PUB 41:1975

Informational

(Approved)

GPC

NIST

Guidelines on Evaluation of Techniques for Automated Personal Identification

FIPS PUB 48:1977

Informational

(Approved)

3.9.2.1.2 Alternative specifications. The following specifications are also available:

a. Berkeley Unix: Centralized User and Group Management.
b. OSF/1 O.S.: Centralized User and Group Management.

3.9.2.1.3 Standards deficiencies. User and group management in the SVID, OSF/1, and Berkeley Unix is designed for a centralized, single machine environment. No Ada bindings exist for user and group management standards.

3.9.2.1.4 Portability caveats. System V Unix and the SVID use the commands "useradd" and "groupadd" to add a new user or group to the system. The OSF and Berkeley Unix use the commands "adduser" and "addgroup" to do the same thing.

Although the functionality defined by P1387.3 is based on historical user and group administration practice, no commercial products which conform to the (draft) standard are available as yet.

3.9.2.1.5 Related standards. The following standards are related to user and group management or user and group management standards:

a. ISO/IEC 9595:1991: CMIS.

b. ISO/IEC 9596:1991: CMIP.

c. ISO/IEC DIS 11578.2: RPC.

d. Network Management Forum: OMNIPoint 1.

e. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

f. Internet RFC 1157: Simple Network Management Protocol.

g. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

3.9.2.1.6 Recommendations. The mandated standards are recommended.

3.9.3 Configuration control. This requirement states the need to be able to manage the configuration of the system. This entails the ability to view the current configuration statically and dynamically modify the configuration, and the ability to tune the system.

3.9.3.1 Software distribution. (This BSA appears both in part 2 and part 9.) Software distribution and installation services comprise utilities for packaging, installing, and distributing software for use on heterogeneous and potentially incompatible systems. These services will enable network managers to transmit software to any stand-alone or networked system, regardless of the media used for distribution. Standards for software distribution in a system provide a standardized layout for distributing and installing software in a single system or network. They explicitly define each phase of software distribution, installation, and configuration--covering such distribution media as disks, tapes, and CD-ROM.

3.9.3.1.1 Standards. Table 3.9-9 presents standards for software distribution.

TABLE 3.9-9 Software distribution standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Adopted

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170)

T908: 1995

Emerging

(Approved)

CPC

X/Open

Systems Management: Distributed Software Administration (XDSA)

P429:1997

Informational

(Approved)

3.9.3.1.2 Alternative specifications. The following specifications are also available:

a. Hewlett-Packard: "swinstall" and "swpackage" systems.
b. USG: SVR4-based "pkgadd" system.
c. Santa Cruz Operation (SCO): "custom+" system.

3.9.3.1.3 Standards deficiencies. The IEEE 1387.2 standard does not provide for acting upon log files in remote file systems. No Ada bindings are available for software distribution standards.

3.9.3.1.4 Portability caveats. Although the IEEE 1387.2 standard is based on Hewlett-Packard's "swinstall" and "swpackage" systems, the standard has modified the specifications so that they are not exactly like the HP systems.

3.9.3.1.5 Related standards. The following standards are related to software distribution or software distribution standards:

a. ISO/IEC JTC1 IS 9595:1991: Common Management Information Service (CMIS).

b. ISO/IEC JTC1 IS 9596:1991: Common Management Information Protocol (CMIP).

c. ISO/IEC IS 11578: 1996, Information Technology - Open Systems Interconnection - Remote Procedure Call (RPC).

d. Internet RFC 1155 (STD 17): Structure and Identification of Management Information for TCP/IP-based Internets.

e. Internet RFC 1157 (STD 15): A Simple Network Management Protocol.

f. Internet RFC 1213 (STD 17): Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

g. Network Management Forum: OMNIPoint 1.

3.9.3.1.6 Recommendations. IEEE 1387.2 is recommended.

A new version of the X/Open Single UNIX Specification (Spec. 1170) is expected to be issued in 1997.

3.9.3.2 Software configuration management. (This BSA appears both in part 2 and part 9.) Configuration management is the process of applying administrative and technical procedures throughout the software life cycle to identity, define, and baseline configuration items for software in a system; control modifications and releases of the items; record and report the status of the items and modification requests; ensure the completeness and correctness of the items; and control storage, handling, and delivery of the items. This includes activities employed by the developer to identify entities (such as computer files, documents, Computer Software Configuration Items) whose version and status are to be tracked and controlled, to apply such controls, to keep records of these controls, and to audit that these controls are being applied.

3.9.3.2.1 Standards. Table 3.9-10 presents standards for software configuration management.

TABLE 3.9-10 Software configuration management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

NPC

EIA

National Consensus Standard for Configuration Management

IS-649

Adopted

(Approved)

NPC

ANSI/IEEE

Software Configuration Management

1042:1987

Informational

(Approved)

NPC

ANSI/IEEE

Software Configuration Management Plans

828:1990

Informational

(Approved)

GPC

NIST

Guideline for Software Documentation Management

FIPS PUB 105:1984

Informational

(Approved)

GPC

DOD

Configuration Management

MIL-STD-973(I3): 1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

MIL-STD-498, Software Development and Documentation has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service.

3.9.3.2.2 Alternative specifications. The following additional guidance document is also available: Guidelines for Configuration Management (MIL-HDBK-761), although it is used with MIL-STD-973(I3): 1995, which will most likely be canceled.

3.9.3.2.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.3.2.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.3.2.5 Related standards. None.

3.9.3.2.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

3.9.3.3 Data dictionary. (This BSA appears in part 4 and part 9.) A data dictionary is a part of a database management system that transparently provides a centralized meaning, relationship to other data, origin, usage, and format. It also indicates which application programs use that data, so that when a change in a data structure is contemplated, a list of affected programs can be generated. The data dictionary a stand-alone system or may be an integral part of the DBMS and used to control it. Data integrity and accuracy is better ensured in the latter case.

3.9.3.3.1 Standards. Table 3.9-11 presents standards for data dictionary.

TABLE 3.9-11 Data dictionary standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Information Resource Dictionary System (IRDS) (adopts ANSI X3.138-1988 and X3.138A-1991)

FIPS PUB 156:1989

Adopted

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Framework

10027:1990

Informational

(Approved)

GPC

NIST

Guide for the Development, Implementation, and Maintenance of Standards for the Representation of Computer Processed Data Elements

FIPS PUB 45:1976

Informational

(Approved)

GPC

NIST

Guidelines for Planning and Using a Data Dictionary System

FIPS PUB 76:1980

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS)

X3.138-1988

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS) Services Interface

X3.185-1992

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS) Export/Import File Format

X3.195-1991

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface

10728:1993

Informational

(Approved)

CPC

Metadata Coalition

Metadata Interchange Specification (MDIS)

MDIS 1.0:1996

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 1: C Language Binding

10728 AMD 1:1994

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Export/Import Support for SQL:1989 with Integrity Enhancement

JTC1/SC21/WG03 Nxxx

Informational

(Formative)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Design Support for SQL Applications

JTC1/SC21/WG03 Nxxx

Informational

(Draft)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 2: Ada bindings (binding for Ada-83)

10728 WDAM 2:1993(E)

Informational

(Draft)

3.9.3.3.2 Alternative specifications. No applicable consortia or de facto specifications for the data dictionary are available.

3.9.3.3.3 Standards deficiencies. The following deficiencies have been identified in the available standards:

a. APIs with the IRDS are not currently defined.

b. There are no IRDS bindings to Ada.

c. IRDS does not support the development of active functionality.

d. IRDS does not support object-oriented data structures. An upcoming major IRDS revision is expected to add support for object-oriented data structures and communications between data management tools. Computer Aided Software Engineering (CASE) tool proponents are lobbying for this revision.

e. IRDS does not support information communications among data management tools.

f. IRDS conformance tests do not exist, although they are being developed.

g. While DOD 8320.1-M-1 Data Element Standardization Procedures, January 1993, provides procedures for the approval and maintenance of data elements. The standard governing the design, definition, and naming rules for data elements comes from Integration Definition for Information Modeling (IDEF1X), Corporate Information Management Process Improvement Methodology for DOD Functional Managers (1992). This has been adopted as FIPS 184.

h. There are no implementations.

3.9.3.3.4 Portability caveats. The ANSI and ISO services interface standards have diverged and are not compatible. All attempts to converge these standards have failed because the ANSI and ISO IRDS specifiers have different data dictionary interests. As a result, the ISO model is geared toward developing an underlying interface between the dictionary and the DBMS. U.S. Federal agencies, the NIST, and ANSI focus on user interfaces.

One example of how ANSI and ISO IRDS diverge is concerned with whether or not relationships are permitted to have attributes. ISO says no, on the grounds that its simpler model, without attributes, is more easily integrated with SQL tables. ANSI says yes, claiming that even though a model permitting attributes is more complex and difficult to use, it provides greater flexibility for more IRDS users. People using IRDS for system planning processes, for example, might need to store certain items in the dictionary that would not necessarily be applicable for interfacing with DBMSs.

3.9.3.3.5 Related standards. The following standards are related to data dictionaries or data dictionary standards:

a. International Telecommunications Union - Telecommunications Standards Sector (ITU-T) (formerly International Telegraph and Telephone Consultative Committee (CCITT))/ISO X.500: Directory Services

b. Standard Textual Language (STL): IEEE 1175 (particularly for use with CASE tools)

c. Many CASE tools, because the IRDS acts as a focus for sharing data and metadata and can be applied to them.

d. NIST FIPS 183: IDEF0

e. NIST FIPS 184: IDEF1X

f. Data element standards in the data dictionary BSA, above.

3.9.3.3.6 Recommendations. IRDS, FIPS 156, is recommended. Most computer vendors claim that they are committed to IRDS, but few have it now. If specific IRDS documents are not specified explicitly in a procurement, vendors most likely will propose products that are not compatible with IRDS.

If a procurement is targeted at a traditional database environment and a simpler-to-use IRDS is desirable, consider the ISO specification. If other environments are at stake and attributes on relationships, or many-to-many relationships are needed to represent the relationships between hardware and programs, as well as between programs and data, then choose FIPS 156 IRDS and use ANSI IRDS wherever FIPS 156 has not specified certain capabilities. Whether the choice is for ISO, ANSI, or FIPS IRDS, be prepared to lock yourself in for other procurement, rather than mixing ISO and ANSI IRDS because of the incompatibilities.

3.9.3.4 Distributed directory services. (This BSA appears in part 4, part 9, and part 11.) A directory or naming service provides a standardized naming scheme, a standardized interface with the naming facilities, and the ability for the interface to provide transparent access to a variety of naming schemes and mechanisms (e.g., DCE).

Directory service applications convert a name into a physical address on a network, providing logical to physical conversion. Names can be user names, computers, printers, servers, or files. This enables users to find these resources without knowing their locations. The transmitting station sends a name to the server containing the naming service software, which sends back the actual address of the user or resource.

3.9.3.4.1 Standards. Table 3.9-12 presents standards for distributed directory services.

TABLE 3.9-12 Distributed directory services standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Directory (Global and Cell) Service

DCE 1.1 Directory:1994

Mandated

(Approved)

IPC

ISO

Open Systems Interconnection-Session Service Definition

8326:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Session Protocol

8327:1987

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Basic Connection Oriented Presentation Service Definition

8822:1988

Informational

(Approved)

IPC

ISO

Open Systems Interconnection-Connection-Oriented Presentation Protocol

8823:1988

Informational

(Approved)

IPC

ITU-T

The Directory: Models (X-ref: ISO 9594-2)

X.501 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Authentication Framework (X-ref: ISO 9594-8)

X.509, Version 3: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Abstract Service Definition (X-ref: ISO 9594-3)

X.511 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Procedures for Distributed Operation (X-ref: ISO 9594-4)

X.518: 1993

Informational

(Approved)

IPC

ITU-T

The Directory: Protocol Specification (X-ref: ISO 9594-5)

X.519 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Attributes Types (X-ref: ISO 9594-6)

X.520 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Selected Object Classes (X-ref: ISO 9594-7)

X.521 (1993)

Informational

(Approved)

IPC

ITU-T

The Directory: Replication (X-ref: ISO 9594-9)

X.525 (1993)

Informational

(Approved)

CPC

X/Open

Federated Naming: The XFN Specification

C403 (7/95)

Informational

(Approved)

NPC

IEEE

Directory services/Name space API

1224.2:1993

Informational

(Approved)

GPC

DOD

Domain Name Service Profile (References IAB STD 13 (RFC 1034, 1035))

MIL-STD-2045-17505:1994

Informational

(Approved)

3.9.3.4.2 Alternative specification. There are no alternative specifications available.

3.9.3.4.3 Standard deficiencies. Deficiencies in the existing specifications are unknown.

3.9.3.4.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.3.4.5 Related standards. There are no related standards.

3.9.3.4.6 Recommendations. OSF DCE directory services are recommended for DCE applications. For more information on non-DCE directory services, see the Host Application Support BSA in part 7, Communication Services.

3.9.3.5 System configuration. (This BSA appears both in part 8 and part 9.) System configuration services is a representation of the components and component parameters of a computer system (e.g., memory boards, amounts of memory, memory addresses, particular interrupts, networks, network addresses, and specific peripherals such as keyboards, disk drives, terminals, mice or other input devices, and specialized instruments). Clearly, every computer must have a way to do this. System configuration also refers to the automation of this procedure (i.e., automated system configuration) and the ability to configure the system on-line. On-line configuration refers to the ability for system administrators to make dynamic configuration changes, while users are working on-line, rather than having to take the system down.

3.9.3.5.1 Standards. Table 3.9-13 presents standards for system configuration.

TABLE 3.9-13 System configuration standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 1: Object Management Function

10164-1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 2: State Management Function

10164-2:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 3: Attributes for Representing Relationships

10164-3:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 12: Test Management Function

10164-12:1994

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

3.9.3.5.2 Alternative specifications. No other consortia or de facto specifications are available.

3.9.3.5.3 Standards deficiencies. The present ISO 10164-3, "Attributes for Representing Relationships," and 10164-12, "Test Management Function," standards were designed with network configuration in mind. Theoretically, these standards should be able to be used for configuration management of any computer system. Until now, very little work has been done in this area, either in standards groups or in products. Exactly how these standards should be used in host management is undetermined.

Versions 1.0 and 2.0 of the GNMP specify only network management capabilities. Not until Version 3.0 is available will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems management, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols. Plans are for the GNMP to provide a capability to integrate the present GNMP with SNMP also. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for the configuration management standards or consortia specifications.

3.9.3.5.4 Portability caveats. Unknown

3.9.3.5.5 Related standards. The following standards are related to system configuration or system configuration standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: File Transfer, Access, and Management (FTAM), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: ACSE, as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the Network Management SIG (NMSIG) agreements in Part 18 of the OSI Implementors' Workshop (OIW) Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: Remote Operations Service Element (ROSE), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: CMIS.

i. ISO/IEC 9596:1991: CMIP.

j. ISO/IEC 10165-1:1993: Structure of Management Information (SMI).

k. ISO/IEC 10165-2:1992: Definition of Management Information (DMI).

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: Remote Procedure Call.

n. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

o. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

p. Comite Consultatif International de Telegraphique et Telephonique (CCITT) X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: C315:5/94: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.9.3.5.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

To build or procure configuration management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various ISO 10164 and 10165 standards whose specifications are related to these requirements. Finally, they must include their explicit requirements and the related standards in the RFP.

3.9.3.6 Network configuration management. Network configuration management defines the procedures for initializing, operating, and closing down the managed objects, and the procedures for reconfiguring the managed objects.

3.9.3.6.1 Standards. Table 3.9-14 presents standards for network configuration management.

TABLE 3.9-14 Network configuration management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

3.9.3.6.2 Functionalities supported. This network service supports the Network Management functionality.

3.9.3.6.3 Related network services. Addressing is related to this network service.

3.9.3.6.4 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.9.3.6.5 Recommendations. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile.

3.9.3.6.6 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.4 Usage monitoring and cost allocation. Services that allow monitoring of system usage, allocation of resources, and assessment of charges to users.

3.9.4.1 Software license management. (This BSA appears in both part 2 and part 9.) License management addresses the problem of tracking software licenses in a distributed systems environment. The DME licensing technology includes models that assist users in keeping track of how many software copies are needed and who is using it once it is purchased. Software license management for a system provides license administration, monitoring, and enforcement services that allow more detailed, firm and equitable licensing terms for users, and better protection against illegal software usage for vendors.

3.9.4.1.1 Standard. Table 3.9-15 presents standards for software license management.

TABLE 3.9-15 Software license management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Adopted

(Approved)

CPC

X/Open

Systems Management: Distributed Software Administration (XDSA)

P429:1997

Informational

(Approved)

CPC

OSF

Distributed Management Environment (DME): License Management (LM) Service

DME LM

Informational

(Historic (Not recommended))

3.9.4.1.2 Alternative specification. The following specifications are also available:

a. Hewlett-Packard: Network License System (NetLS) Version 2.0 on which OSF's DME License Management System (LS) is based.

b. Gradient Technologies: PC Client libraries for license management and PC Ally server, on which DME's License Management PC component is based.

3.9.4.1.3 Standard deficiencies. No Ada bindings exist for any of the configuration management standards or consortia specifications.

3.9.4.1.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.4.1.5 Related standards. The following standards are related to license management or license management standards:

a. ISO/IEC JTC1 IS 9595:1991: Common Management Information Service (CMIS).

b. ISO/IEC JTC1 IS 9596:1991: Common Management Information Protocol (CMIP).

c. ISO/IEC IS 11578: 1996, Information Technology - Open Systems Interconnection - Remote Procedure Call (RPC).

d. Internet RFC 1155 (STD 17): Structure and Identification of Management Information for TCP/IP-based Internets.

e. Internet RFC 1157 (STD 15): A Simple Network Management Protocol.

f. Internet RFC 1213 (STD 17): Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

g. Network Management Forum: OMNIPoint 1.

3.9.4.1.6 Recommendations. IEEE 1387.2 is recommended.

3.9.4.2 Accounting management. (This BSA appears in part 8 and part 9.) Accounting management services provide the ability to cost services for charging and reimbursement. An effective cost management system should contribute to the development of a sound investment strategy that recognizes and evaluates cost and alternatives. The services should also provide for the ability to measure and prioritize resource usage and to monitor assets and maintain costing records for chargeback purposes. Costs of information technology services should be capable of being apportioned to users, and reports of those costs should be capable of being provided to management and customers.

3.9.4.2.1 Standards. Table 3.9-16 presents standards for accounting management.

TABLE 3.9-16 Accounting management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Systems Management, Part 10: Usage Metering Function for Accounting Purposes

10164-10:1995

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 13: Summarization Function

10164-13:1995

Adopted

(Approved)

GPC

NIST

Guideline for Developing and Implementing a Charging System for Data Processing Services

FIPS PUB 96:1982

Adopted

(Approved)

3.9.4.2.2 Alternative specifications. The following specifications are also available:

a. OSF/1 O.S.: Centralized Accounting Mgmt.
b. Berkeley BSD 4.3 Unix.

3.9.4.2.3 Standards deficiencies. A variety of different chargeback systems are using different metrics and methods that are causing compatibility problems within agencies and services. The Unix accounting functions are designed for a single machine environment.

The present ISO 10164-10, "Accounting Metering Function," and 10164-13, "Summarization Function," standards were designed with a networked system configuration in mind. Little work has been done in standards groups or products to determine how to use these standards for host configuration management.

Although several standard libraries of object classes that allow a common view of network resources are planned, few are currently available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections.

The ISO standards require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols, and do not interoperate with TCP/IP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

3.9.4.2.4 Portability caveats. OSF/1 uses the System V Unix accounting facilities. Although the OSF/1 and System V accounting systems differ, and each operating system has extra accounting functions, the use of the same accounting facilities eliminates one source of incompatibility.

3.9.4.2.5 Related standards. The following standards are related to accounting management or accounting management standards:

a. ISO/IEC 7498:1986: Management Framework.

b. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: ACSE, as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990 (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: ROSE, as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991 CMIS.

i. ISO/IEC 9596:1991 CMIP.

j. ISO/IEC 10165-1:1993: SMI.

k. ISO/IEC 10165-2:1992: DMI.

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: RPC.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for Internets based on TCP/IP.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1213: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. Network Management Forum: OMNIPoint 1.

v. X/Open: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.9.4.2.6 Recommendations. To build or procure account management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications within the ISO 10164 and 10165 standards that are related to these requirements. Finally, they must explicitly include the requirements and the related standards in the RFP.

In the future, the NIST plans to provide a capability in the GNMP to integrate the present GNMP with SNMP.

3.9.4.3 System resource limits. (This BSA appears both in part 8 and part 9.) Resource limits functionality allows system administrators to control the amount of system resources available to users.

3.9.4.3.1 Standards. Table 3.9-17 presents standards for system resource limits.

TABLE 3.9-17 System resource limits standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Adopted

(Approved)

NPC

IEEE

POSIX-Based Supercomputing Application Environment Profile

1003.10:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API, Amendment x: Resource Limit Interface (C Language)

P1003.1p

Emerging

(Formative)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.4.3.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.3 Unix.
b. Cray Research, Inc.: "limits" interfaces.
c. OSF: OSF/1 Operating System: "getrlimit/setrlimit."

3.9.4.3.3 Standards deficiencies. The Berkeley Unix and System V "setrlimit" and "ulimit" interfaces have the limitation that users may act only to make their limits more restrictive.

3.9.4.3.4 Portability caveats. The actual numeric limit values for different resource limits are not portable across various platforms. Applications need to provide some sort of configuration parameters to specify the actual numeric values for each site.

3.9.4.3.5 Related standards. The following standards are related to resource limits or resource limit standards:

a. ISO/IEC 9945-1:1996: POSIX.1 System Application Programming Interfaces.

b. IEEE P1003.1e: Security Interface Standards for POSIX.

c. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

d. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

3.9.4.3.6 Recommendations. X/Open Single Unix Specification (SUS) provides "setrlimit/getrlimit" functionality.

3.9.5 Performance monitoring. Performance monitoring services allow information technology resources to be managed efficiently. Performance aspects of hardware, software, and network components must be monitored and subsequently made available to the system manager. The manager must then have access to services and parameters with which to tune the system to meet performance targets.

3.9.5.1 Software management indicators. (This BSA appears both in part 2 and part 9.) Software management indicators aid in managing the software development process. Various measurements of both software products and software processes are available. Product measures(such as lines of code, function points, etc.) are often associated with the product specification and should be used as management indicators throughout the product life cycle. Process measures(such as software trouble reports) should be tracked to determine whether the software development process is within statistical control limits. Key indicators should be identified in the software development plan, and the developer should then collect, analyze, interpret, take corrective actions, and report on the selected key management indicators.

3.9.5.1.1 Standards. Table 3.9-18 presents standards for software management indicators.

TABLE 3.9-18 Software management indicators standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Adopted

(Approved)

IPC

ISO/IEC

Quality Characteristics and Guidelines for Their Use

9126:1991

Adopted

(Approved)

NPC

IEEE

Use of Standard Measures to Produce Reliable Software

982.2:1988

Informational

(Approved)

NPC

IEEE

Standard Dictionary of Measures to Produce Reliable Software

982.1:1988

Informational

(Approved)

NPC

IEEE

Software Productivity Metrics

1045:1992

Informational

(Approved)

NPC

IEEE

Software Quality Metrics Methodology

1061:1992

Informational

(Approved)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

MIL-STD-498, Software Development and Documentation has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service.

3.9.5.1.2 Alternative specifications. For additional metrics information, consult the following documents:

a. Metrics for I-CASE Pilot Project (MIPP) Program, Metrics Reporting Guidebook, (prepared by Mitre Corporation, 27 May 1994, for DISA/JIEO/CIM/TXEM).

b. Practical Software Measurement: A Guide to Objective Program Insight, Draft 12 April 1995.

c. Streamlined Integrated Software Metrics Approach (SISMA) Guidebook; Application of STEP Metrics, (prepared by Software Productivity Solutions, Indialantic, FL 32903, 12 July 1993, for the U.S. Army).

d. Software Measurement Guidebook, (prepared by the Software Productivity Consortium Services Corporation, December 1992, Herndon VA, for DARPA).

3.9.5.1.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.5.1.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.5.1.5 Related standards. Related software management guidance can be found in the Software Engineering Institute's Capability Maturity Model (CMM). The Software Engineering Institute's CMM provides guidance on how to gain control of the software development and maintenance processes. The CMM has defined an evaluation procedure, the CMM Based Appraisal (CBA), as a means of identifying the risks associated with potential contractor performance. Diagnostic tools based on the CMM have been deployed. One of those tools, the Software Capability Evaluation(SCE), is designed to be used by an acquiring organization to either identify process risks associated with a particular proposal during the source selection or to monitor the risk-reducing process improvements during the contract execution.

3.9.5.1.6 Recommendations. The adopted standards are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. MIL-STD-498 contains requirements for security and privacy for software development and documentation. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service policy, until organizational processes for IEEE/EIA 12207US are in place.

For other related information, consult ISO/IEC 9126. Appropriate standards should be selected based on software metrics requirements.

3.9.5.2 Performance management. (This BSA appears in part 8 and part 9.) Performance management provides services and interfaces for tuning systems and subnetworks to meet individual performance requirements. Performance management enables the behavior of resources and the effectiveness of communication activities to be evaluated. It includes functions to: gather statistical information; maintain and examine logs of system state histories; determine system performance under natural and artificial conditions; and alter system modes of operation for the purpose of conducting performance management activities. Performance management may make use of event management facilities.

3.9.5.2.1 Standards. Table 3.9-19 presents standards for performance management.

TABLE 3.9-19 Performance management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NIST

Data Communications Systems and Services -User Oriented Performance Parameters (adopts ANSI X3.102-1983/R1990)

FIPS PUB 144:1985

Adopted

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 11: Metric Objects and Attributes

10164-11:1994

Informational

(Approved)

GPC

NIST

Guideline on Computer Performance Management: An Introduction

FIPS PUB 49:1977

Informational

(Approved)

GPC

NIST

Guidelines for the Measurement of Interactive Computer Service Response Time and Turnaround Time

FIPS PUB 57:1978

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

GPC

NIST

Guidelines for Measurement of Remote Batch Computer Service

FIPS PUB 72:1980

Informational

(Approved)

3.9.5.2.2 Alternative specifications. No other consortia or de facto specifications are available.

3.9.5.2.3 Standards deficiencies. The present 10164-11 ("Workload Monitoring Function) and generic 10165-xx standards were designed with network configuration in mind. Theoretically, they should be able to be used for configuration management of any computer system. Little work has been done in this area, either in standards groups or in products. Exactly how these standards should be used in host management is undetermined. Standards for system performance measurement are needed.

Although several standard libraries of object classes that allow a common view of network resources and support performance management of network resources are planned, few are currently available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections. Based on needs of the U.S. Federal Government (as shown by NIST surveys), the GNMP added more object class specifications and definitions. These include the following objects: LANs, X.25 WANs, ISDN, FDDI, modems, bridges, links, and a rudimentary capability to manage OSI routers and transport connections. Phase 2 GNMP objects also will include protocol software (layers 3-7), routers, terminal servers, MTAs, PBXs, and circuit switches.

Versions 1.0 and 2.0 of the GNMP currently specify only network management capabilities. Not until Version 3.0 will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communication of management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP. One reason for this goal is the widespread use of SNMP.

No Ada binding is available for the ISO system management standards.

Performance management could make use of generalized event management facilities, but most products currently implement their own event management.

3.9.5.2.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.5.2.5 Related standards. The following standards are related to performance management or performance management standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if FTAM functionality are required.

c. ISO/IEC 8650:1988: Association Control Service Element (ACSE), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: ROSE, as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: CMIS.

i. ISO/IEC 9596:1991: CMIP.

j. ISO/IEC 10165-1:1993: SMI.

k. ISO/IEC 10165-2:1992: DMI.

l. ISO/IEC 10165-4:1992: GDMO.

m. ISO/IEC DIS 11578.2: RPC.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7, of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: C315:5/94: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.9.5.2.6 Recommendations. To procure performance management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications in the ISO 10164 and 10165 standards related to these requirements. Finally, they must include their requirements and the related standards in the RFP.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile. OMNIPoint adopts the ISO 10164 and 10165 series of standards.

FIPS 144 is a mandatory standard according to the Federal ADP and Telecommunications Standards Index and shall be used if it satisfies the user's requirements.

3.9.5.3 Network flow control. Flow control refers to the regulation of the movement of datagrams through the transfer process. It includes the ability to manage the size of the information at various stages in the process.

3.9.5.3.1 Standards. Table 3.9-20 presents standards for network flow control.

TABLE 3.9-20 Network flow control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Transmission Control Protocol

Standard 7/RFC-793

Mandated

(Approved)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

IAB

The Point-to-Point Protocol (PPP)

Standard 51/RFC 1661

Mandated

(Approved)

GPC

DOD

Transport Profile: Reliable End System Transport for DOD Communications

MIL-STD-2045-14500 Part 1:March 1994

Informational

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications Wide Area Network Access (References ISO 8208 Information Processing Systems - Data communications - X.25 Packet Level Protocol for Data Terminal Equipment)

MIL-STD-2045-14502 Part 3:July 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Balanced Point-to-Point Digital Data Circuit

MIL-STD-2045-14500 Part 2:March 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Subnetwork for an Unbalanced Data Link

MIL-STD-2045-14500 Part 3:March 1994

Informational

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications: Point-to-Point Links

MIL-STD-2045-14502 Part 2:July 1994

Informational

(Approved)

GPC

DOD

Transport Protocol for High-Stress Resource Constrained Environments

MIL-STD-2045-44000

Informational

(Formative)

3.9.5.3.2 Alternative specifications. There are no alternative specifications.

3.9.5.3.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.9.5.3.4 Portability caveats. Connection-oriented transport classes do not interoperate. Applications using different classes of transport service will have portability problems. Class Zero connection-oriented transport must be provided along with X.25 if public messaging systems are to be connected to the procured systems.

The X.25 equipment that conforms to different X.25 specification dates (e.g., 1980, 1984, 1988, 1992) can have interoperability problems.

3.9.5.3.5 Related standards. There are no related standards.

3.9.5.3.6 Recommendations. Flow control is one of the functions supported by the Transmission Control Protocol (TCP). The TCP should be used as specified in the IAB STD 7. The IAB STD 3 identifies and corrects errors in the TCP.

MIL-STD-2045-14500-01 should be used for legacy systems interoperability. It uses Class Four connection-oriented transport protocol is one of the base standards. It provides the most reliable transport service and, in turn, assumes the least about the network layer services supporting transport. Implementations requiring use of TP4 for flow control services should comply with MIL-STD-2045-14500-01. A connection-oriented transport class must be chosen based on the reliability of the other OSI layers in the system. MIL-STD-2045-14500 parts 2 and 3 should be used for legacy systems. For legacy systems, LAPB should be used as specified in MIL-STD-2045-14500 Parts 2 and 3.

If recommended standards do not meet system requirements, or are cost prohibitive, standards for the legacy systems may be used as long as interoperability is not impacted. The use of legacy systems standards may require a waiver from the appropriate authority. MIL-STD-2045-44000 is an emerging standard. It uses TCP and UDP with enhancements to meet specific requirements for high-stress resource constrained environments.

3.9.5.4 Network sequencing. Sequencing is a function performed by the N-layer to preserve the order of N-service data units that were submitted to the N-layer (ISO 7498).

3.9.5.4.1 Standards. Table 3.9-21 presents standards for network sequencing.

TABLE 3.9-21 Network sequencing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Transmission Control Protocol

Standard 7/RFC-793

Mandated

(Approved)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

IAB

The Point-to-Point Protocol (PPP)

Standard 51/RFC 1661

Mandated

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications Wide Area Network Access (References ISO 8208 Information Processing Systems - Data communications - X.25 Packet Level Protocol for Data Terminal Equipment)

MIL-STD-2045-14502 Part 3:July 1994

Informational

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications: Point-to-Point Links

MIL-STD-2045-14502 Part 2:July 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Reliable End System Transport for DOD Communications

MIL-STD-2045-14500 Part 1:March 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Balanced Point-to-Point Digital Data Circuit

MIL-STD-2045-14500 Part 2:March 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Subnetwork for an Unbalanced Data Link

MIL-STD-2045-14500 Part 3:March 1994

Informational

(Approved)

GPC

DOD

Transport Protocol for High-Stress Resource Constrained Environments

MIL-STD-2045-44000

Informational

(Formative)

3.9.5.4.2 Alternative specifications. There are no alternative specifications.

3.9.5.4.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.9.5.4.4 Portability caveats. Connection-oriented transport has five levels of service that deal with reliability. These classes do not interoperate. Applications using different classes of transport service will have portability problems. Class Zero connection-oriented transport must be provided along with X.25 if public messaging systems are to be connected to the procured systems.

The X.25 equipment conforming to different specification dates (e.g., 1980, 1984, 1988, 1992) can have interoperabilty problems.

3.9.5.4.5 Related standards. There are no related standards.

3.9.5.4.6 Recommendations. Sequencing is one of the functions supported by Transmission Control Protocol (TCP). The TCP should be used as specified in the IAB STD 7. The IAB STD 3 identifies and corrects errors in the TCP.

MIL-STD-2045-14500-01 is recommended for legacy systems interoperability. It uses TP4 as one of its base standards. The Class Four transport provides the most reliable transport service. It assumes that the underlying network service is unreliable. A connection-oriented transport class must be chosen based on the reliability of the other OSI layers in the system. MIL-STD-2045-14500 parts 2 and 3 are recommended for legacy systems use. LAPB should be used as specified in MIL-STD-2045-14500 Parts 2 and 3.

If recommended standards do not meet system requirements, or are cost prohibitive, standards from the legacy column may be used as long as interoperability is not impacted. The use of legacy systems standards may require a waiver from the appropriate authority. MIL-STD-2045-44000 is an emerging standard. It uses TCP and UDP with enhancements to meet specific requirements for high-stress resource constrained environments.

3.9.5.5 Communication of management information. (This BSA appears in part 8 and part 9.) Communication of management information refers to a mechanism and protocol with extensions specifically geared to the communication of data and information used by system management and network management applications for monitoring and controlling resources. This management information may be shared between management processes and structured according to the requirements of those processes.

3.9.5.5.1 Standards. Table 3.9-22 presents standards for communication of management information.

TABLE 3.9-22 Communication of management information standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Simple Network Management Protocol (SNMP)

Standard 15/RFC-1157

Mandated

(Approved)

GPC

DOD

DoD Standardized Profiles - Internet Network Management Profile for DoD Communications

MIL-STD-2045-17507:7/94

Informational

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - Common Management Information Protocol (CMIP) - Part 1: Specification (Includes amendment 1 and 2 of ISO/IEC 9596-1:1990)

9596-1:1991

Informational

(Approved)

IPC

ISO/IEC

Elements of Management Information Relating to OSI Network Layer Standards

10733:1993

Informational

(Approved)

IPC

ISO/IEC

Elements of Management Information Related to OSI Data Link Layer Standards

10742:1994

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

CPC

X/Open

Management Protocol Profiles (XMPP)

C206 (11/93)

Informational

(Approved)

CPC

IETF

Protocol Operations for Simple Network Management Protocol, version 2 (SNMPv2)

RFC 1448:1993

Informational

(Approved)

IPC

ISO

OSI Remote Procedure Call (RPC) (Replaces DIS 11578 PT 1 Thru PT 4)

11578.2

Informational

(Draft)

IPC

IAB

Simple Management Protocol (SMP)(Developed in response to an IETF request for an improved SNMP)

SMP

Informational

(Draft)

3.9.5.5.2 Alternative specifications. Hewlett-Packard's Postmaster, on which the OSF DME's CMIP and Simple Network Management Protocol (SNMP) implementations are based, is also available.

3.9.5.5.3 Standards deficiencies. With its object-oriented approach, CMIS/CMIP has a relatively expensive initial application implementation cost. This flaw is offset by a low maintenance cost, because CMIS/CMIP allows objects to be added, and an associated level of management to be provided, at a small incremental cost. There is no standard API to CMIS/CMIP. Only a limited number of narrowly focused applications are implemented with it. It lacks a complete set of associated object definitions needed for network management and sufficient associated security standards.

The SNMP is a simple request-and-reply protocol. It performs all its operations using a fetch-and-store paradigm, rather than defining a large set of commands. Effectively, the SNMP network manager is restricted to only two commands that are performed on Management Information Base (MIB) data items: "set" and "get." Variables are retrieved (get) or modified (set). All other operations are defined as side-effects of the "set" operation.

The SNMP's chief disadvantage is the fact that its simplicity severely limits the protocol's ability to satisfy users' requirements for event reporting, sufficient control, and extensibility. Because SNMP is so simplistic and limited, it provides more of a monitoring and data gathering capability than a management function.

The SNMP accommodates only limited event reporting by means of the "trap" mechanism. Other events must be discovered by the managing node by means of periodic polling. Its simplicity compromises its ability to support consistent or extensive addressing. It has limited security capabilities, and does not support threshold-driven performance notification except indirectly through side effects or "set" operations on MIB items. SNMP cannot be extended easily.

The SNMP has a high maintenance cost. Although the first implementation of SNMP is relatively inexpensive, SNMP's simplicity so severely limits its extensibility that future SNMP developments are more likely to occur in the form of new proprietary and standard Management Information Bases (MIBs) rather than as SNMP enhancements. Each additional MIB will require changes and additions to its existing specific applications to support new functions. New MIBs also will require a unique application code to be developed, modified, documented, and supported. MIB development and maintenance can result in a high cost to users and vendors and present a major SNMP concern.

The SNMP lacks an object-oriented approach to network management. The lack of object orientation is a major factor limiting the SNMP's extensibility and its ability to support legacy systems, support system and network management, and make complex distributed system management more intuitive.

It lacks the ability to manage a network of networks in which different managers must interact on a peer-to-peer basis.

Because the SNMP cannot be extended easily, and extensions require changes to SNMP applications, developing new SMP products rather than retooling existing ones probably will be less costly.

The future of SMP is uncertain because it is unclear whether vendors will want to develop new products for a protocol that is incompatible with the major systems management standards today (e.g., from ISO, NMF, X/Open, and OSF). SMP is still less functional than CMIS/CMIP.

The SMP is not an Internet standard. Although developed in response to a request issued by the Internet Engineering Task Force (IETF) for an improved SNMP, SMP was developed outside the IETF. Furthermore, the SMP developers do not plan to submit it as a proposed Internet standard. They feel that submitting SMP to a committee would subject it to alteration and a lengthy review, and would slow down development of a coherent technology.

SMP is not accepted by groups such as the Network Management Forum (NMF), X/Open, OSF, and the National Institute of Standards and Technology (NIST). These groups are resistant to SMP because it lacks an object-oriented approach to network management. Despite the improvements, without object orientation, SMP is still incompatible with the ISO and NMF network management model, as well as with the OSF's Distributed Management Environment (DME) and X/Open's systems management specifications. Vendors moving from SNMP to SMP may find it more cost effective to develop new SMP products.

SMP is not easily extensible, and like SNMP, is expensive to extend. This is largely due to SMP's lack of an object-oriented approach to network management.

3.9.5.5.4 Portability caveats. Nonstandard SNMP MIB definitions have proliferated.

The SNMP MIB is tailored to accommodate only Internet equipment. Despite the X/Open, OSF, and former UI (now X/Open) consolidated interface to CMIP and SNMP (X/Open Management Protocol (XMP) and CM-API), without object-orientation SNMP is still incompatible with the ISO and NMF network management model, as well as with the OSF's Distributed Management Environment (DME) and X/Open's systems management specifications.

SNMP's design does not lend itself to migration from and coexistence with legacy systems. For example, SNMP does not support the ability to send the same operation to different classes of objects (an important concept known in this context as "polymorphism," which CMIS/CMIP supports).

3.9.5.5.5 Related standards. The following standards are related to management information communication standards:

a. ISO/IEC 7498:1986: Management Framework.

b. ISO/IEC 8326:1987 and 8327:1987: Connection-Oriented Session Service and Connection-Oriented Session Protocol, respectively.

c. ISO/IEC 8326 AD 2: Connection-Oriented Session Service - Incorporation of Unlimited User Data.

d. ISO/IEC 8327 AD 2: Connection-Oriented Session Protocol - Incorporation of Unlimited User Data.

e. ISO/IEC 8571:1988: FTAM, as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if File transfer, Access, and Management functionality are required.

f. ISO/IEC 8649:1988 and 8650:1988: Association Control Service Element (ACSE) and Association Control Protocol (ACP), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

g. ISO/IEC 8822:1988 and 8823:1988: Connection-Oriented Presentation Service and Connection-Oriented Presentation Protocol, respectively.

h. ISO/IEC 8824:1990: Abstract Syntax Notation 1 (ASN.1).

i. ISO/IEC 8825:1990: Basic Encoding Rules (BER) for ASN.1 .

j. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

k. ISO/IEC 9072-1:1989 and 9072-2:1989: ROSE and Remote Operations Protocol (ROP), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES) and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

l. ISO/IEC 10165-1:1993: SMI.

m. ISO/IEC 10165-2:1992: DMI.

n. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

o. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

p. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7, of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

q. Open Software Foundation Distributed Computer Environment (DCE): Remote Procedure Call (RPC) Service Definition.

r. Plan to use IEEE 1327 Object Management API, or X/Open's XOM (on which 1327 is based) to simplify the management of networked managed resources in a CMIP environment. (See system management APIs BSA in part 8 for more information.)

s. RFC 1006:1987: ISO transport services on top of the TCP: version 3 (IAB Std 35).

3.9.5.5.6 Recommendations. All new systems and systems undergoing major upgrades should use the Internet Architecture Board (IAB) STD 15, SNMP (RFC 1157). Those persons conducting procurements that involve IAB standards should review the latest version of the IAB official protocol standards list to ensure that the appropriate RFCs are specified.

The PM should plan to use CMIS/CMIP for OSI/GOSIP networks and existing TCP/IP networks, because SNMP does not have the required functionality to manage distributed networks and is very expensive to maintain.

Until environments become distributed, SNMP is a suitable solution for stand-alone local area networks.

The PM also should plan to use either X/Open's XMP or OSF's CM-API (they are the same) as a common API to CMIP and SNMP. (See the system administration and management APIs BSA in part 8 for more information).

The CMOT users, vendors, and applications should be aware of some of the functional differences between OSI managed systems and Internet agents because CMIS/CMIP's more sophisticated and additional features may be difficult to map reliably to TCP/IP and SNMP.

A common protocol API should be used to access CMIP and SNMP. X/Open, Unix International, and OSF specify the same API. X/Open and Unix International call the API "XMP" (X/Open Management Protocol); OSF calls the same protocol CM-API (Consolidated Management API). Although XMP and CM-API provide an extra call specific to SNMP, because the SNMP "GetNext" function call does not work in an OSI environment, the consolidated management protocol API provides the union of the CMIP and SNMP protocols and service primitives consistently. It hides some of the differences between CMIP and SNMP. For most work, programmers and system managers need to learn only a single syntax to access both protocols.

3.9.5.6 Managed information base. Defined objects are network and system objects that can be managed by a network or system management application and are stored in a management information database.

3.9.5.6.1 Standards. Table 3.9-23 presents standards for managed information base.

TABLE 3.9-23 Managed information base standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Structure of Management Information (SMI)

Standard 16/RFC-1155/RFC-1212

Mandated

(Approved)

IPC

IAB

Management Information Base

Standard 17/RFC-1213

Mandated

(Approved)

NPC

IEEE

POSIX System Administration - Part 2: Software Administration (former P1003.7.2)

1387.2:1995

Informational

(Approved)

IPC

ISO/IEC

OSI Structure of Management Information (SMI), Part 1: Management Information Model

10165-1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Structure of Management Information (SMI), Part 2: Definition of Management Information (DMI)

10165-2:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Structure of Management Information (SMI), Part 4: Guidelines for the Definition of Managed Objects (GDMO)

10165-4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Structure of Management Information (SMI), Part 5: Generic Management Information (GMI)

10165-5:1993

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 3: User and Group Administration

1387.3:1996

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

CPC

NMF

Object Class Library Supplement: DIS GDMO Translation

Forum Library - Volume 1:Release 1.0 Definitions - Issue 1.3

Informational

(Approved)

CPC

NMF

OSI/NM Forum Modeling Principles for Managed Objects Technical Report

NMF Technical Report

Informational

(Approved)

CPC

IETF

Management Information Base for SNMP v2

RFC 1450:1993

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 4: Print Administration (former P1003.7.1)

P1387.4

Informational

(Draft)

NPC

OSFs Special Interest Group

Catalog of OSF Managed Object Definitions (Generic objects, and objects to represent hardware, the operating system (particularly OSF/1), applications, users, distributed environments (particularly the DCE), and metadata.)

Catalog of OSF Managed Object Definitions

Informational

(Formative (Working documents))

CPC

IETF

OSI Integrated Management (OIM): Management Information Base for TCP/IP Networks (MIB)

RFC XXXX

Informational

(Formative)

GPC

NIST

Registry for managed objects

TBD-Registry for managed objects

Informational

(TBD)

CPC

IETF

OSI Internet Management: Management Information Base (CMIP over TCP/IP)(CMOT)(SNMP MIB II mapped into CMIP)

RFC 1214:1991

Informational

(Historic (Not recommended))

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

3.9.5.6.2 Alternative specifications. There are no alternative specifications available.

3.9.5.6.3 Standards deficiencies. ISO's object model is targeted at networking and communications, rather than general system management. It is built around CMIP and is specific to CMIS services. Among other things, the ISO object model contains concepts such as the registration of objects and a class hierarchy. This registration is patterned around the way CMIS/CMIP objects are registered. This is of great concern to network management. A more generic extensible object model that can be specialized for many kinds of system and software objects and used with multiple types of communication systems (e.g., remote procedure calls) is needed for system management.

The ISO Guidelines for the Definition of Managed Objects (GDMO) formal object definition language syntax is highly specific to CMIP and uses the complex ISO OSI ASN.1 notation. This syntax lends itself to the definition of objects such as modems and other network devices. It is not necessarily suitable for defining more abstract objects, such as applications and operating systems, which are needed for general system management.

The OMG's objects lack the ability to have more than one interface. This ability, called "allomorphism," is taken from the ISO OSI management model's allomorphism requirement. This multiple interface ability makes it possible to identify different classes of objects (e.g., classes A, B, and C), then have an application operate on an instance of class A as if it were an instance of class B or C. Allomorphism is important because it allows the definition of enhanced versions of a managed object class that are backward compatible with previous versions. Migration costs are thereby reduced.

3.9.5.6.4 Portability caveats. Multiple object models are being defined by various organizations (e.g., ISO, the Object Management Group). These different models conflict with each other. Among other things, they differ in the way they represent objects, the object interfaces, the targeted application domain, and the targeted types of objects.

The OMG object model, on which the OSF object model is based, is a generic one, to which extensions can be added to specialize objects for different domains. In contrast, the ISO object model is targeted at networking and communications. It is built around CMIP and is specific to CMIS services. Although CMIS/CMIP is supposed to accommodate any management data, until now, the focus has been on network management.

The ISO, NMF, and IEEE P1387 distributed system administration groups define their managed objects using the ISO GDMO definition language. OSF is using its Interface, Inheritance, Implementation, and Installation (I4DL) definition language, which is based on the OMG's Interface Definition Language (IDL), to define its managed objects. Unfortunately, the GDMO, I4DL, and IDL interfaces defined by each of the object models affect the basic object model (which are different for ISO, OSF, and OMG) and make it difficult to use one object model's set of interfaces for another.

3.9.5.6.5 Related standards. The Object Management Group's Interface Definition Language (IDL) for defining generic objects is related to object definition standards.

3.9.5.6.6 Recommendations. All new systems and systems undergoing major upgrades should use the Internet Architecture Board (IAB) STD 16 and IAB STD 17. Those persons conducting procurements that involve IAB standards should review the latest version of the IAB official protocol standards list to ensure that the appropriate RFCs are specified. If recommended standards do not meet system requirements or are cost prohibitive, standards for the legacy systems may be used, as long as interoperability is not impacted. The use of legacy system standards may require a waiver from the appropriate authority.

3.9.5.7 Event management. Event management and notification services allow system managers and system administrators to be informed that a predefined system or network event of interest (e.g., additional resources needed) has occurred, so that the event may be managed in a predefined way that prevents network or system problems. Event management is related closely to fault and performance management, in that each of these services could make use of event management to log, track, and provide alerts based on relevant events.

3.9.5.7.1 Standards. Table 3.9-24 presents standards for event management.

TABLE 3.9-24 Event management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Stable Implementation Agreements for Open System Environments, Ver. 8, Ed. 1

Special Pub. 500-224:12/94

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Informational

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Informational

(Formative)

3.9.5.7.2 Alternative specifications. The following specifications are also available:

a. Banyon Systems' Network Event Logger (from Wang Laboratories) on which OSF's Event Notification Component is based.

b. Banyon Systems' PC library for the Network Event Logger, which filters and logs PC events locally and sends them to a Network Event Logger server on a host system for further processing. The OSF DME's PC Error Logging Component is based on this Banyon Systems' PC library.

3.9.5.7.3 Standards deficiencies. None of the event notification components in any of the consortia management systems are compatible with the IEEE P1003.1b specifications for event notification. OSF DME event management is intended to be used as the basis for commercial management systems, but is not currently supported by any products.

3.9.5.7.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.9.5.7.5 Related standards. The following standards are related to event management and notification standards:

a. ISO/IEC DIS 11578.2: RPC (Replaces DIS 11578 PT 1 Thru PT 4.)

b. NIST APP - Special Pub. 500-230: 1995.

c. OSF: Distributed Computing Environment (DCE) Remote Procedure Call Component.

d. USL/Sun Microsystems: Open Network Computing (ONC) Remote Procedure Call (RPC) Component.

e. NIST FIPS 179-1:1995: Government Network Management Profile (GNMP).

f. ISO/IEC 9596-1:1991: OSI CMIP, Part 1: Specification.

g. IAB: RFC 1157: SNMP.

3.9.5.7.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

3.9.5.8 Input/Output control. (This BSA appears in both part 8 and part 9.) Input/Output (I/O) control standards include services such as device initialization, device attachment, asynchronous operation, error notification, raw I/O, and other services needed to implement logical device drivers in a system.

Input/output control enables control of different media devices over the network through software. The media devices include videocassette recorders, laser disc players, video cameras, CD players, and so on. Control capabilities may be available on the workstation through a graphical user interface (GUI). They are similar to the controls on the device, such as play, record, reverse, eject, and fast forward. Input/output control is important because it enables the operator to control video and audio remotely without requiring physical access.

3.9.5.8.1 Standards. Table 3.9-25 presents standards for input/output control.

TABLE 3.9-25 Input/Output control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: Real Time System API Extensions

P1003.1d

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.5.8.2 Alternative specifications. The following specifications are also available:

a. Berkeley 4.2/4.3 Unix.
b. OSF: OSF/1 (product implementation).

3.9.5.8.3 Standards deficiencies. POSIX.1 provides basic input/output primitives, but lacks the generalized services needed to implement device drivers for many types of devices. POSIX.1b provides support for asynchronous and synchronized I/O, but also lacks generalized services needed to implement device drivers for many types of devices.

3.9.5.8.4 Portability caveats. The "ioctl" function, which is associated with the control of an asynchronous device (including terminal characteristics) has been identified repeatedly as a source of portability problems. It is an old system call, and during the many years it has been in Unix, several variants have evolved. The differences appear at low levels. However, it is not always easy to spot these differences, because each "ioctl" is defined loosely and makes its own assumptions. As networking becomes more common, the device drivers executing some code may be located across a network, remote from the source of the system call. The many variants and interpretations of "ioctl," complicate networking because the same "ioctl" system call possibly cannot be used across a network to control a remote peripheral. For example, the SVID version of "ioctl" looks like a completely different call. Because of the difficulty in reaching agreement on a standardized version of the "ioctl," the POSIX standards groups eliminated "ioctl" from the standard early. Because the POSIX.1b real time group believes that most devices communicate using "ioctl," there was a move to reinstate and standardize "ioctl" in the P1003.1b standard. The final result, however, was the incorporation of specific "tc" (terminal control) functions to replace each "ioctl" function.

The use of "ioctl" calls to set certain terminal modes causes problems because a single, standard terminal interface or portable mechanism to set the modes of an asynchronous terminal does not exist. Such a standard has not been defined, because it would require the "raw" (unprocessed) and "cooked" (processed) modes to be defined. Defining these would create other problems. However, not defining them could cause application codes to be written in a nonportable way.

The SVID and XPG support the "ioctl" call as part of their device service interfaces. In practice, this support is different on every different implementation of these specifications. The "ioctl" function, while deprecated for asynchronous terminal control in favor of the POSIX.1 "tc" functions, is still required to control other, less common device types. Unfortunately there is no standard for programmatic control of video cameras, etc., even though every system which supports such a device will provide the basic control functionality needed in some way.

3.9.5.8.5 Related standards. The following standards are related to input/output control or input/output control standards:

a. ISO 10164-7: Security Management.

b. IEEE P1003.1e: Security Interface Standards for POSIX.

c. IEEE 1003.2d:1994: POSIX Batch Environment Amendments.

d. IEEE P1201.1: Uniform API-GUI.

e. NIST FIPS 179-1:1995: GNMP (Government Network Management Protocol): Authentication.

f. MIT Consortium: X Window System.

3.9.5.8.6 Recommendations. The mandated standards are recommended for input/output control. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. It specifies read/write functionality. The "tc-functions" were introduced into POSIX.1 to solve portability issues arising from "ioctl" calls. X/Open SUS covers all the core POSIX functions.

3.9.6 Fault monitoring. Fault monitoring services allow a system to react to the loss or incorrect operation of system components at various levels.

3.9.6.1 Software safety. (This BSA appears in both Part 2: Software Engineering and Part 9: System Management.) These standards provide procedures for identifying as safety-critical those CSCIs or portions thereof whose failure could lead to a hazardous system state (one that could result in death, injury, loss of property, or environmental harm). The developer shall develop a safety assurance strategy, including both tests and analyses, to assure that the requirements, design, implementation, and operating procedures for the identified software minimize or eliminate the potential for hazardous conditions. The objective is to eliminate hazards, and reduce the associated risk to a level of acceptability to the managing activity.

3.9.6.1.1 Standards. Table 3.9-26 presents standards for software safety.

TABLE 3.9-26 Software safety standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

System Safety Program Requirements

MIL-STD-882C: 1996

Adopted

(Approved)

NPC

IEEE

Software Safety Plans

1228:1994

Informational

(Approved)

3.9.6.1.2 Alternative specifications. No other specifications are known.

3.9.6.1.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.6.1.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.6.1.5 Related standards. None.

3.9.6.1.6 Recommendations. MIL-STD-882C is recommended.

3.9.6.2 Database recovery. (This BSA appears in both part 4 and part 9.) Database recovery refers to the ability to detect a failure in a system, recover from failure, and permit a slave copy to become a master copy, assuring data integrity and consistency.

3.9.6.2.1 Standards. Table 3.9-27 presents standards for database recovery.

TABLE 3.9-27 Database recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

OSI Service Definition for the Commitment, Concurrency, and Recovery (CCR) Service Element

9804:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Protocol Specification for the Commitment, Concurrency, and Recovery (CCR) Service Element

9805:1990

Informational

(Approved)

3.9.6.2.2 Alternative specifications. No other consortia or de facto specifications are available.

3.9.6.2.3 Standards deficiencies. Deficiencies in database recovery standards are unknown.

3.9.6.2.4 Portability caveats. At present, CCR is not widely implemented, although most vendors intend to implement it. Therefore, one should make no assumptions about the degree of portability and interoperability existing for any database recovery utilities.

3.9.6.2.5 Related standards. The following standards are related to database recovery or database recovery standards:

a. ISO/IEC 10026 Parts 1, 2, and 3: Distributed Transaction Processing (DTP) protocol

b. X/Open XA Interface specification, which includes CCR's two-phase commitment

3.9.6.2.6 Recommendations. If CCR is desired (and it is necessary for multivendor, distributed database and distributed transaction processing), it must be referenced specifically in procurement specifications. Otherwise, vendors probably will propose products that do not meet this specification.

For the greatest portability, design applications as if CCR were not present.

3.9.6.3 Recovery and restart services for long running transactions. (This BSA appears in both part 4 and part 9.) Checkpoint and restart is provided for interactive transactions on centralized systems via the SQL "commit" and "rollback" commands, and for short-running transactions on distributed systems via the 2-Phase Commit specified in the ISO CCR standard. However, long running transactions require standardized checkpointing, restarting, and migration services and interfaces to prevent the loss of the transaction if a system fails or shuts down. Two APIs must be standardized for this purpose. One will allow application control of the checkpoint. The other will allow the transaction manager to control the checkpointing and restart activity over a range of heterogeneous resource managers.

3.9.6.3.1 Standards. Table 3.9-28 presents standards for recovery and restart services for long running transactions.

TABLE 3.9-28 Recovery and restart services for long running transactions standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 2:Shell and Utilities - Amendment 1: Batch Environment

1003.2d:1994

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Informational

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Informational

(Formative)

3.9.6.3.2 Alternative specifications. The following specifications are also available:

a. USL: Tuxedo
b. Transarc: Encina
c. NCR: Top End

3.9.6.3.3 Standards deficiencies. Based on a requirement from the P1003.15 Batch Queuing Extensions Standards Group, the POSIX.1 revision will specify application control of checkpointing. But this specification is geared to batch environments, and does not address the transaction manager's control of checkpoint, restart, or migration of services needed for a transaction processing environment. This need is not being addressed other than by de facto solutions.

1003.2d specifies some capabilities needed for checkpointing and restart in batch environments, but as a standard geared to batch environments, it does not address the transaction manager's control of checkpoint, restart, or migration of services.

3.9.6.3.4 Portability caveats. Without standardized interfaces to allow application control of checkpointing and transaction manager's control of checkpointing and restart activity, portability and interoperability across heterogeneous resource managers are nonexistent, except for short-running transactions (which are controlled via SQL's "commit" and "rollback" commands and via ISO's CCR standard).

3.9.6.3.5 Related standards. The following standards are related to recovery and restart services or standards:

a. ISO 9041-1: Basic Class Virtual Terminal Protocol Specification

b. ISO 9075:1992: SQL 3rd edition

c. IEEE 1003.1b:1993: Real-Time Extension to POSIX

d. IEEE 1003.1c:1995: Threads Extension to POSIX

3.9.6.3.6 Recommendations. There is no recommendation for recovery and restart services.

3.9.6.4 Network error recovery. These are procedures for the detection and reconstitution of corrupted data, packet data units, and/or datagrams.

3.9.6.4.1 Standards. Table 3.9-29 presents standards for network error recovery.

TABLE 3.9-29 Network error recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

IAB

Transmission Control Protocol

Standard 7/RFC-793

Mandated

(Approved)

IPC

IAB

Host Requirements

Standard 3/RFC-1122/RFC-1123

Mandated

(Approved)

IPC

IAB

The Point-to-Point Protocol (PPP)

Standard 51/RFC 1661

Mandated

(Approved)

GPC

DOD

Transport Profile: Reliable End System Transport for DOD Communications

MIL-STD-2045-14500 Part 1:March 1994

Informational

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications Wide Area Network Access (References ISO 8208 Information Processing Systems - Data communications - X.25 Packet Level Protocol for Data Terminal Equipment)

MIL-STD-2045-14502 Part 3:July 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Balanced Point-to-Point Digital Data Circuit

MIL-STD-2045-14500 Part 2:March 1994

Informational

(Approved)

GPC

DOD

Transport Profile: Subnetwork for an Unbalanced Data Link

MIL-STD-2045-14500 Part 3:March 1994

Informational

(Approved)

GPC

DOD

Internet Transport Profile for DOD Communications: Point-to-Point Links

MIL-STD-2045-14502 Part 2:July 1994

Informational

(Approved)

GPC

DOD

Transport Protocol for High-Stress Resource Constrained Environments

MIL-STD-2045-44000

Informational

(Formative)

3.9.6.4.2 Alternative specifications. There are no alternative specifications.

3.9.6.4.3 Standards deficiencies. No deficiencies have been identified in the existing standards.

3.9.6.4.4 Portability caveats. Connection-oriented transport has five levels of service that deal with reliability. These classes do not interoperate. Applications using different classes of transport service will have portability problems.

The X.25 equipment conforming to different specification dates (e.g., 1980, 1984, 1988, 1992) can have interoperability problems.

3.9.6.4.5 Related standards. There are no related standards.

3.9.6.4.6 Recommendations. Error recovery is one of the functions supported by the Transmission Control Protocol (TCP). The TCP should be used as specified in the IAB STD 7. The IAB STD 3 identifies and corrects errors in the TCP.

MIL-STD-2045-14500-01 is recommended for legacy systems interoperability. It specifies the details necessary to meet DOD requirements for connection-oriented transport service over a connectionless network service. It uses class four transport protocol as one of its base standards. It is an error detection and recovery class that assumes the underlying network service is unreliable. MIL-STD-2045-14500 parts 2 and 3 are recommended for legacy systems interoperability. Use of LAPB for Balanced Point to Point Digital Data Circuit should comply with MIL-STD-2045-14500-02. For an Unbalanced link, LAPB should be used as specified in MIL-STD-2045-14500-03.

If recommended standards do not meet system requirements, or are cost prohibitive, standards for the legacy systems may be used as long as interoperability is not impacted. The use of legacy systems standards may require a waiver from the appropriate authority. MIL-STD-2045-44000 is an emerging standard. It uses TCP and UDP with enhancements to meet specific requirements for high-stress resource constrained environments.

3.9.6.5 Fault management. (This BSA appears in part 8 and part 9.) Fault management services allow a system to react to the loss or incorrect operation of system components. Fault management services encompass services for fault detection, isolation, diagnosis, recovery, and avoidance. Fault management may make use of event management facilities. In practice, fault management and performance management products often incorporate event management functions.

3.9.6.5.1 Standards. Table 3.9-30 presents standards for fault management.

TABLE 3.9-30 Fault management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 4: Alarm Reporting Function

10164-4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 6: Log Control Function

10164-6:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 12: Test Management Function

10164-12:1994

Informational

(Approved)

NPC

SAE

General Open Architecture (GOA) Framework

AS 4893 (Committee AS-5)

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 14: Confidence and Diagnostic Test Categories

10164-14

Informational

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Emerging

(Formative)

NPC

IEEE

POSIX, Part 1: System API, Amendment x: Resource Limit Interface (C Language)

P1003.1p

Emerging

(Formative)

3.9.6.5.2 Alternative specifications. The following specifications for network fault reporting are available:

a. Banyon Systems's Network Event Logger (originally developed by Wang Laboratories), on which OSF's DME event services and logging services are based.

b. Gradient Technologies: PC Event system integrated with a Banyon Systems-based Network Event Logger PC library and a PC Ally server on which OSF has based its PC event and logging component.

3.9.6.5.3 Standards deficiencies. The present ISO 10164-4, "Alarm Reporting Function," 10164-6, "Log Control Function," 10164-5, "Event Report Management Function," 10164-12, "Test Management Function," and 10164-14, "Confidence and Diagnostic Testing Service" standards were designed with network configuration in mind. Theoretically, these standards should be able to be used for configuration management of any computer system. Little work has been done in this area, either in standards groups or in products. Therefore, exactly how these standards should be used in host management is undetermined.

Although several standard libraries of object classes that allow a common view of network resources and fault management of network resources are planned, few are available or sufficiently complete. For example, these library specifications have incomplete object definitions for modems, OSI routers, and transport connections. Based on U.S. Federal Government needs (as shown by NIST surveys), the GNMP added more object class specifications and definitions. These include the following objects: LANs, X.25 Wide-Area-Networks (WANs), Integrated Services Digital Network (ISDN), Fiber Distributed Data Interface (FDDI), modems, bridges, links, and a rudimentary capability to manage OSI routers and transport connections.

Phase 2 GNMP objects also will include protocol software (layers 3-7), routers, terminal servers, Message Transfer Agents (MTAs), Private Branch Exchange (PBXs), and circuit switches.

Versions 1.0 and 2.0 of the GNMP currently specify only network management capabilities. Not until Version 3.0 will the GNMP specify the management information required for general system management, such as host computer configuration and management, operating systems, and database management systems.

The present ISO standards and GNMP specifications require ISO CMIS/CMIP for the communications of management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP also. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

Fault management should make use of general event management such as OSF DME event services, but most products currently implement their own event management facilities.

Finally, standards are needed for problem reporting and tracking, diagnostic standards for hardware and software, and fault isolation.

3.9.6.5.4 Portability caveats. Portability problems with existing standards are unknown.

3.9.6.5.5 Related standards. The following standards are related to fault management or fault management standards:

a. ISO/IEC 7498-4:1989: Management Framework.

b. ISO/IEC 8571:1988: File Transfer, Access, and Management (FTAM), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if File transfer, Access, and Management functionality are required.

c. ISO/IEC 8650:1988: Association Control Service Element (ACSE), as specified in GOSIP Version 2, Section 4.2.7.1, as modified by the NMSIG agreements in Part 18 of the OIW Implementors Agreements.

d. ISO/IEC 8824:1990: Specification of Abstract Syntax Notation 1 (ASN.1).

e. ISO/IEC 8825:1990: Specification of Basic Encoding Rules for ASN.1.

f. ISO/IEC 9041:1990: (OSI Virtual Terminal), as specified in GOSIP Version 2 Sections 4.2.7.2 and 5.3.1, if virtual terminal functionality is required.

g. ISO/IEC 9072:1989: Remote Operations Service Element (ROSE), as specified in the Remote Operations Part 1: Model Notation and Service Definition (ROSES), and the Remote Operations Part 2: Protocol Specification (ROSEP), and as modified by the NMSIG agreements clause 6.5.

h. ISO/IEC 9595:1991: Common Management Information Service (CMIS).

i. ISO/IEC 9596:1991: Common Management Information Protocol (CMIP).

j. ISO/IEC 10165-1:1993: Structure of Management Information (SMI).

k. ISO/IEC 10165-2:1992: Definition of Management Information (DMI).

l. ISO/IEC 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO).

m. ISO/IEC DIS 11578.2: Remote Procedure Call.

n. CCITT X.400 Message Handling System (MHS), as specified in GOSIP Version 2 Sections 4.2.7.3 and 5.3.2, if message handling functionality is required.

o. IEEE 1224:1993: OSI Abstract Data Manipulation (Object Management) API - Language Independent Specification.

p. IEEE 1327:1993: OSI Abstract Data Manipulation (Object Management) API - C Language Binding.

q. NIST OSI Implementors Workshop (OIW) Implementor Agreements relating to the Presentation and Session layers, as specified in Part 5 (Upper Layer Agreements), clause 13.7 of the OIW Stable Implementation Agreements for OSI Protocols Version 3 (NIST Special Publication 500-224).

r. Internet RFC 1155: Structure and Identification of Management Information for Internets based on TCP/IP.

s. Internet RFC 1157: Simple Network Management Protocol.

t. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

u. X/Open: OSI-Abstract-Data Manipulation API (XOM) (Object Management).

3.9.6.5.6 Recommendations. To build or procure fault management applications, users must identify the system management functions that are applicable to their requirements. Then they must identify the various specifications within the ISO 10164 and 10165 standards related to these requirements. Finally, they must specify the requirements and the related standards in the RFP.

The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications. It replaces FIPS 179 (GNMP) in Version 3.0 of the NIST Application Portability Profile.

3.9.6.6 Storage device management. (This BSA appears both in part 8 and part 9.) Storage device management is familiar to most people as "Logical Volume Management." With logical volume management, a logical volume manager provides disk partition flexibility by allowing the disk partitions to grow automatically as the system runs, and by allowing files to span physical volumes. This allows a given file to be larger than any one disk. This flexibility is possible because the logical volume manager manages the disk space by creating what it calls "logical volumes." The logical volume manager determines the correspondences between the logical volumes and the actual physical volumes. A logical drive is an allocated part of a physical drive designated and managed as an independent unit. Hierarchical storage management and archiving addresses the ability to handle different levels of storage transparently, such as disks, tapes, and juke boxes.

3.9.6.6.1 Standards. Table 3.9-31 presents standards for storage device management.

TABLE 3.9-31 Storage device management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Distributed File Service (DFS)

DCE 1.1 DFS:1994

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE): Network File Service (NFS)

DCE 1.1 NFS:1994

Informational

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

CPC

UDI Group

Uniform Driver Interface (UDI) Specification

UDI Rev 0.75

Informational

(Formative)

3.9.6.6.2 Alternative specifications. Future releases of SVR4 will support the Logical Volume Manager, but no other alternative specifications are available.

3.9.6.6.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.6.6.4 Portability caveats. Portability caveats are unknown at this time.

3.9.6.6.5 Related standards. No standards are related to storage device management.

3.9.6.6.6 Recommendations. Open Software Foundation's Distributed File Service is recommended. Logical volume managers are extremely valuable, as many system managers know who have had to back up a system, take it down, repartiation it to accommodate the growth of applications and data in certain partitions, and restore the system, only to do the same thing months later. The logical volume manager eliminates this problem by allowing partitions to grow dynamically.

3.9.6.7 Backup and restore. (This BSA appears both in part 8 and part 9.) Backup and restore standards provide facilities and interfaces to save data as a precaution to system failure and restore the system to a previous data state after failure.

3.9.6.7.1 Standards. Table 3.9-32 presents standards for backup and restore.

TABLE 3.9-32 Backup and restore standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

ANSI

Recorded Magnetic Tape for Information Interchange (1600 cpi, Phase Encoded)

X3. 39-1986 (R1992)

Informational

(Approved)

NPC

ANSI

Recorded Magnetic Tape for Information Interchange (6250 cpi, Group-Coded Recording)

X3. 54-1986 (R1992)

Informational

(Approved)

CPC

OSF

OSF/1 Operating System

OSF/1 O.S.

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.6.7.2 Alternative specifications. The "dd" utility is useful for data copy with optional conversion that promotes portability, (e.g., ASCII to EBCDIC) or for record conversion with discrete record sizes, or multiple sector reads/writes to disk. The Berkeley Unix "dump" command is also available. The OSF's OSF/1 "tar" and "cpio" utilities and USG's System V Release 4 (SVR4) are also available.

3.9.6.7.3 Standards deficiencies. Although the "tar" and "cpio" commands can be used to back up disks, they are very limited in capability. "tar" and "cpio" are copy commands. These commands do not perform incremental backups. Furthermore, "tar" does not span multiple disks. No Ada bindings exist for distributed backup and restore standards.

3.9.6.7.4 Portability caveats. The "ustar" format is an extension of the historical "tar" archive format and, as such, may be read by historical implementation of the "tar" command. The POSIX.2 "pax" command has been developed as a replacement for both "tar" and "cpio" commands. It can read and write "ustar" and "cpio" archives, and most implementations have been extended to read historical "tar" format archives as well.

The "cpio" command can produce two different types of archives: "character"and "binary." The binary archives are non-portable, and cannot be read except on the same platform on which they were produced. POSIX documents only the character "cpio" format, and the "pax" command is only guaranteed to be able to read the character format.

The Berkeley Unix-based set of "backup" commands (e.g., "dump" and "rdump") are not the same as the backup commands based on System V (SVID) (e.g., "backup," "bkexcept,"). The two backup systems have different interfaces and do not work in a compatible manner.

3.9.6.7.5 Related standards. The following standards are related to backup and restore or backup and restore standards.

a. ISO/IEC 9595: CMIS.

b. ISO/IEC 9596: CMIP.

c. ISO/IEC DIS 11578.2: RPC.

d. Network Management Forum: OMNIPoint 1.

e. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

f. Internet RFC 1157: Simple Network Management Protocol.

g. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

3.9.6.7.6 Recommendations. ISO/IEC 9945-1 and ISO/IEC 9945-2 archiving services are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. "Pax" was commissioned for POSIX.2 because "tar" and "cpio" were considered inadequate. "Pax" is similar to "tar" and "cpio." The "tar" and "cpio" formats are expected to be retired from a future version of POSIX.1 in favor of the newer "ustar" format.

3.9.6.8 Hardware error and event conditions. (This BSA appears in both part 8 and part 9.) An event is an unsolicited communication from a hardware device to a computer operating system, application, or driver. Events are generally attention-getting messages, allowing a process to know when a task is complete or when an external event occurs. Error conditions (e.g., system failures, unauthorized access attempts, or strange glitches) must be detected and reported so corrective action can be taken to minimize system or network problems. (See the BSA on error and event logging for more information on tracking errors.)

Offline diagnosis of events which have been written in encoded form to the system log is termed event classification. Encoded events which are written to the system log for later analysis form the raw material for algorithms designed to diagnose and passivate faults, that is to prevent them from being reactivated. Offline classification of errors or events which are indicative of the potential failure of a component can be conducted only when the required information has been saved. Algorithms designed to improve system maintenance and to shorten the duration of outages generally scan the system event log for patterns of event types. Such algorithms can be used to predict imminent failure of software or hardware components. This analysis of logged events could also be processed in parallel while the main system continues to perform.

Services for the detection of events come in two basic forms: active and passive. Events come in two types, those which are anomalous and those which are not. Anomalous events may be classified into two categories: errors, and events which are indicative of a fault which is not yet producing errors, but is the cause of some degradation in system performance. P1003.1h is already addressing passive errors in their draft standard.

3.9.6.8.1 Standards. Table 3.9-33 presents standards for hardware error and event conditions.

TABLE 3.9-33 Hardware error and event conditions standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Emerging

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX Part 1: System Application Program Interface (API) - Amend: Technical Corrigenda to Real Time Extension [C Language]

1003.1i:1995

Informational

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.6.8.2 Alternative specifications. The OSF's OSF/1 (product implementation) is also available.

3.9.6.8.3 Standards deficiencies. POSIX.1 has limited event management capabilities.

3.9.6.8.4 Portability caveats. Symbolic error numbers are a set of names defined for error numbers set by the "exec" functions to indicate the nature of an error condition that has occurred. Symbolic error numbers have been around for a long time and are reasonably stable. However, many implementations, especially the newer ones, use symbolic error numbers that are different from one another. Applications using such new, different symbolic error numbers are not portable except to implementations using the same error number set.

POSIX, X/Open, and SVID support many of the same symbolic error numbers, with some exceptions. For example, POSIX does not support the error symbols "EIDRM" (indicating an identifier has been removed from the system), "ENOMSG" (required message not in the message queue), and "ETXTBSY" (attempt to overwrite active procedure), even though X/Open, and SVID support them. Other differences in symbolic error numbers occur in the following error symbols: "EBADMSG," "ENOSR," "ENOSTR," "EPROTO," "ERESTART," and "ETIME."

Symbolic error numbers provide portability only if programmers and vendors implement programs using them. Implementations using numeric numbers instead of symbolic error names and numbers are not portable.

POSIX, X/Open, and SVID allow additional implementation-defined symbolic error names to be created. Such implementation-defined symbolic error numbers may be a necessity for a particular application. These values are usually returned by extended functionality, not defined by POSIX.1. The SVID, for example, defines the symbolic errors "EBADMSG", "ENOSR", and "ENOSTR" which are returned by the kernal "STREAMS" subsystem. These new symbolic error numbers should be portable among all systems which provide the underlying functionality. The longest of the symbolic error number names is "ENAMETOOLONG."

X/Open's Single Unix Specification (Spec 1170) has aligned XPG4 with POSIX in the areas where they overlap. Thus any XPG4 or Single Unix conforming system is guaranteed to respond with the same symbolic error value although, as discussed above, the actual error number may vary.

3.9.6.8.5 Related standards. The following standards are related to hardware error conditions:

a. IEEE 1003.2:1992: POSIX - Shell and Utility Application Interface.

b. IEEE R1003.5:1992: Ada Language Binding for POSIX (under revision).

c. IEEE P1003.1e: Security Interface Standards for POSIX.

d. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

e. IEEE 1387.2:1995: POSIX System Administration - Part 2: Software.

f. IEEE P1387.3: POSIX System Administration - Part 3: User and Group Administration.

g. IEEE P1003.1g: Protocol Independent Interfaces.

h. IEEE 1224.2:1993: Directory Services API - Language Independent.

i. IEEE 1224.1:1993: X.400 Based Electronic Messaging API.

j. IEEE P1238.1: OSI Applications Program Interface - FTAM.

k. IEEE P1351: OSI Application Interfaces - ACSE.

3.9.6.8.6 Recommendations. The mandated standards are recommended. The operating system standards mandated by the JTA Version 1.0:1996 (ISO/IEC 9945-1:1990, IEEE 1003.1b:1993, IEEE 1003.1c:1995, and IEEE 1003.1i:1995) are all incorporated in the new ISO/IEC 9945-1:1996. Federal Information Processing Standard (FIPS) 151-2 should also be consulted. It adopted ISO 9945-1:1990 and is still applicable to the 1996 version. IEEE 1003.1b added asynchronous event notification to the original IEEE 1003.1. FIPS 151-2 specifies the read/write return options. SUS supports additional error symbols.

To get the better event management capabilities needed for networking, communications, transaction processing, and real time applications, explicitly specify the IEEE 1003.1b standard's real time signals option for asynchronous event notification. For U.S. Federal Government procurements, the NIST Application Portability Profile (APP) and FIPS 151-2 have some special file and directory requirements:

a. The APP and FIPS 151-2 require support for the error message "ENAMETOOLONG" for the open command.

b. The APP and FIPS 151-2 require read() calls and write() calls that are interrupted by a signal after they have successfully read or written data shall return the number of bytes the system has read. POSIX allows the return of either the number of bytes read or written or a return of -1 with "errno" set to [EINTR] after a successful read or write.


To get greater functionality than POSIX provides, establish the error management interfaces provided by X/Open as an internal standard. The problem is that in implementations compliant with POSIX, many specific system calls have differences in their error messages and exception management handling. These system call commands must be analyzed to see which error messages to specify for certain critical commands, as the NIST did in developing FIPS 151-1. A second problem occurs because X/Open, the SVID, and OSF specify more functionalities than POSIX. Even where these functionalities are the same, X/Open's, the SVID's, and OSF/1's error messages are often different. In general, X/Open's error messages for specific system calls tend to be the same, but they differ from OSF/1's, which is the same as Berkeley UNIX's.

3.9.6.9 Event management. Event management and notification services allow system managers and system administrators to be informed that a predefined system or network event of interest (e.g., additional resources needed) has occurred, so that the event may be managed in a predefined way that prevents network or system problems. Event management is related closely to fault and performance management, in that each of these services could make use of event management to log, track, and provide alerts based on relevant events.

3.9.6.9.1 Standards. Table 3.9-34 presents standards for event management.

TABLE 3.9-34 Event management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

GPC

NIST

Stable Implementation Agreements for Open System Environments, Ver. 8, Ed. 1

Special Pub. 500-224:12/94

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Informational

(Approved)

NPC

IEEE

Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) Amendment 1: Realtime Extension (C language)

1003.1b:1993

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Informational

(Formative)

3.9.6.9.2 Alternative specifications. The following specifications are also available:

a. Banyon Systems' Network Event Logger (from Wang Laboratories) on which OSF's Event Notification Component is based.

b. Banyon Systems' PC library for the Network Event Logger, which filters and logs PC events locally and sends them to a Network Event Logger server on a host system for further processing. The OSF DME's PC Error Logging Component is based on this Banyon Systems' PC library.

3.9.6.9.3 Standards deficiencies. None of the event notification components in any of the consortia management systems are compatible with the IEEE P1003.1b specifications for event notification. OSF DME event management is intended to be used as the basis for commercial management systems, but is not currently supported by any products.

3.9.6.9.4 Portability caveats. Portability problems with the existing specifications are unknown.

3.9.6.9.5 Related standards. The following standards are related to event management and notification standards:

a. ISO/IEC DIS 11578.2: RPC (Replaces DIS 11578 PT 1 Thru PT 4.)

b. NIST APP - Special Pub. 500-230: 1995.

c. OSF: Distributed Computing Environment (DCE) Remote Procedure Call Component.

d. USL/Sun Microsystems: Open Network Computing (ONC) Remote Procedure Call (RPC) Component.

e. NIST FIPS 179-1:1995: Government Network Management Profile (GNMP).

f. ISO/IEC 9596-1:1991: OSI CMIP, Part 1: Specification.

g. IAB: RFC 1157: SNMP.

3.9.6.9.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

3.9.6.10 Process checkpoint and restart. (This BSA appears both in part 8 and part 9.) Checkpoint and restart is a method of recovering from a system failure. A checkpoint is a copy of the computer's memory saved periodically on disk along with the current register settings (e.g., the last instruction executed). In the event of any failure, the last checkpoint serves as a recovery point. When the problem has been fixed, the restart program copies the last checkpoint into memory, resets all the hardware registers, and starts the computer from that point. Any transactions in memory after the last checkpoint was taken until the failure occurred will be lost. Checkpoint restart is helpful in any system running long jobs and requiring more time than can be expected between system down-times, and in any job that would be inconvenient to start over in the event of a system failure.

3.9.6.10.1 Standards. Table 3.9-35 presents standards for process checkpoint and restart.

TABLE 3.9-35 Process checkpoint and restart standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

NPC

IEEE

POSIX, Part 1: System API - Amendment x: Checkpoint/Restart Interfaces (C Language)

P1003.1m

Emerging

(Formative)

3.9.6.10.2 Alternative specifications. The only other specifications available are proprietary.

3.9.6.10.3 Standards deficiencies. P1003.1a does not specify how files and directories are identified in the checkpoint file.

3.9.6.10.4 Portability caveats. One checkpoint restart implementation provides a value of "RESTART_FORCE" to restart a checkpoint file or directory, whether or not it could be restarted rationally. This behavior cannot be used in a portable way, since no predictable meaning exists for restarting a process that was in a condition that could not be checkpointed.

3.9.6.10.5 Related standards. ISO IS 9804/9805: CCR is related to process checkpoint and restart.

3.9.6.10.6 Recommendations. Too many unresolved issues are in the checkpoint restart specification in the P1003.1m draft standard to specify the emerging checkpoint restart specification. Issues range from the error codes to how much of the process state to specify explicitly.

Checkpoint/restart, originally in P1003.1a system services as a separate API is now a separate IEEE project work item under P1003.1m. This work was started by the Super Computer and Batch processing systems working groups in conjunction with the P1003.1a working groups to provide mechanisms to suspend a long executing job and/or provide checkpoints along the way so it could be restarted if something happened during execution.

3.9.6.11 Error and event logging. (This BSA appears both in part 8 and part 9.) Error logging is the automatic logging of errors and events to a log (special file) to avoid system or network faults (by detecting that the operation of a component is approaching the edge of its operational range) and to provide a historical record that can be studied to diagnose faults after their occurrence and perhaps prevent their happening in the future.

On the detection of events of interest, the operating system may automatically write the encoded event to the system log and/or may notify a process of the occurrence. This is certainly the case when an error with a high severity level is detected. Logging or notification may occur at any time in the operation of a system. They may occur when an application or the operating system has detected an error, when an event has been generated during event classification (especially if the event is indicative of imminent failure of a component), or when an event is severe and requires the immediate attention of a process and when a corrective action is taken, such as when a processor(hardware) or process(software) is being registered for service.

3.9.6.11.1 Standard. Table 3.9-36 presents standards for error and event logging.

TABLE 3.9-36 Error and event logging standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Adopted

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 4: Alarm Reporting Function

10164-4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 5: Event Report Management Function

10164-5:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 6: Log Control Function

10164-6:1993

Informational

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interface Definitions, Issue 4, Version 2 (part of XPG4)

C434 (9/94)

Emerging

(Approved)

CPC

X/Open

Single Unix Specification (Spec. 1170), System Interfaces and Headers, Issue 4, Version 2, (Part of XPG4)

C435 (9/94)

Emerging

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amend: Services for Reliable, Available, and Serviceable Systems (SRASS) [C Language]

P1003.1h

Emerging

(Formative)

3.9.6.11.2 Alternative specification. The following specifications are also available:

a. Banyon Systems' Network Event Logger (NeL) (from Wang Laboratories) on which OSF's Event Notification Component is based.

b. Banyon Systems' PC library for the Network Event Logger (NeL), which filters and logs PC events locally and sends them to a Network Event Logger server on a host system for further processing.

3.9.6.11.3 Standard deficiencies. No Ada bindings are available for any of the consortium's system management Error Logging Components.

3.9.6.11.4 Portability caveats. Portability problems related to the existing standards are unknown

3.9.6.11.5 Related standards. The following standards are related to error logging standards:

a. ISO/IEC DIS 11578.2: OSI - RPC (Replaces DIS 11578 PT 1 Thru PT 4).

b. NIST APP - Special Pub. 550-230:1995.

c. OSF: DCE RPC Component.

d. USL/Sun Microsystems: Open Network Computing (ONC) RPC Component.

3.9.6.11.6 Recommendations. OMNIPoint 1 is recommended. The OMNIPoint program defines a collection of specifications for the management of network and distributed systems using open standards and specifications.

3.9.7 Security monitoring. Security monitoring provides management services which contribute to the protection of open systems information resources in accordance with applicable security policies.

3.9.7.1 System development. (This BSA appears in part 2, part 9, and part 10.) Development of secure systems requires that security engineering be a key discipline in conjunction with other system, software, and hardware engineering activities.

3.9.7.1.1 Standard. Table 3.9-37 presents standards for system development.

TABLE 3.9-37 System development standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Network Interpretation

NCSC-TG-005, Version 1: 1987

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

DOD

FORTEZZA Cryptologic Programmers' Guide

MD40000501-1.52: 1996

Mandated

(Approved)

GPC

DOD

FORTEZZA Application Implementors' Guide

MD4002101-1.52: 1996

Mandated

(Approved)

GPC

DOD

Software Development and Documentation

MIL-STD-498

Informational

(Approved)

IPC

ISO/IEC

Software Life Cycle Processes

12207:1995

Informational

(Approved)

NPC

EIA

Trial Use Standard - Standard for Information Technology - Software Life-Cycle Processes - Software Development - Acquirer-Supplier Agreement

EIA/IEEE J-STD-016: 1995

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Guidelines for Security of Computer Applications

FIPS PUB 83:1980

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Abstract Service Definition: (same as ITU-T X.511 (1993))

9594-3:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Procedures for Distributed Operations:(same as ITU-T X.519(1993))

9594-4:1993 (or 1994)

Informational

(Approved)

IPC

ISO/IEC

OSI The Directory: Authentication Framework (same as ITU-T X.509 (1993))

9594-8:1993 (or 1994)

Informational

(Approved)

CPC

X/Open

Generic Security Service API (GSS-API) Base

C441 (12/95)

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Legacy

(Draft)

NPC

IEEE

POSIX Part 2: Shell and Utilities - Amendment n: Protection and Control Utilities, Draft 15

P1003.2c: 1995

Emerging

(Draft)

CPC

IETF

Generic Security Service - Application Program Interface, Version 2

RFC 2078: 1997

Emerging

(Draft)

CPC

IETF

Independent Data Unit Protection Generic Security Application Program Interface (IDUP-GSS-API)

draft-ietf-cat-idup-gss-06.txt, 26 November 1996

Emerging

(Draft)

NPC

IEEE

Standard for Information Technology - Software Life Cycle Processes

IEEE/EIA 12207US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data

IEEE/EIA 12207.1US-date

Informational

(Draft)

NPC

IEEE

Guide for Information Technology - Software Life Cycle Processes - Implementation Considerations

IEEE/EIA 12207.2US-date

Informational

(Draft)

3.9.7.1.2 Alternative specification. There are no alternative specifications.

3.9.7.1.3 Standard deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.1.4 Portability caveats. If FORTEZZA services are used, the following guidelines should be consulted:

a. MD4002101-1.52, 3/5/96, FORTEZZA Application Implementors' Guide

b. MD400501-1.52, 1/30/96, FORTEZZA Cryptologic Programmers' Guide, Revision 1.52

3.9.7.1.5 Related standards. DOD Directive 5200.28 "Security Requirements for Automated Information Systems (AISs)," provides the DOD-wide program for AIS security. It provides mandatory, minimum AIS security requirements for systems processing classified, sensitive but unclassified, and unclassified information. For intelligence systems, Director, Central Intelligence Directive (DCID) 1/16, "Security Policy for Uniform Protection of Intelligence Processed in Automated Information Systems and Networks," and "Security Manual for Uniform Protection of Intelligence Information Processed in Automated Information Systems and Networks," should be used in conjunction with DOD 5200.28-STD. The following guidelines also are for use with DOD 5200.28-STD:

a. NCSC-TG-006, Version 1, 28 March 1988, A Guide to Understanding Configuration Management in Trusted Systems

b. NCSC-TG-007, Version 1, 2 October 1988, A Guide to Understanding Design Documentation in Trusted Systems

c. NCSC-TG-008, Version 1, 15 December 1988, A Guide to Understanding Trusted Distribution in Trusted Systems

d. NCSC-TG-018, Version 1, July 1992, A Guide to Understanding Object Reuse in Trusted Systems

e. NCSC-TG-023, Version 1, July 1993, A Guide to Understanding Security Testing and Test Documentation in Trusted Systems

3.9.7.1.6 Recommendations. The standards listed as mandated are recommended.

MIL-STD-498 merges and supersedes DOD-STD-2167A and DOD-STD-7935A and has been approved for use by DOD with a waiver. Requirements for usage waivers are determined by each Service or Agency. MIL-STD-498 contains requirements for security and privacy for software development and documentation. EIA/IEEE J-STD-016: 1995 (formerly IEEE 1498/EIA IS 640) is based on MIL-STD-498 and was issued 30 September 1995 as a joint EIA/IEEE trial use standard. It is anticipated that J-STD-016 will be upgraded from trial use to full use and issued as an ANSI standard in 1997. It is also anticipated that IEEE/EIA 12207US, the U.S. adaptation of ISO/IEC 12207, will be sent to ANSI as a joint standard. IEEE/EIA 12207US will consist of a base standard (12207.0US) and two guides (12207.1US and 12207.2US). The base standard will contain ISO/IEC 12207 and is expected to be approved prior to July 1997. The guide IEEE/EIA 12207.1US, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data, will contain the contents lists of the product descriptions from EIA/IEEE J-STD-016. The guide IEEE/EIA 12207.2US will provide guidance for: software reuse, software process management indicator categories for problem reporting, software/system architecture, development strategies, tailoring and build planning, software product evaluations, alternate means of compliance for joint reviews, configuration management, and acquirer-supplier interaction. The two guides are expected to be final by September 1997. The long range goal is migration to full use of IEEE/EIA 12207US; however, EIA/IEEE J-STD-016 can be used for transition from MIL-STD-498, subject to Agency/Service approval, until organizational processes for IEEE/EIA 12207US are in place.

If FORTEZZA services are used, the following two guidelines should be consulted:

a. MD4002101-1.52, 3/5/96, FORTEZZA Application Implementors' Guide

b. MD4000502-1.52, 1/30/96, FORTEZZA Cryptologic Programmers' Guide, Revision 1.52

3.9.7.2 Security management. (This BSA appears in part 7, part 8, part 9, and part 10.) Security management is a particular instance of information system management. Security management provides supporting services that contribute to the protection of information and resources in open systems in accordance with information domain and information security policies. The basic elements that must be managed are users, security policies, information, information processing systems that support one or more security policies, and the security functions that support the security mechanisms (automated, physical, personnel, or procedural) used to implement security services. For each of these elements, the managed objects that constitute them must be identified and maintained. For example, users must be known and registered, security policies must be represented and maintained and information objects must be identified and maintained. Security policies, security services and security mechanisms are the first classes of managed objects.

3.9.7.2.1 Standards. Table 3.9-38 presents standards for security management.

TABLE 3.9-38 Security management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

DOD

Trusted Network Interpretation

NCSC-TG-005, Version 1: 1987

Mandated

(Approved)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

IPC

ITU-T

The Directory: Procedures for Distributed Operation (X-ref: ISO 9594-4)

X.518: 1993

Informational

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - Common Management Information Protocol (CMIP) - Part 1: Specification (Includes amendment 1 and 2 of ISO/IEC 9596-1:1990)

9596-1:1991

Informational

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 7: Security Alarm Reporting Function (same as ITU-T X.736)

10164-7:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 8: Security Audit Trail Function (same as ITU-T X.740)

10164-8:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 9: Objects and Attributes for Access Control

10164-9:1995

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

NPC

IEEE

POSIX Part 2: Shell and Utilities - Amendment n: Protection and Control Utilities, Draft 15

P1003.2c: 1995

Emerging

(Draft)

NPC

IEEE

POSIX, Part 1: System API - Amendment n: Protection, Audit, and Control Interfaces (C Language), Draft 15

P1003.1e: 1995

Emerging

(Draft)

CPC

OMG

Common Object Request Broker Architecture (CORBA) Security

OMG 95-12-1: 1995

Emerging

(Draft)

CPC

IETF

Domain Name System (DNS) Security Extensions

RFC 2065:1997

Emerging

(Draft)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

NPC

IEEE

Standard for Interoperable LAN Security - Part D: Security Management

802.10d

Informational

(Formative)

IPC

ISO/IEC

Management Plan for Security

JTC1/SC21 SD-7

Informational

(Draft)

3.9.7.2.2 Alternate specifications. There are no alternative specifications.

3.9.7.2.3 Standards deficiencies. Deficiencies exist in standardization of security policy rule representation; key management, including generation, distribution, and accounting; audit information formats; exchange of security management information; and remote security management.

The DGSA principle of decision and enforcement separation requires that the functions determining how to enforce a security policy and the actual enforcement of the policy be implemented independently. That is, the enforcement mechanisms do not need any knowledge of security policy. Standards are needed for object class definitions for classes of managed objects and for methods of representing security policy.

The DGSA calls for a separation mechanism, such as separation kernel, to mediate all calls to security critical functions to ensure that strict isolation is maintained. Standardization of object class definitions for management of critical functions used within the separation kernel is needed.

The present ISO/IEC 10164-7 "Security Alarm Reporting Function," and 10164-8, "Security Audit Trail Function," standards were designed with network security in mind. Little work has been done, either in standards groups or in products, on how to use these standards for general system management (e.g., computer systems and software).

FIPS PUB 179-1 supersedes FIPS PUB 179. The present GNMP specifications require ISO CMIS/CMIP to communicate management information and ISO OSI networking protocols. Plans are for the GNMP eventually to provide a capability to integrate the present GNMP with SNMP. One reason for this goal is the widespread use of SNMP.

No Ada bindings exist for any of the ISO or consortia system management specifications.

The IEEE POSIX Security Working Group (formerly P1003.6) is defining security extensions to the base POSIX interface standard (ISO 9945-1), to include support for audit, privilege, discretionary and mandatory access control, and information labels. These have been redesignated IEEE P1003.1e and IEEE P1003.2c. The draft standards are still incomplete, and the specifications may change.

The POSIX/UNIX permission bits are inadequate for fine-grained control over exactly which users can perform specified actions to particular files.

In the IETF, efforts to develop an acceptable security standard for SNMPv2 have been on hold since September 1995 when the IETF SNMP Working Group failed to agree on the proposals submitted. Since then, two sets of proposals for providing SNMPv2 security have emerged. The first set of proposed specifications, the User-based Security Model (USEC), also referred to as SNMPv2u, consists of two documents: RFC 1909, "An Administrative Infrastructure for SNMPv2" and RFC 1910, "The User-based Security Model for SNMPv2." Both RFCs were issued 28 February 1996 and are classified by the IETF as experimental RFCs. The other proposal is known as SNMPv2*, which its proponents claim is heavily based on USEC. Neither USEC nor SNMPv2* has been approved for a standards track by IETF.

3.9.7.2.4 Portability caveats. The structure of certain traditional UNIX directories, such as the familiar "/tmp," "/usr/spool," and "/usr/spool/mail" directories will have to change to accommodate the P1003.1e and P1003.2c security standards. This is because these are directories to which all users have access and to which many programs write. A change in the way programs write to directories has the potential for causing software portability and systems administrator portability problems.

The traditional UNIX permission bits that have been carried into POSIX are inadequate for defining exactly which user can perform specific actions on specific files. Eliminating the permission bits in favor of Access Control Lists could make the secure POSIX systems incompatible with non-POSIX compliant systems and many applications.

OSF DCE version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not tatally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.9.7.2.5 Related standards. ISO/IEC 9945-1 as profiled by FIPS PUB 151-2 is related to IEEE P1003.1e and IEEE P1003.2c.

3.9.7.2.6 Recommendations. The mandated standards are recommended.

All IEEE P1003.1e and IEEE P1003.2c security systems should incorporate Access Control Lists as an optional feature in addition to permission bits (not "in place of" permission bits). The incompatibilities between the two access control methods (permission bits and access control lists) are not resolvable. The best method for resolving the overall problems seem to be incorporation Access Control Lists as an optional feature on top of permission bits. The permission bits would represent the lowest common denominator of security, showing the maximum amount of openness possible in a system. Organizations needing only the lowest level of security could continue to use the familiar permission bits and associated "chmod" command. Use of access control lists will require a change in security policy such that access is granted if and only if permission is granted and access control permits it.

3.9.7.3 Security risk management. (This BSA appears in part 2, part 7, part 9, and part 10.) Security risk management supports accreditation through a risk analysis of an information system and its operational environment, and the steps taken to manage the risk requirements.

3.9.7.3.1 Standards. Table 3.9-39 presents standards for security risk management.

TABLE 3.9-39 Security risk management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

NIST

Guideline for the Analysis of Local Area Network Security

FIPS PUB 191:1994

Informational

(Approved)

GPC

NIST

Guideline for Automated Data Processing Risk Analysis

FIPS PUB 65:1979

Informational

(Approved)

GPC

NIST

Guidelines for Automatic Data Processing Physical Security and Risk Management

FIPS PUB 31:1974

Informational

(Approved)

3.9.7.3.2 Alternate specifications. There are no alternative specifications.

3.9.7.3.3 Standards deficiencies. Because of its age, FIPS PUB 31 does not include information of all modern security concepts.

3.9.7.3.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.7.3.5 Related standards. The following standards are related to the TCSEC standard:

a. CSC-STD-003-85 25 June 1985, Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer Security Evaluation Criteria in Specific Environments

b. CSC-STD-004-85, 25 June 1985, Technical Rationale Behind CSC-STD-003-85: Computer Security Requirements - Guidance for Applying the Department of Defense Trusted Computer Security Evaluation Criteria in Specific Environments

3.9.7.3.6 Recommendations. The mandated standard is recommended. Office of Management and Budget (OMB) Circular A-130, "Management of Federal Information Resources," provides guidance on effective security risk management of federal information systems. NIST Special Publication 800-12, "An Introduction to Computer Security: The NIST Handbook" provides additional guidance on risk management. DOD Directive 5200.28 requires a risk analysis of an information system be conducted in its operational environment to support accreditation of the information system. System implementors should perform the risk analysis in accordance with CSC-STD-003-85 and CSC-STD-004-85 to determine the appropriate DOD-5200.28-STD class.

3.9.7.4 Security audit. (This BSA appears in part 7, part 9, part 10, and part 11.) Security auditing is a review or examination of records and activities to test controls, ensure compliance with policies and procedures, detect breaches in security, and indicate changes in operation (paraphrased from ISO 7498-2).

3.9.7.4.1 Standards. Table 3.9-40 presents standards for security audit.

TABLE 3.9-40 Security audit standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 8: Security Audit Trail Function (same as ITU-T X.740)

10164-8:1993

Informational

(Approved)

CPC

X/Open

Security Interface Specification: Auditing and Authentication

S020: 1990

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks for Open Systems, Part 7: Security Audit Framework

10181-7

Informational

(Draft)

IPC

ISO/IEC

OSI Distributed Transaction Processing (DTP) - Draft Amendments to Parts 1-3: Transaction Processing Security

WDAMs ((SC21 N6232) to ISO 10026-1,2,3) 1994

Informational

(Draft)

3.9.7.4.2 Alternate specifications. There are no alternative specifications.

3.9.7.4.3 Standards deficiencies. ISO Transaction Processing Security work (WDAMs to ISO 10026-1,2,3) is in the early stages. Its content is not defined, and it cannot be used for procurement. ISO 10164-8 does not define a security audit, or explain how to perform one. It does not define implementation aspects, occasions where the use of the security audit trail function is appropriate, or the services necessary for the establishment and normal or abnormal release of a management association.

There is a need for a standard for programming interfaces to support development of portable tools for audit trail analysis and configuration.

3.9.7.4.4 Portability caveats. Proposed amendments to ISO 10026 have ceased. This is a high portability risk area.

3.9.7.4.5 Related standards. The following guidelines support the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-011, Version 1, 1 August 1990, Trusted Network Interpretation Environments Guideline - Guidance for Applying the Trusted Network Interpretation

c. NCSC-TG-001, Version 2, June 1988, A Guide to Understanding Audit in Trusted Systems

3.9.7.4.6 Recommendations. The mandated standard is recommended.

3.9.7.5 Security alarm reporting. (This BSA appears in part 7, part 9, part 10, and part 11.) Security alarm reporting is the capability to receive notifications of security-related events, alerts of any misoperations in security services and mechanisms, alerts of attacks on system security, and information as to the perceived severity of any misoperation, attack, or breach of security.

3.9.7.5.1 Standards. Table 3.9-41 presents standards for security alarm reporting.

TABLE 3.9-41 Security alarm reporting standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

NMF

OMNIPoint 1 (Adopts ISO Profile Sets 11183-X, 12059-X, and 12060-X, includes ISO/IEC 10164-X)

OMNIPoint 1:1993

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 7: Security Alarm Reporting Function (same as ITU-T X.736)

10164-7:1992

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

3.9.7.5.2 Alternate specifications. There are no alternative specifications.

3.9.7.5.3 Standards deficiencies. FIPS PUB 179-1 supersedes FIPS PUB 179. ISO 10164-7 does not define implementation aspects, specify the manner in which management is accomplished by the user of the Security Alarm Reporting Function (SARF), define interactions that result in the use of the SARF, or specify the services necessary for the establishment and normal and abnormal release of a management association.

3.9.7.5.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.7.5.5 Related standards. There are no related standards.

3.9.7.5.6 Recommendations. There are no recommended standards for security alarm reporting.

3.9.7.6 Personal authentication. (This BSA appears in part 2, part 3, part 9, and part 10.) Personal authentication supports the accountability objective of being able to trace all security relevant events to individual users. In addition to supporting unique identification, standards are provided to authenticate the claimed identity.

3.9.7.6.1 Standards. Table 3.9-42 presents standards for personal authentication.

TABLE 3.9-42 Personal authentication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

NIST

Password Usage

FIPS PUB 112: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

GPC

NIST

Guidelines on Evaluation of Techniques for Automated Personal Identification

FIPS PUB 48:1977

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - The Directory: Authentication Framework edition 2 (Same as ITU-T X.509:1993)

9594-8.2:1993

Informational

(Approved)

GPC

NIST

Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 190:1994

Informational

(Approved)

CPC

IETF

A One-Time Password System

RFC 1938: 1996

Emerging

(Draft)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

CPC

IETF

The Kerberos Network Authentication Service (V5)

RFC 1510:1993

Informational

(Draft)

3.9.7.6.2 Alternate specifications. There are no alternative specifications.

3.9.7.6.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.6.4 Portability caveats. OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.9.7.6.5 Related standards. The following standards are related to personal authentication standards (particularly TCSEC):

a. DOD 5200.28-STD, DOD Trusted Computer Systems Evaluation Criteria

b. NCSC-TG-017, Version 1, "A Guide to Understanding Identification and Authentication in Trusted Systems

c. CSC-STD-002-85, "Password Management Guideline"

d. NCSC-WA-002-85, "Personal Computer Security Considerations"

e. ITU-T X.509 (1993) (same as ISO 9594-8), The Directory: Authentication Framework

3.9.7.6.6 Recommendations. The mandated standards are recommended.

3.9.7.7 Entity authentication. (This BSA appears in part 8, part 9, part 10, and part 11.) Entity authentication standards address data, processes, systems, and enterprises.

3.9.7.7.1 Standards. Table 3.9-43 presents standards for entity authentication.

TABLE 3.9-43 Entity authentication standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

GPC

NIST

Computer Data Authentication

FIPS PUB 113:1985

Informational

(Approved)

GPC

NIST

Entity Authentication Using Public Key Cryptography

FIPS PUB 196:1996

Emerging

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

Financial Transactions - Retail Banking Security Requirements for Message Authentication

9807

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 1: General Model

9798-1:1991

Informational

(Approved)

IPC

ISO

Entity Authentication Mechanisms - Part 3: Entity Authentication Using a Public Key Algorithm

9798-3:1993

Informational

(Approved)

GPC

NIST

Guideline for Use of Advanced Authentication Technology Alternatives

FIPS PUB 190:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 2: Mechanisms Using Symmetric Encipherment Algorithms

9798-2:1994

Informational

(Approved)

IPC

ISO

Entity Authentication - Part 4: Mechanisms Using a Cryptographic Check Function

9798-4:1995

Informational

(Approved)

CPC

X/Open

Security Interface Specification: Auditing and Authentication

S020: 1990

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

CPC

IETF

The Kerberos Network Authentication Service (V5)

RFC 1510:1993

Informational

(Draft)

IPC

ISO

Entity Authentication Mechanisms, Part 5: Entity Authentication Using Zero Knowledge Techniques

9798-5:1993

Informational

(Draft)

3.9.7.7.2 Alternate specifications. There are no alternative specifications.

3.9.7.7.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.7.4 Portability caveats. OSF DCE Version 1.1's authentication service is based on Kerberos Version 5 (RFC 1510), but is not totally compatible with RFC 1510. DCE 1.2.2 adds testing and official support for Kerberos Version 5.

3.9.7.7.5 Related standards. The following standards are related to entity authentication:

a. DOD NCSC-TG-017, Version 1, September 1991, Guide to Understanding Identification and Authentication in Trusted Systems.

b. FIPS PUB 196, 11 October 1996.

FIPS PUB 196 becomes effective 6 April 1996. It is based on ISO/IEC 9798-3:1993 and specifies two challenge-response protocols by which entities in a computer system may authenticate their identities to one another. FIPS PUB 196 is for use in public key based challenge-response and authentication systems at the application layer within computer and digital telecommunications systems.

3.9.7.7.6 Recommendations. The mandated standards are recommended.

3.9.7.8 System access control. (This BSA appears in part 4, part 9, part 10, and part 11.) System access control standards provide high-level guidance on access control frameworks and implementation.

3.9.7.8.1 Standards. Table 3.9-44 presents standards for system access control.

TABLE 3.9-44 System access control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Security Services

DCE 1.1 Security Services: 1994

Mandated

(Approved)

CPC

OSF

Distributed Computing Environment (DCE) Rev. 1.2.2

DCE Rev. 1.2.2:1996

Informational

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO/IEC

OSI Systems Management, Part 9: Objects and Attributes for Access Control

10164-9:1995

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks in Open Systems, Part 3: Access Control

10181-3

Informational

(Draft)

3.9.7.8.2 Alternate specifications. There are no alternative specifications.

3.9.7.8.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.8.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.7.8.5 Related standards. The following guidelines support the TCSEC standard:

a. NCSC-TG-003, Version 1, September 1987, A Guide to Understanding Discretionary Access Control in Trusted Systems

b. NCSC-TG-028, Version 1, May 1992, Assessing Controlled Access Protection

c. NCSC-TG-020-A, August 1989, Trusted UNIX Working Group (TRUSIX) Rationale for Selecting Access Control List Features for the UNIX System

3.9.7.8.6 Recommendations. The mandated standards are recommended.

3.9.7.9 Network access control. (This BSA appears in part 7, part 9, and part 10.) Access control is the prevention of unauthorized use of a resource, including its use in an unauthorized manner.

3.9.7.9.1 Standards. Table 3.9-45 presents standards for network access control.

TABLE 3.9-45 Network access control standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Information Technology - Defense Standardized Profiles AMHXn(D)- Message Handling Systems - Message Security Protocol (MSP) Parts 1-5

MIL-STD-2045-18500: 1993

Mandated

(Approved)

GPC

NSA

Secure Data Network System (SDNS) Security Protocol 3 (SP3)

SDN.301, Revision 1.5: 1989

Mandated

(Approved)

NPC

IEEE

Standard for Interoperable LAN Security - Part B: Secure Data Exchange (SDE)

802.10b:1992

Legacy

(Approved)

IPC

ISO/IEC

OSI Common Management Information Services (CMIS) Definition, with Amendment 4: Access Control

9595:1991/ AM4:1992

Informational

(Approved)

IPC

ISO

Transport Layer Security Protocol (TLSP) (Includes Amendment 1)

10736:1994

Informational

(Approved)

IPC

ISO

Network Layer Security Protocol (NLSP)

11577:1994

Informational

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179-1:1995

Informational

(Approved)

GPC

NIST

Guidelines for Security of Computer Applications

FIPS PUB 83:1980

Informational

(Approved)

GPC

NSA

Secure Data Network System (SDNS) Security Protocol 4 (SP4)

SDN.401, Rev. 1.3:1989

Informational

(Approved)

GPC

NSA

Message Security Protocol (MSP)

SDN.701, v. 4.0, Rev. A: 1997

Emerging

(Approved)

GPC

NSA

Message Security Protocol (MSP)

SDN.701, Rev. 3.0: 1994

Legacy

(Approved)

GPC

NIST

Government Network Management Profile (GNMP)

FIPS PUB 179:1992

Informational

(Superseded)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - The Directory - Parts 1-4 DAM1: Access Control

9594-1,2,3,4:1990/ DAM1

Informational

(Draft)

IPC

ISO/IEC

Information Technology - Open Systems Interconnection - The Directory - Part 8: Authentication Framework, DAM1: Access Control

9594-8:1990/ DAM1

Informational

(Draft)

IPC

ISO

OSI File Transfer, Access and Management (FTAM) - Parts 1-4: Amendment 4: Enhancement to FTAM Security Services

8571-1,2,3,4:1988/ WDAM4:1993

Informational

(Draft)

3.9.7.9.2 Alternate specifications. There are no alternative specifications.

3.9.7.9.3 Standards deficiencies. Deficiencies in the existing standards are unknown. FIPS PUB 179-1 supersedes FIPS PUB 179.

3.9.7.9.4 Portability caveats. Proposed security enhancements to FTAM (WDAM4 to ISO 8571) has ceased. This is a high portability risk area because no standards exist.

3.9.7.9.5 Related standards. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation, and NCSC-TG-011, Version 1, August 1990, Trusted Networks Interpretation Environments Guideline - Guideline for Applying the Trusted Network Interpretation, supports the DOD 5200.28-STD.

3.9.7.9.6 Recommendations. The mandated standards are recommended.

MIL-STD-2045-18500 describes the security provided by MSP. It should be used for DOD message systems that are required to exchange classified and sensitive but unclassified information. It is based on Version 3.0 of the MSP documented in SDN.701, "Secure Data Network System (SDNS) Message Security Protocol," Revision 1.5, 1 August 1989. MSP is under revision to Version 4.0 to accommodate, in part, Allied requirements. This DOD Standardized Profile (DSP) standard will be replaced by a portion of the U.S. Supplement to ACP 123 or ACP 120, Common Security Protocol, when the revision to MSP is complete.

SDN.701, Rev.3.0, is used with DMS, Phase 1. It is for use with legacy systems only.

SP3 provides connectionless security services and is the basis for ISO 11577. SP3 is designed to be used at the top of layer 3.

The work on File Transfer, Access, and Management (FTAM) security (WDAM4 to ISO 8571) security enhancements has been suspended. Procurements requiring access control for FTAM and transaction processing should not use these standards.

IEEE 802.10b is for use with legacy LANs only.

3.9.7.10 Certification and accreditation. (This BSA appears in part 2, part 9, and part 10.) Certification and accreditation constitute a set of procedures and judgments leading to a determination of the suitability of the system to operate in the targeted operational environment.

Accreditation is the official management authorization to operate a system. The accreditation normally grants approval for the system to operate (a) in a particular security mode, (b) with a prescribed set of countermeasures (administrative, physical, personnel, communications security, emissions, and computer security controls), (c) against a defined threat and with stated vulnerabilities and countermeasures, (d) within a given operational concept and environment, (e) with stated interconnections to other systems, (f) at an acceptable level of risk for which the accrediting authority has formally assumed responsibility, and (g) for a specified period of time. The Designated Approving Authority(s) (DAA) formally accepts security responsibility for the operation of the system and officially declares that the specified system will adequately protect against compromise, destruction, or unauthorized modification under stated parameters of the accreditation. The accreditation decision affixes security responsibility with the DAA and shows that due care has been taken for security in accordance with the applicable policies.

An accreditation decision is in effect after the issuance of a formal, dated statement of accreditation signed by the DAA, and remains in effect for the specified period of time (varies according to applicable policies). A system processing classified or sensitive unclassified information should be accredited prior to operation or testing with live data unless a written waiver is granted by the DAA. In some cases (e.g., when dealing with new technology, during a transition phase, or when additional time is needed for more rigorous testing), the DAA may grant an interim approval to operate for a specified period of time. At the end of the specified time period, the DAA must make the final accreditation decision.

Certification is conducted in support of the accreditation process. It is the comprehensive analysis of both the technical and nontechnical security features and other safeguards of a system to establish the extent to which a particular system meets the security requirements for its mission and operational environment. A complete system certification must consider factors dealing with the system in its unique environment, such as its proposed security mode of operation, specific users, applications, data sensitivity, system configuration, site/facility location, and interconnections with other systems. Certification should be done by personnel who are technically competent to assess the systems ability to meet the security requirements according to an acceptable methodology. The resulting documentation of the certification activities is provided to the DAA to support the accreditation decision. Many security activities support certification, such as risk analysis, security test and evaluation, and various types of evaluations.

Ideally, certification and accreditation procedures encompass the entire life cycle of the system. Ideally, the DAA is involved from the inception of the system to ensure that the accreditation goals are clearly defined. A successful certification effort implies that system security attributes were measured and tested against the threats of the intended operational scenarios. Additionally, certification and accreditation are seen as continuing and dynamic processes; the security state of the system needs to be tracked and assessed through changes to the system and its operational environment. Likewise, the management decision to accept the changing system for continued operation is an ongoing decision process.

Standards for certification and accreditation services provide definitions and procedures for the testing and accreditation of computer systems in so far as their conformance with security standards is concerned.

3.9.7.10.1 Standards. Table 3.9-46 presents standards for certification and accreditation.

TABLE 3.9-46 Certification and accreditation standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

GPC

NIST

Guideline for Computer Security Certification and Accreditation

FIPS PUB 102:1983

Informational

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

GPC

DOD

DOD Information Technology Certification and Accreditation Process

DITSCAP: 1996

Informational

(Draft)

3.9.7.10.2 Alternate specifications. No other consortia or de facto specifications are available.

3.9.7.10.3 Standards deficiencies. Because of its age, FIPS PUB 102 does not include services for the certification and accreditation of all modern security concepts.

Certification and accreditation evaluation criteria that address cuttent information technology, such as distributed computing and networking, are needed. As new criteria such as the Common Criteria emerge, revision of existing certification and accreditation guidelines may be required.

3.9.7.10.4 Portability caveats. There are no portability problems related to the existing specifications.

3.9.7.10.5 Related standards. NCSC-TG-029, "Introduction to Certification and Accreditation," January 1994, discusses basic concepts related to certification and accreditation and is the first of a series of guidelines in the "Rainbow Series" supporting the Trusted Computer System Evaluation Criteria (TCSEC) standard.

3.9.7.10.6 Recommendations. The mandated standard is recommended.

Procurements that require that an AIS be certified and/or accredited must reference DOD Directive 5200.28 and applicable designated approving authority guidance. DOD Directive 5200.28, "Security Requirements for Automated Information Systems (AISs)," requires certification and accreditation of AIS. FIPS PUB 102, Guidelines for Computer Security and Accreditation provides Federal guidelines for certification and accreditation. Because of its age, this FIPS PUB does not include services for the certification and accreditation of all modern security concepts. DOD 5200.28-STD provides criteria to assess security assurances of trusted systems to specific classes. DCID 1/16 provides security requirements for systems processing intelligence information.

The DISA CISS and NSA are each developing documents that will standardize the certification and accreditation process within DOD. Each document is in draft form; final documents are expected to be issued in 1997. The NSA document, "Certification and Accreditation Process Handbook for Certifiers," will be published as a "Rainbow" series document supporting the TCSEC standard. This NSA handbook focuses on certification and accreditation of standalone systems. The DISA CISS document, "DOD Information Technology Certification and Accreditation Process" (DITSCAP), will be published as a DOD publication. The DITSCAP focuses on certification and accreditation in conjunction with the programmatic aspects of the DII.

3.9.7.11 Detection and notification. (This BSA appears in part 2, part 9, and part 10.) Detection and notification objectives ensure that a secure system has the capability to recognize that it is: under attack; may potentially enter a non-available state; has been compromised; or has failed in a potentially compromising manner. Guidance in this area focuses on reporting detected security critical conditions to proper authorities, and implementing predetermined corrective actions.

3.9.7.11.1 Standards. Table 3.9-47 presents standards for detection and notification.

TABLE 3.9-47 Detection and notification standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

3.9.7.11.2 Alternate specifications. There are no alternative specifications.

3.9.7.11.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.11.4 Portability caveats. Portability problems in the existing standards are unknown.

3.9.7.11.5 Related standards. NSA's C-Technical Report-001, Computer Viruses: Prevention, Detection, and Treatment, and NIST SP 800-5, A Guide to the Selection of Anti-Virus Tools and Techniques, provide guidance on computer viruses. The following specifications support the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-015, Version 1, October 1989, A Guide to Understanding Trusted Facility Management

c. NCSC-TG-016, Version 1, October 1992, Guidelines for Writing Trusted Facility Manuals

3.9.7.11.6 Recommendations. The mandated standard is recommended.

3.9.7.12 Security recovery. (This BSA appears in part 2, part 9, and part 10.) Recovery guidance defines provisions to allow system personnel or processes with the proper authorizations to repair or eliminate the cause of security relevant failures, isolate compromised portions of the system, and revalidate proper operations prior to returning the system to a fully operational secure state.

3.9.7.12.1 Standards. Table 3.9-48 presents standards for security recovery.

TABLE 3.9-48 Security recovery standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

The DOD Trusted Computer Systems Evaluation Criteria

DOD 5200.28-STD: 1985

Mandated

(Approved)

IPC

CCEB

Common Criteria for Information Technology Security Evaluation, (CC) Version 1.0

CC Version 1.0: 1996

Emerging

(Draft)

3.9.7.12.2 Alternate specifications. There are no alternative specifications.

3.9.7.12.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.12.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.7.12.5 Related standards. The following specifications are related to the TCSEC standard:

a. NCSC-TG-005, Version 1, July 1987, Trusted Network Interpretation

b. NCSC-TG-022, Version 1, December 1991, A Guide to Understanding Trusted Recovery in Trusted Systems

c. NCSC-TG-015, Version 1, October 1989, A Guide to Understanding Trusted Facility Management

d. NCSC-TG-016, Version 1, October 1992, Guidelines for Writing Trusted Facility Manuals

3.9.7.12.6 Recommendations. The mandated standard is recommended.

3.9.7.13 Database security. (This BSA appears in part 4, part 9, and part 10.) Database security standards provide protection for stored data from unauthorized access, modification, and denial of service.

3.9.7.13.1 Standards. Table 3.9-49 presents standards for database security.

TABLE 3.9-49 Database security standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Trusted Database Management System Interpretation of the Trusted Computer Systems Evaluation Criteria

NCSC-TG-021, Version 1: 1991

Mandated

(Approved)

IPC

ISO

OSI Basic Reference Model, Part 2: Security Architecture (same as CCITT X.800:1991)

7498-2:1989

Informational

(Approved)

GPC

NIST

Database Language SQL (Adopts ANSI X3.135-1992 (same as ISO 9075:1992))

FIPS PUB 127-2:1993

Informational

(Approved)

GPC

NIST

Information Resource Dictionary System (IRDS) (adopts ANSI X3.138-1988 and X3.138A-1991)

FIPS PUB 156:1989

Informational

(Approved)

NPC

ANSI

Database Language SQL

X3.135-1992

Informational

(Approved)

IPC

ISO

Database Language SQL (same as ANSI X3.135-1992)

9075:1992

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Framework

10027:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Service Definition for the Commitment, Concurrency, and Recovery (CCR) Service Element

9804:1990

Informational

(Approved)

IPC

ISO/IEC

OSI Protocol Specification for the Commitment, Concurrency, and Recovery (CCR) Service Element

9805:1990

Informational

(Approved)

NPC

ANSI

Information Resource Dictionary System (IRDS)

X3.138-1988

Informational

(Approved)

IPC

ISO/IEC

Information Resource Dictionary System (IRDS) Services Interface Amendment 1: C Language Binding

10728 AMD 1:1994

Informational

(Draft)

3.9.7.13.2 Alternate specifications. There are no alternative specifications.

3.9.7.13.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.13.4 Portability caveats. Portability problems with the existing standards are unknown.

3.9.7.13.5 Related standards. DOD 5200.28-STD, 26 December 1995, DOD Trusted Computer Systems Evaluation Criteria, is related to NCSC-TG-021. The following specifications are related to DOD 5200.28-STD:

a. NCSC-TG-018, Version 1, July 1992, A Guide to Understanding Object Reuse in Trusted Systems

b. NCSC-TG-025, Version 2, September 1991, A Guide to Understanding Data Remnants in Automated Information Systems

3.9.7.13.6 Recommendations. The mandated standard is recommended.

3.9.7.14 Security association and key management. (This BSA appears in part 7, part 9, and part 10.) A security association is the totality of communication and security mechanisms and functions (e.g., communications protocols, security protocols, doctrinal mechanisms, security-critical mechanisms and functions) that securely binds together two security contexts in different end systems or relay systems supporting the same information domain. A security association is an application association that includes additional support from security functions and mechanisms. Key management provides procedures for handling cryptographic keying material to be used in symmetric or asymmetric cryptographic mechanisms. It includes key generation, key distribution, key storage, key archiving, and key deletion.

3.9.7.14.1 Standards. Table 3.9-50 presents standards for security association and key management.

TABLE 3.9-50 Security association and key management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

NSA

Key Exchange Algorithm

R21-TECH-23-94: 1994

Mandated

(Approved)

GPC

NSA

Secure Data Network System (SDNS) Key Management Protocol (KMP)

SDN.903, Version 3.2: 1989

Mandated

(Approved)

GPC

NIST

Key Management Using ANSI X9.17

FIPS PUB 171:1992

Informational

(Approved)

IPC

ISO

Generic Upper Layer Security (GULS) - Part 1: Overview, Models, and Notation

11586-1:1994

Informational

(Approved)

IPC

ISO

Generic Upper Layer Security (GULS) - Part 2:Security Exchange Service Element Definition

11586-2:1994

Informational

(Approved)

IPC

ISO

Generic Upper Layer Security (GULS) - Part 3: Security Exchange Service Element Protocol Specification

11586-3:1994

Informational

(Approved)

IPC

ISO

Banking Key Management (wholesale)

8732:1988

Informational

(Approved)

NPC

ANSI

Financial Institution Key Management (wholesale)

X9.17-1991

Informational

(Approved)

NPC

IEEE

Standard for Interoperable LAN Security - Part C: Key Management Protocol (KMP)

802.10c

Emerging

(Draft)

IPC

ISO/IEC

OSI Security Frameworks for Open Systems Part 8: Key Management

10181-8

Informational

(Draft)

CPC

IETF

Internet Security Association and Key Management Protocol (ISAKMP)

draft-ietf-ipsec-isakmp-07.txt,.ps, 21 February 1997

Informational

(Draft)

CPC

IETF

The Photuris Session Key Management Protocol

draft-simpson-photuris-11.txt, 13 June 1996

Informational

(Draft)

CPC

IETF

Simple Key Management for Internet Protocols (SKIP)

draft-ietf-ipssec-skip-07.txt, August 1996

Informational

(Draft)

CPC

IETF

The Oakley Key Determination Protocol

draft-ietf-ipsc-oakley-01.txt, 5/10/96

Informational

(Draft)

NPC

IEEE

Standard for Public-Key Cryptography

P1363

Informational

(Formative)

3.9.7.14.2 Alternate specifications. There are no alternative specifications.

3.9.7.14.3 Standards deficiencies. There is a lack of guidance for establishing a Public Key Infrastructure (PKI) to automatically manage public keys through the use of public key certificates. In April 1994, NIST, in conjunction with seven other federal agencies, completed a study on automated management of public keys and associated public key certificates on a nationwide basis. Based on the recommendations of the study, NIST is establishing a PKI pilot project to provide public key certificate services for several participating government agencies.

3.9.7.14.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.7.14.5 Related standards. There are no related standards.

3.9.7.14.6 Recommendations. The mandated standards are recommended. In FORTEZZA applications, the NSA-developed Key Exchange Algorithm, R21-TECH-23-94, must be used.

IEEE P1363, Standard for Public-Key Cryptography, is under development, with the first version expected to be ready for balloting in 1997.

The IETF's IP Security Protocol (IPSEC) Working Group (WG) is developing an Internet Key Management Protocol (IKMP) that will be specified as an application layer protocol independent of the lower layer security protocol. The IKMP will be based on ISAKMP/Oakley work begun in the Internet Draft documents for ISAKMP and the Oakley Key Determination Protocol.

3.9.7.15 Registration of cryptographic techniques. (This BSA appears in part 9 and part 10.) These standards provide procedures for the registration of cryptographic algorithms in a standard format with a registration authority. The need for these registration services is determined by the security architecture of the system in question. These are not implementable specifications and no conformance test is required.

3.9.7.15.1 Standards. Table 3.9-51 presents standards for registration of cryptographic techniques.

TABLE 3.9-51 Registration of cryptographic techniques standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO

Procedures for the Registration of Cryptographic Algorithms

9979:1991

Informational

(Approved)

3.9.7.15.2 Alternate specifications. No other consortia or de facto specifications are available.

3.9.7.15.3 Standards deficiencies. Deficiencies in the existing standards are unknown.

3.9.7.15.4 Portability caveats. Portability problems related to the existing specifications are unknown.

3.9.7.15.5 Related standards. No standards are related to registration of cryptographic techniques.

3.9.7.15.6 Recommendations. Procurements requiring that all cryptographic algorithms offered are registered with a registration authority in a standard format should specify conformance with ISO 9979. The NIST document, NISTIR 5308, "General Procedures for Registering Computer Security Objects," December 1993, describes the object-independent procedures for operating the Computer Security Objects Register (CSOR) established by NIST. Initially, the only family of objects registered in the CSOR is network security labels; however, plans include adding cryptographic algorithm modes of operation to the CSOR.

3.9.8 Other management services.

3.9.8.1 Database administration. (This BSA appears in part 4 and part 9.) Data administration is the process of the analysis, classification, and maintenance of an organization's data and data relationships. It includes the development of data models, data warehousing, and data dictionaries, which combined with transaction processing, are the raw materials for database design.

3.9.8.1.1 Standards. Table 3.9-52 presents standards for database administration.

TABLE 3.9-52 Database administration standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

GPC

DOD

Data Element Standardization Procedures, January 1993

Manual 8320.1-M-1

Mandated

(Approved)

GPC

NIST

Guide to Data Entity Naming Conventions

NBS SP 500-149 of Oct. 1987

Informational

(Approved)

GPC

DOD

Defense Data Repository System

End User Manual ver. 2.0 of 10 August 1993

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 3: Basic Attributes of Data Elements

11179-3:1994

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 4: Rules and Guidelines for the Formulation of Data Definitions

11179-4:1995

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 5: Naming and Identification Principles for Data Elements

11179-5:1995

Informational

(Approved)

IPC

ISO/IEC

Specification and Standardization of Data Elements, Part 6: Registration of Data Elements

11179-6

Informational

(Draft)

GPC

DOD

DOD Data Administration

DODD 8320.1 of 9/26/1991

Informational

(Superseded)

3.9.8.1.2 Alternative specifications. The only other available specifications are proprietary database utilities.

3.9.8.1.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard.

3.9.8.1.4 Portability caveats. This is a high portability risk area because no standards exist.

3.9.8.1.5 Related standards. The following standards are related to database administration or database administration standards:

a. ISO 7498-4:1989: Management Framework

b. ISO 9075: SQL

c. ISO 9579-1: RDA (Generic Model, Service and Protocols)

d. ISO 9579-2: RDA (SQL Specialization)

e. ISO 9595:1991: CMIS.

f. ISO 9596-1:1991: CMIP.

g. ISO/IEC 9945-1: (IEEE P1003.1)

h. ISO 10164-1:1993: Object Management Function

i. ISO 10165-1:1991: SMI - Part 1 Management Information Model

j. ISO 10165-2:1991: SSMI - Part 2 DMI

k. ISO 10165-4:1992: Guidelines for the Definition of Managed Objects (GDMO)

l. ANSI X3.135-1992: SQL

m. ANSI X3.168-1989: Embedded SQL

n. NIST FIPS 127-2: Database Language SQL

o. NIST FIPS 146-1: Government Open Systems Interconnection Profile (GOSIP)

p. NIST FIPS 156: IIRDS

q. NIST FIPS 193: SQL Environments

3.9.8.1.6 Recommendations. DODD 8320.1 is recommended for data administration. Database administration systems should be compatible with and integrated with the SQL database language set forth in FIPS PUB 127-2. Furthermore, all database administration systems offered as a result of this procurement's requirements shall be integrated with ISO 9579-1 RDA (Generic Model, Service and Protocol), ISO 9579-2 Remote Database Access (SQL Specialization) of December 1993, and NIST FIPS PUB 193, SQL Environments.

3.9.8.2 Object-oriented database management. (This BSA appears in both Part 4 and Part 9.) Standards for object-oriented database management provide facilities and interfaces to manage object databases (databases that store, manipulate, and retrieve data represented as objects).

3.9.8.2.1 Standards. Table 3.9-53 presents standards for object-oriented database management.

TABLE 3.9-53 Object-oriented database management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

CPC

ODMG

Object Database Management Group (ODMG) - 93

ODMG-93, Release 1.1

Informational

(Approved)

CPC

ODMG

Object Database Management Group (ODMG) 9x

ODMG-9x

Emerging

(Formative)

NPC

ANSI

X3 Database System Study Group (DBSSG)

X3 Study

Informational

(Formative)

CPC

OMG

Preliminary work on object-oriented database management

TBD-Preliminary work on object-oriented database management

Informational

(Formative)

3.9.8.2.2 Alternative specifications. Microsoft's Object Database Connectivity (OBDC) API specification for MS-Windows applications is also available.

3.9.8.2.3 Standards deficiencies. Deficiencies in the standards are unknown, since these services are not part of any formal standard, but the Microsoft specification has insufficient drivers available.

3.9.8.2.4 Portability caveats. This is a high portability risk area because no standards exist, and many Microsoft PC products do not comply with most Unix- and Portable Operating System Interfaces for Computers (POSIX)-based systems.

3.9.8.2.5 Related standards. No standards are related to object-oriented database management standards.

3.9.8.2.6 Recommendations. There is no recommendation at this time.

3.9.8.3 Floppy disk format and handling. (This BSA appears both in part 8 and part 9.) Floppy disk format and handling standards provide formats and interfaces for the exchange, backup, and restoration of data to or from floppy disks.

3.9.8.3.1 Standards. Table 3.9-54 presents standards for floppy disk format and handling.

TABLE 3.9-54 Floppy disk format and handling standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Portable Operating System Interface (POSIX) Part 1: System API (Replaces ISO 9945-1:1990 and incorporates IEEE 1003.1b, 1003.1c, and 1003.1i)

9945-1:1996

Mandated

(Approved)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

GPC

NIST

Portable Operating System Interface (POSIX) - System Application Program Interface/ C Language (adopts ISO/IEC 9945-1:1990)

FIPS PUB 151-2:1993

Informational

(Approved)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API)[C language], (as profiled by FIPS PUB 151-2:1993)

9945-1:1990

Informational

(Superseded)

CPC

X/Open

System V Interface Definition (SVID) (replaced by Single UNIX Specification (Spec. 1170))

SVID Issue 4

Informational

(Superseded)

3.9.8.3.2 Alternative specifications. The following alternative specifications are also available:

a. Sun Microsystems' SunOS/Solaris command "bar"
b. OSF: OSF/1 "tar" and "cpio" utilities.

3.9.8.3.3 Standards deficiencies. POSIX and Unix have very poor floppy disk handling capabilities. Most standards related to floppy disks concern logical interfaces that permit the interconnection of floppy disk peripherals.

3.9.8.3.4 Portability caveats. The "bar" is not a standard. However, it is widely used because of Sun's large installed base. It is presented as an example of a capability needing to be standardized, as well as an example of the kind of capability that could be specified.

3.9.8.3.5 Related standards. No standards are related to floppy disk format standards.

3.9.8.3.6 Recommendations. ISO/IEC 9945-2 disk format services "pax" are expected to replace "tar" and "cpio" utilities in POSIX.1. X/Open SUS includes the POSIX.2 utilities.

3.9.8.4 POSIX tape labeling and tape volume processing. (This BSA appears both in part 8 and part 9.) Tape labels are a fixed portion of data stored on tape media and containing certain types of administrative information automatically readable by tape-handling software. Among the information typically stored on tape labels are the identification of the media content, ownership of the media content, access control information for the media content, and the format of the rest of the information on the media.

3.9.8.4.1 Standards. Table 3.9-55 presents standards for POSIX tape labeling and tape volume processing.

TABLE 3.9-55 POSIX tape labeling and tape volume processing standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ECMA

File Structure and Labeling of Magnetic Tapes for Information Interchange

13 (1985)

Informational

(Approved)

IPC

ECMA

Magnetic Tape Cassette Labeling and File Structure for Information Interchange

41 (1973)

Informational

(Approved)

NPC

IEEE

POSIX, Part 1: System API - Amendment 1: System API Extensions (C language)

P1003.1a

Emerging

(Draft)

NPC

IEEE

POSIX - Part 1: System API Supplement - Removable Media Support

P1003.1k

Emerging

(Formative)

3.9.8.4.2 Alternative specifications. The only other available specifications are proprietary.

3.9.8.4.3 Standards deficiencies. The P1003.1a draft standard does not address the issue of processing several files as if they were a single entity.

Traditional Unix systems do not provide mechanisms for protected access to devices or media, nor do they generally provide mechanisms for label processing or transparent volume switching.

3.9.8.4.4 Portability caveats. To provide tape handling portability, a standard must specify the handling of ANSI/ISO labeled tape and IBM labeled tape. IBM labeled tapes, although not a strict standard, represent vast numbers of labeled tapes already in existence. IBM labeled tapes are roughly analogous to the ANSI standard, except the labels are written with the EBCDIC character set rather than with ASCII.

It is not certain, even within the proposed standard, how to process information when some of it is on 9-track tape and some on 8mm (Exabyte) tape, or some on labeled and some on unlabeled tape. This may be a limitation of the standard.

3.9.8.4.5 Related standards. The following standards are related to POSIX tape labeling and tape volume processing standards:

a. ISO/IEC 9945-1:1996: POSIX Part 1: System Application Programming Interface.

b. ISO/IEC 9945-2:1992: POSIX Part 2: Shell and Utility.

c. IEEE 1003.5:1992: Ada Language Binding to POSIX.

d. IEEE P1003.1e: Security Interface Standards for POSIX.

e. IEEE P1387.1: POSIX System Administration - Part 1: Overview.

f. IEEE 1003.9:1992: Standard Fortran Language Bindings to POSIX.

3.9.8.4.6 Recommendations. There are no recommendations.

3.9.8.5 Print management. (This BSA appears both in part 8 and part 9.) The print services are used by management and user applications to send a file to the printer, cancel the print job, and get printer status information. The printing systems program interface is used as the base for the POSIX printing management standard. Printing management standards also provide services and interfaces for transparent remote printing, output spooling, spool queue management, and scheduling.

3.9.8.5.1 Standards. Table 3.9-56 presents standards for print management.

TABLE 3.9-56 Print management standards

Standard Type

Sponsor

Standard

Standard Reference

Status

DoD

(Lifecycle)

IPC

ISO/IEC

Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (as profiled by FIPS PUB 189:1994)

9945-2:1993

Mandated

(Approved)

CPC

X/Open

Common Desktop Environment (CDE); XCDE Services and Applications

C323 (4/95)

Mandated

(Approved)

CPN-C

Microsoft

Window Management and Graphics Device Interface, Volume 1 Microsoft Win32 Programmers' Reference Manual, 1993, Microsoft Press

Win32 APIs

Mandated

(Approved)

CPC

X/Open

Single UNIX Specification (Spec. 1170) Commands and Utilities, Issue 4, Version 2 (part of XPG4)

C436 (9/94)

Emerging

(Approved)

IPC

ECMA

Method for Measuring Printer Throughput

132 (1991)

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Text and office systems - Document Printing Application (DPA), Part 1: Abstract service definition and procedures

10175-1:1996

Informational

(Approved)

IPC

ISO/IEC

Information Technology - Text and office systems - Document Printing Application (DPA) - Part 2: Protocol specification

10175-2:1996

Informational

(Approved)

NPC

IEEE

POSIX: System Administration - Part 4: Print Administration (former P1003.7.1)

P1387.4

Emerging

(Draft)

CPC

OSF

DME Print Service (PRS) (part of OSF Personal Computer Services)

DME PRS

Informational

(Not Recommended (No commercial products))

3.9.8.5.2 Alternative specifications. The following specifications are also available:

a. MIT: Palladium (the basis for DME print management).

b. Berkeley 4.2/4.3 Unix.

c. Siemens/Nixdorf: Printing Management (the basis for UI's distributed printing management specification and USL's reference implementation).

3.9.8.5.3 Standards deficiencies. SVID, OSF/1, and Berkeley Unix have no features to control the formatting or scheduling of print jobs. The SVID, OSF/1, and Berkeley Unix are designed for centralized environments. No Ada bindings exist for print management standards. POSIX.2 specifies only a minimal "lp" command, suitable for submitting print jobs; no printer administration facilities are provided.

3.9.8.5.4 Portability caveats. The System V Unix "lp" printing system, from which the POSIX "lp" command is derived, is not compatible with the Berkeley Unix "lpr" printing system.

The OSF DME distributed print management is based on MIT's Palladium. It has a different interface from UI/USL's distributed print management, which is based on the Siemens-Nixdorf Xprint program and, therefore, is incompatible.

3.9.8.5.5 Related standards. The following standards are related to print management services or standards:

a. ISO/IEC 9945-1:1996: POSIX Part 1 - System Application Programming Interface.

b. ISO 8824:1990: Abstract Syntax Notation 1 (ASN.1).

c. ISO 8825:1990: Basic Encoding Rules for ASN.1.

d. ISO 9072:1989: Remote Operations Service Element (ROSE).

e. ISO/IEC 9595: Common Management Information Service (CMIS).

f. ISO/IEC 9596: Common Management Information Protocol (CMIP).

g. ISO/IEC DIS 11578.2: Remote Procedure Call.

h. IEEE P1003.1e: Security Interface Standards for POSIX.

i. Internet RFC 1155: Structure and Identification of Management Information for TCP/IP-based Internets.

j. Internet RFC 1157: Simple Network Management Protocol.

k. Internet RFC 1158: Management Information Base for Network Management of TCP/IP-based Internets (MIB-II).

l. Network Management Forum: OMNIPoint 1.

3.9.8.5.6 Recommendations. The recommendation is to specify POSIX "lp" only for traditional, centralized systems for imminent procurements. Then look to ISO 10175 or IEEE 1387.4 in the long term.

3.9.9 Additional areas to be added. The following Open Systems Operations, Administration, and Maintenance services are under consideration for addition:

a. Problem reporting and tracking standards

b. Operations standards

c. Diagnostic standards

d. Fault isolation standards

e. System performance metrics and standards

f. Standard mechanisms to initiate remotely both OSE and proprietary diagnostics

g. End user support (help desks)

h. Systems integration standards