The Future of POSIX

In July this year, the ad-hoc group that was set up to investigate and report on these issues produced its final report. This report is reproduced below. Closer cooperation between the three groups that have up until now been responsible for producing standards with overlapping scope now looks certain to happen.

The three groups, PASC, ISO JTC1/SC22/WG15, and The Open Group (TOG) met together in early September to start work on a revision to POSIX.1 and POSIX.2. The idea is to produce a single document that will define the core of the Single UNIX specification, and replace POSIX.1 and POSIX.2 as they are today with a more up to date and complete standard. This is the first meeting of the study group proposed in the report. This study group is responsible for planning, scoping, and initiating a new joint working group to produce these new standards. This represents the future of the core POSIX work.

Much of the recent POSIX work has been in relation to the realtime extensions, which are still recognized as vitally important, and a place where PASC expertise is still essential. In order to finish those realtime extensions not yet completed, POSIX.1a and POSIX.2b must clear the way for them. Both of these documents are in ballot at present, and look likely to complete within the next year. Apart from providing a basis for the other realtime extensions, these documents will add several classic UNIX features, such as symbolic links, to the existing core.

Let's hope that we can now stop wondering quite so much about what the future holds for us, and instead get on with implementing it!

The Report of the Ad-Hoc Committee

At the April, 1998 meetings PASC, WG15 and The Open Group (TOG) all committed to seeking answers to the procedural, political, financial, and intellectual property issues which must be addressed to enable the coordinated development and maintenance of POSIX standards. However, proposing solutions, or even identifying who should be involved with specific negotiations, has proven to be very difficult.

The April 1998 preliminary report (N719) from the POSIX Coordination Ad-Hoc Committee identified three "First Principles":

1. For each specification we must develop a common point of responsibility for development and maintenance of that specification.
2. Methods must be established to ensure technical coordination of logically related groups of specifications.
3. We must establish a sustainable process that ensures that adopted standards are maintained.

1. There must be no more than one working group per specification.
2. Working group membership must be open to participation of persons from PASC, WG15, and The Open Group.
3. We must not develop competing specifications.
4. The anticipated lifetimes of standards range from five to thirty years.

This Final Report proposes some basic resolutions intended to define the way forward and provide a "stake in the ground" for resolving the numerous issues which must still be addressed.

In previous debates we have agreed that the existing "rolling amendment" process for POSIX standards is no longer acceptable. We have further agreed that we must establish a step-wise revision process. In January 1998, we took initial steps toward that goal by resolving to limit possible amendments to POSIX.1 and POSIX.2 to some of the existing projects and corrigenda. We further resolved to develop all other POSIX standards as stand-alone specifications that could, as appropriate, be included in a future revision of the base standards.

The 1984 /usr/group Standard was the first effort to define a single, common specification for the various UNIX implementation versions which had evolved in the commercial and academic arenas. This standard, along with AT&T's System V Interface Definition, were used as the basis for the IEEE/TCOS efforts to develop POSIX standards. In the same time frame, X/Open, in close cooperation with the POSIX committees, developed its series of Portability Guides (XPG). The extraordinarily close cooperation between these two efforts has resulted in the incorporation of all POSIX.1 and POSIX.2 concepts and features (including many which were contributed by TOG) in TOG's Single UNIX Specification (SUS). Today, the POSIX.1 and POSIX.2 base standards and the SUS are very closely aligned. The SUS represents valuable input to the revision project proposed below.

We urge PASC and the WG15TAG to endorse the following proposals at their July 1998 meetings, the TOG liaison to obtain TOG concurrence, and WG15TAG to submit this proposal to WG15 for its approval. It is essential that these agreements be achieved by the end of July, 1998. The SC22 TAG can then provide the information to the SC22 plenary in August when SC22 is expected to take up the issue of the future of WG15.

There are a number of issues that led to this proposal:

1. There has been a very significant decline in participation in PASC working groups (especially POSIX.1 and POSIX.2) for two primary reasons: (1) we have accomplished most of what we originally set out to do with the base standards (POSIX.1 and POSIX.2); and, as a result, (2) most of the industry participants have shifted their technical expertise to evolving and maintaining the SUS.
2. An IEEE decision to reaffirm/revise/withdraw IEEE Std 1003.2-1992 must be made before December, 1998.
3. The ISO/IEC JTC1 decision to reaffirm/revise/withdraw IS 9945-2:1993 is due in 1998.
4. The "namespace reservation" issue must be resolved to enable other POSIX.1 amendments to move forward.
5. Further delay in resolving these issues, or failure to clearly define a way forward, will result in the near term loss of many of the remaining industry technical expert participants in PASC.
6. We must re-establish a dedicated, critical mass of participation.

In addition, there are numerous unresolved issues that must be addressed if we are to achieve the three "first principles" that we identified at the beginning of this report. Some of these unresolved issues are:

