Path: utzoo!attcan!uunet!longway!std-unix From: ahby@bungia.bungia.mn.org (Shane P. McCarron) Newsgroups: comp.std.unix Subject: Standards Update, Part 3: NIST FIPS Message-ID: <270@longway.TIC.COM> Date: 11 Dec 88 01:12:11 GMT Sender: std-unix@longway.TIC.COM Reply-To: Shane P. McCarron Lines: 137 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) [ These Standards Updates are published after each IEEE 1003 meeting, and are commissioned by the USENIX Association. See Part 1 for contact information. -mod ] An update on UNIX|= Standards Activities - Part 3 NIST (NBS) Federal Inforamtion Processing Standards November 18, 1988 Shane P. McCarron, NAPS International National Institute of Standards and Technology On August 30th, 1988 (4 days after publication of the last article in this series) the NIST (formerly the National Bureau of Standards) published their Federal Information Processing Standard for POSIX. I have written much about this in the past, so I won't go into the details of it now. Suffice it to say that this FIPS is finally approved, but differs substantially from the approved IEEE standard in a few key areas. The NIST is now working to revise the FIPS so that it is more in line with the real standard. This new FIPS should be announced in the Federal Register in early January, and after time for public comment and review will be formally approved. The NIST expects approval sometime in the summer of 1989. In the last article I mentioned that the NIST had announced their intent to create FIPS in a number of other areas. They have now released a preliminary FIPS for System Administration, and are about to release one for Shell and Tools. They have also stated that by year's end they will release a FIPS on utilities with User Interfaces (like vi). While in the case of Shell and Tools the NIST is going to use Draft 8 of the 1003.2 standard, there are no existing formal standards in the other areas. Instead of waiting for standard bodies to develop mature documents, the NIST is going to a number of different versions of UNIX, and picking those things that look neat. The System Administration FIPS in particular is disturbing. There are a number of utilities in there from AIX (IBM's version of UNIX), Xenix (SCO or Microsoft, I can't tell), and of course the SVID (from AT&T). This ensures that there is no existing system that will conform to the FIPS on day one, and also shackles the newly formed IEEE working group on System Administration. __________ |= UNIX is a registered trademark of AT&T in the U.S. and other countries. - 2 - I really don't know what the NIST is trying to achieve. It appears as if they are working toward their stated goal of creating a full suite of specifications to flesh out the Applications Portability Profile (a conceptual model of portability specifications created by the NBS over the last few years). I used to think that they had some sort of hidden agenda, but I don't believe that any more. I used to think that they were trying to railroad standards to make sure that the government's needs were satisfied. In this I have also been proven wrong. They have now shown their ability to create standards at will, thereby invalidating the work of the standards bodies before they can even begin. This interesting turn of events proves that in their previous heinous acts they were just being nice. They could have superceded the process altogether if they had really wanted to! It was bad enough when the work of the committees was being affected by the arbitrary timelines imposed by the NIST, but now they have created a framework within which any standard on, say, System Administration will have to fall if it is to be taken seriously by the vendor community. What vendor in its right mind would conform to a formal standard that was not in line with the standard being required by all U.S. federal agencies? The obvious answer is "vendors that don't want to sell to the government." In other words - none. Moreover, what vendor sponsored committee member is going to propose something for a standard that would make their employer not be able to sell to the federal government? Again, none. I have given the NIST an opportunity to rebut the comments made above, and they are in the process of doing so. I will publish their comments as soon as I have them available. However, I would guess that they will say something like "These are just first cuts. In the future we will modify the FIPS to conform to standards produced by standards making bodies." That's great, but it really doesn't help. First, it would be a disservice to the federal user community to force them to change from an environment in which they have become comfortable. Second, it is a mistake to assume that the vendors are going to want to conform to one standard for a while, and then change over later. If there is a standard that is being required by a substantial part of the user community, then that is the one to which vendors are going to conform. And if vendors conform to it, it then becomes the existing practice that must be formalized by standards bodies like IEEE P1003. It's a vicious circle, and in the end the losers are the users. They are being handed an ill-considered standard; one that is being foist upon them just because some small group of - 3 - people, after consulting with a handful of their (rather unique) user community, have decided that this is the way it is going to be. In defense of the NIST, I know that they are not trying to destroy the standards making process. In reality they are just a bunch of people trying to do their jobs the best way they know how. It is unfortunate that in doing so they may end up doing more harm than good. The Watchdog committee has no contact person with the NIST. For further information on NIST activities you can contact me or Roger Martin. Roger Martin National Institute of Standards and Technology Software Engineering Group Technology Blvd. Room B266 Gaithersburg, MD 20899 rmartin@swe.icst.nbs.gov +1 (301) 975-3295 Volume-Number: Volume 15, Number 38