ahby@bungia.bungia.mn.org (Shane P. McCarron) (12/11/88)
[ 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 38gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/11/88)
From: gwyn@smoke.BRL.MIL (Doug Gwyn ) In article <270@longway.TIC.COM> Shane P. McCarron <ahby@bungia.bungia.mn.org> writes: >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. I fully agree with your criticism of the way NIST has taken it upon themselves to publish FIPS before the related standards in progress are even semi-stable. As a member of an agency that has to justify not specifying compliance with applicable FIPS, I must say that far from helping me procure standard-environment systems, NIST is making it difficult to procure ANY system, let alone one that sufficiently meets our needs. FIPS-151 is a minor disaster that fortunately can probably be straightened out before it is too late, but additional FIPS for other 1003.* areas are definitely premature and interfere with production of quality standardized environmental specifications. If NIST had Ken Thompson, Dennis Ritchie, Brian Kernighan, and Rob Pike (for example) writing their FIPS, then it wouldn't distress me so much, because at least the FIPS would be reasonable specifications. But they are FAR from being in a position to develop clean, usable operating system environment specifications on their own. Why are they trying to do so? It's completely subverting the standardization process! [ FIPS-151 is the one published in August 1988 about IEEE 1003.1. -mod ] Volume-Number: Volume 15, Number 39