1. All interested participants must have visibility into the standards development and balloting processes. This includes all ballot objections and how they are resolved. One serious impediment in this area may be nondisclosure agreements.
2. There must be a way of balancing the interests of various affected groups. An example method of achieving this is the IEEE requirement for appropriate levels of representation from Producers, Users, General Interest, and Academic participants.
3. There are a number of difficult issues surrounding the ballot process (e.g., who gets to participate, whose votes are counted, the time frame for voting, etc.).
4. With respect to The Open Group processes, there are concerns about the disenfranchisement of individuals and small organizations.
5. A list of specific issues and problems regarding the Procedures and Processes of each organization has not been generated. This should be done and each issue addressed.
6. Specific IPR issues must be identified and submitted for resolution to the appropriate leadership of each organization.

Hammering out the details of these and other issues will continue to be a very major and difficult problem. The ad hoc committee stresses the importance of recognition by all parties that "the devil is in the details" and there are many details remaining to be addressed. The concerns raised by the lack of resolution of these details must be overcome if progress is to be made.

Recognizing the "realities" of the current situation, but also acknowledging the continuing importance of POSIX standards in the quest for truly open systems environments, we therefore re-affirm the Issues and Recommendations presented in the preliminary ad hoc report and further propose the following actions:

1. PASC should adopt a Resolution to immediately create a Study Group with open membership to initiate a joint revision of ISO/IEC 9945-1, ISO/IEC 9945-2, IEEE Std 1003.1, IEEE Std 1003.2, and the appropriate parts of The Open Group SUS. This revision should result in a common standard(s) that must be completed within the next three to five years. (Note: See IEEE/PASC Resolution 9801-03 for additional applicable information about possible amendments.)
2. PASC and WG15 should immediately initiate the necessary processes to "reaffirm" IEEE Std 1003.2-1992 and IS 9945-2:1993.
3. Based on the experiences gained from this process, similar collaborative efforts for other POSIX standards should be initiated as appropriate.
4. PASC should adopt a Resolution that PASC will not unilaterally produce standards that conflict with the SUS or the ISO/IEC 9945-1 and 9945-2 standards.

This report is the result of approximately 12 hours of face-to-face meetings, ongoing electronic discussions over the last six months, and many hours of private discussions on the part of approximately 20-25 participants from all three organizations. The frank and open discussions of the ad hoc committee should be continued in all three organizations. I extend my personal thanks and appreciation to everyone who participated in these discussions.

Roger Martin, chair, POSIX Coordination ad hoc Committee.

Project Management

The PASC working groups have been responsible for delivering many standards projects successfully over the years. Occasionally, however, we embark upon a project that ends up deadlocked for any number of reasons, and fails to make any headway for an extended period of time. Although these projects have their own constituency who are committed to the results of the project, if that project cannot complete in a timely fashion, those constituents will end up looking elsewhere. From time to time, projects end up so helplessly deadlocked that they cannot make sensible progress. Additionally, standards projects, at least in the IEEE, are staffed entirely by volunteers, and these volunteers sometimes lose the time that they dedicate to progressing standards work to other projects their employers demand.

As a result some standards projects end up in a stagnant form, with no visible progress even to those who are looking closely. It serves the community as a whole if such stagnant projects are actually withdrawn, rather than remain unfinished. This year, we have withdrawn sponsorship for POSIX.1e and POSIX.2c (security), and at the July meeting for POSIX.14 and POSIX.18 (Multi-processing Profile and "POSIX" profile) were also withdrawn.

Each quarter, projects that seem to have remained static for more than a year will be given a warning that unless they can show some sign of life, they will have their sponsorship withdrawn at the next meeting. Of course, withdrawal of sponsorship is not in itself a death sentence. If those concerned are actually doing something worthwhile, they can always reapply for sponsorship.

Common Information Model for UNIX

The Open Group's System Management working group (TOG SysMan) has spent much of the last year contemplating what to do in the context of TOG's "IT Dialtone" initiative. It must be said that very little real progress has been made on this; lots of words and pictures, an architecture document, but little that will really effect anybody! One thing that has emerged from this is a commitment to making the Desktop Management Task Force (DMTF) Common Information Model (CIM) a keystone for future system management work. Information about CIM is available at <https://www.dmtf.org/cim/>.

CIM is a conceptual information model for describing management that is not bound to a particular implementation. This allows for the interchange of management information between management systems and applications. This can be either "agent to manager" and "manager to manager" communications which provides for Distributed System Management.

This is the first time in this industry that a common method of describing management information has been agreed and followed through with implementation. Other efforts have failed because of the lack of industry support. The model, because it is implementation independent, does not provide sufficient information for product development. It is the specific product areas, applications, system, network, database and devices and their product specific extensions that produced workable solutions.

In July, at Miami, SysMan agreed to sponsor a project to provide UNIX-98 extensions to the CIM common system schema.

CIM schemas are described in Managed Object File (MOF) format. The CIM-UNIX project team are writing a MOF description of the things that are in UNIX-98, but are not represented in the CIM common system schema. For example, there is a UNIX_FileSystem class, based on the CIM_FileSystem class, but adding features such as the total number of Inodes and Free Inodes (known as "slots" in UNIX-98, to avoid implementation specific language).

A variety of vendors are producing tools that use CIM already; standardized UNIX extensions will make these tools even more powerful and useful in managing a heterogeneous network. CIM is a part of the DMTF Web Based Enterprise Management (WBEM) initiative; in fact at present, CIM is the only approved WBEM specification.