jsh@usenix.org (Jeffrey S. Haemer) (09/29/90)
Submitted-by: jsh@usenix.org (Jeffrey S. Haemer)
An Update on UNIX1-Related Standards Activities
September 1990
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
NIST Shell-and-Tools FIPS Workshop
Donald Lewine <lewine@cheshirecat.webo.dg.com> reports on the
September 6, 1990 meeting in Gaithersburg, MD:
The Federal Government publishes Federal Information Processing
Standards (FIPS) for use in buying and using computers. One set of
FIPS deal with systems with ``POSIX-like interfaces.'' The government
will purchase about $17 Billion worth of POSIX systems in FY91.
Standards let the government avoid vendor-specific requirements like
UNIX or SVID. The theory is that the larger the number of vendors
that can meet the specification the lower the cost to the taxpayer.
Whether that's true or not, using standards makes it harder to protest
a purchase decision.
On September 6, the National Institute of Standards and Technology
(NIST) held a workshop to gather input from industry and federal
agencies on the wisdom of adopting Draft 9 of the IEEE Standard for
POSIX Shell and Utility Application Interface (P1003.2) as a Federal
Information Processing Standard (FIPS).
The meeting was attended by about a dozen system vendors and about
half that many Federal agencies.
Roger Martin of NIST opened the meeting with what was to be a three-
minute introduction. NIST's agenda was to collect specific comments
on the FIPS as printed on Page 23959 of the Federal Register. The
vendors' agenda was to get NIST to give up the idea of adopting a FIPS
until after the IEEE standard is final. Not surprisingly, given this
clash, Roger's opening remarks ran over by a factor of 20.
Here is NIST's case for adopting a FIPS based on POSIX.2/D9:
1. The federal government is going to purchase about $17 billion
worth of systems with ``POSIX-like interfaces.'' NIST wants to
give the agencies as must help as possible. Draft 9 is a good
enough standard to serve this purpose.
__________
1. UNIXTM is a Registered Trademark of UNIX System Laboratories in
the United States and other countries.
September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop
- 2 -
2. It takes about a year to get a FIPS adopted. If POSIX.2 is not
approved until mid-1991, a FIPS based on draft 9 will have a
significant lifespan.2
3. If NIST were to publish a FIPS, it would accelerate the
production of the P1003.2 standard. (just as FIPS 151
accelerated IEEE 1003.1-1988).
4. No agency is going to be stupid enough to demand draft 9 if a
vendor can supply a system conforming to a later draft or to the
final standard, so the FIPS will do no harm. (This was hotly
debated.)
After that introduction, and before the next attack on Roger Martin,
Sheila Frankel and Rick Kuhn described the technical content of the
FIPS. Basically, the idea is to adopt draft 9 minus the parts that
might change. There are about 25 items that may change. NIST is
looking for specific technical comments by October 15. Send comments
to <frankel@swe.ncsl.nist.gov>.
Comments like, ``I don't know if _____ is technically correct but I
like the general idea,'' are welcome for specific items. Comments
from government users are especially welcome. Comments from industry
on the general wisdom of adopting a FIPS prior to the final IEEE
approval of a standard will not be very welcome.
Roger Martin came back for another round of target practice. He went
over the general policy of NIST, which is to adopt standards from
outside and at the highest possible level. The levels are, highest to
lowest:
- International Standards
- National Standards
- Draft Standards
- de facto Standards
__________
2. Just because the IEEE approves a standard does not make it a
Federal Information Processing Standard. The feds still have to
go through the entire legal process of publishing it in the
Federal Register, collecting comments, writing responses to those
comments, and getting it signed by the Secretary of Commerce.
This process takes about a year even for a null standard.
September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop
- 3 -
NIST could be convinced to change from POSIX.2/D9 to POSIX.2/D10.
Here are the factors it will consider:
1. How much delay is introduced (Three months may be OK. One year
is unacceptable.)
2. Is Draft 10 that much better than Draft 9? Is this just a
delaying action?
Shane McCarron, former Watchdog Report Editor (now of UNIX
International), made a great speech pointing out how much wasted
effort would occur if every vendor had to rush out and implement
POSIX.2/D9. The NIST people seemed shocked at how different
POSIX.2/D9 is from existing practice. [Editor: See Randall Howard's
POSIX.2 report for some examples of just how different Draft 9 is from
Drafts 8 and 10.] Nevertheless, the argument seemed to fall on deaf
ears, because NIST claimed that a promise to meet the FIPS should be
good enough and everyone can still wait for AT&T USL to write the
code.
It was pointed out that Congress did not allocate enough funding for
NIST to do much testing for POSIX.2 conformance. This means that
vendors will have to ``self certify'' and coverage may vary. After
some discussion this item was placed into the ``write your
representative'' category, because only Congress can allocate the
money.
NIST pointed out that they are under a great deal of pressure to
``advise'' federal agencies who want to move to open systems. A large
percentage of RFPs for POSIX-like systems will be coming from groups
who know nothing about such systems. Vendors were worried that this
``advice'' would end up in court cases and be read by judges as
``regulations.''
In my opinion, NIST is going to go ahead and publish a flawed FIPS in
the belief that it will drive the IEEE to pick up the pace of POSIX.
The Government has a burning need for a standard, they find it
politically unacceptable to use UNIX System V as that standard, and
they strongly prefer action over waiting for the IEEE.
September 1990 Standards Update NIST Shell-and-Tools FIPS Workshop
Volume-Number: Volume 21, Number 146gwyn@smoke.brl.mil (Doug Gwyn) (09/29/90)
Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn) In article <558@usenix.ORG> std-unix@uunet.uu.net writes: >Standards let the government avoid vendor-specific requirements like >UNIX or SVID. ... >The Government has a burning need for a standard, they find it >politically unacceptable to use UNIX System V as that standard, ... I have to challenge this often-heard (from DEC, for example, who don't want truly open systems in the first place) rationale. In fact there have been more than one major (in the billion-dollar range) federal acquisition where SVID conformance was specified, and that specification was successfully upheld in appeals. Thus the government's official position would appear to be that SVID is an acceptable standard. Note that SVID is not the same as AT&T UNIX System V implementation, although there is clearly a relationship between them. (But there also is between UNIX System V and POSIX, ANSI C, etc.) Volume-Number: Volume 21, Number 148
rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) (09/29/90)
Submitted-by: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson) As a former Federal employee and someone who looks at POSIX strictly from the user point of view, I'd much rather see NIST write a FIPS based on P1003.2/10 AND the current P1003.2a than to have them write one based on P1003.2/9 because it seems clear that draft 9 will be farther from the end product than draft 10 will be by a significant margin and P1003.2a has a lot of stuff that most existing UNIX (tm) users expect to see that was omitted from P1003.2. For that matter, it might be worth looking at the SVID for System V, Release 4 and the BSD 4.3 Tahoe documentation to see if there is other stuff that isn't part of the P1003.2 effort that NIST thinks government users need. For my part, I want P1003.2 to specify an environment with capabilties comparable to what BSD and the SVID both specify and I don't really see that just now in the drafts. I have mixed feelings about the notion of NIST pushing the FIPS this fast, but I agree that some vendors are clearly just trying to drag out the IEEE standards process and are trying to water down the standard so that their existing proprietary system will meet the standard. Randall Atkinson randall@Virginia.EDU Volume-Number: Volume 21, Number 149
vyw@stc06.ctd.ornl.gov (WHITE V L) (10/01/90)
Submitted-by: vyw@stc06.ctd.ornl.gov (WHITE V L) Doug Gwyn writes: >In article <558@usenix.ORG> std-unix@uunet.uu.net writes: >>Standards let the government avoid vendor-specific requirements like >>UNIX or SVID. ... >>The Government has a burning need for a standard, they find it >>politically unacceptable to use UNIX System V as that standard, ... > >I have to challenge this often-heard (from DEC, for example, who don't >want truly open systems in the first place) rationale. In fact there >have been more than one major (in the billion-dollar range) federal >acquisition where SVID conformance was specified, and that specification >was successfully upheld in appeals. Thus the government's official >position would appear to be that SVID is an acceptable standard. Yes and no. This is hard to explain to someone who hasn't lived through it. Yes, the 3.5 billion dollar AFCAC case upheld the legality of the use of the SVID in procurements. No, SVID is not proprietary and any vendor who wished could make his system conform to it. Yes, the SVID is a perfectly good standard and we could be using it to fill in the gaps in our procurement specs until the IEEE has time to produce a reasonable and mature set of Posix standards. So why aren't we? One reason is that we don't want to lock out systems that are primarily Berkeley based. However, we could still pull out enough definitions from the SVID for utilities which don't differ any or much from their BSD equivalents, write out exceptions to allow for the BSD differences, and have a decent spec which would get us a Unix (not a proprietary) system. The bigger reason is that "SVID" is a four letter word to the federal supervisors who are pressured by vendors hinting darkly at protests. The AFCAC precedent doesn't stop these threats, and it doesn't matter whether the vendor could actually win one of these protests. Any protest, whether it is eventually upheld or not, adds an incredible burden of time, money, and headaches to the already baroque procurement process. It can stop your buy for months. The problem is the vendors who have had a free reign in the government for so many years and aren't willing to give up their hold now that they are being forced to play by the rules of competitive procurement. I suppose the problem is also the system that lets them clog the works with unjustified protests, but I don't know how to prevent that without being unfair to the vendors who have justified protests. I've been told this is no excuse to pressure the longsuffering Roger Martin to hurry through an immature FIPS and that I should just write a better spec, good grief. Just say what I want. That's my job, after all. Well, I have done that, because I had to, and I ask you, how am I to define what shell or editor or grep I want without reference to SVID or the BSD manual or X/OPEN or some draft of 1003.2 (to which I am reminded on every page not to require conformance)? Somebody has a complaint about all of them, and I've wasted a lot of time bending words to satisfy nervous bosses when I'd rather be programming. Yes, we should make the standards process reasonable and not rush it. Yes, we'll have to make some sacrifices in lost productivity in the meantime in order to accomplish that goal. It would help a lot if the vendors meant what they said about their standards support instead of standing in the way. And you know, I've used the products of those vendors who are making the most noise, and they're GOOD. Don't they believe that themselves? Don't they think their products can stand on their own merits? Why are they so afraid of the big bad SVID? I'm sorry this is a nontechnical contribution, and a long one at that, but unfortunately the nontechnical problems sometimes have a greater impact on our work and are more difficult to overcome than the technical ones. These opinions are wholely mine and do not represent an official position of my employers or of the federal government. Vicky White Oak Ridge National Laboratory vyw@ornl.gov Volume-Number: Volume 21, Number 159
hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers) (10/02/90)
Submitted-by: rogers@ofc.uucp In article <558@usenix.ORG> std-unix@uunet.uu.net writes: > >In my opinion, NIST is going to go ahead and publish a flawed FIPS in >the belief that it will drive the IEEE to pick up the pace of POSIX. >The Government has a burning need for a standard, they find it >politically unacceptable to use UNIX System V as that standard, and >they strongly prefer action over waiting for the IEEE. > There is something to be said for any action which motivates the IEEE committees to move a little faster. This type of action, however, will ultimately cost the taxpayer when agencies who purchase D9 implementations have to retool a year later because all the developed applications will honor the final dot 2 draft. What I fail to understand is IEEE's continuing propensity to violate the "prime directive", i.e., their failure to specify common practice. As long as they continue this annoying habit, they will continue creating these problems. It is far better to specify common practice, then work through some other forum on getting the vendors to change the functionality for future versions. Attempting to legislate change through IEEE dot n committees may even work, but guess what? Instead of Uncle Sam buying something off the shelf for near commodity prices, he has to buy a "special" for inflated prices because it had to be especially developed. Nobody had it, not common practice,... And guess what else? You, I, Roger Martin, and the rest of us collectively make up "Uncle Sam." It's your money, ace. IMHO, IEEE "management" needs to put their foot down and put an end to the real political battles - those being fought in IEEE dot n committees. Then NIST would be an ally instead of an opponent. --- HL Rogers (hl.rogers@ncrcae.Columbia.NCR.COM) Volume-Number: Volume 21, Number 160
domo@tsa.co.uk (Dominic Dunlop) (10/03/90)
Submitted-by: domo@tsa.co.uk (Dominic Dunlop) In article <107019@uunet.UU.NET> hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers) writes: > There is something to be said for any action which motivates the IEEE > committees to move a little faster. This type of action, however, will > ultimately cost the taxpayer when agencies who purchase D9 implementations > have to retool a year later because all the developed applications will > honor the final dot 2 draft. While we can wish for an ideal world where standards committees are always able quickly to reach a broad consensus based on well-tried existing practice, and can deliver a well-rounded document to an accepting and grateful public, we have to concern ourself with real life. Real life is populated by engineers with a variety of opinions, politicians, lawyers, accountants, and, if you're unlucky, people waving guns -- all forces which make it more difficult to achieve what may appear to you to be obvious goals. Like you, I, and Uncle Sam, they're just doing their jobs, and may consider different goals to be obvious. One just has to evaluate how well one is doing despite their malign influence. And I think that requiring conformance to a draft standard is a whole lot better than not requiring conformance to anything in particular. Sure, it will be annoying and painful to convert later when the real thing comes along. And it will cost real money. But it will cost a whole lot less money in total than -- say -- implementing using a proprietary environment now, and switching to an official POSIX.2 when it comes along. Yes, the up-front costs may be higher because a draft 9-conforming environment is likely to be more or less custom-built (or at least, suppliers are liable to try to stick you for the costs of a fully custom job, even if such costs are not justified). But the downstream costs, including the costs of any draft-to-final conversion, are likely to be way lower. -- Dominic Dunlop Volume-Number: Volume 21, Number 173
ahby@bungia.bungia.mn.org (Shane P. McCarron) (10/06/90)
Submitted-by: ahby@bungia.bungia.mn.org (Shane P. McCarron) In article <13137@cs.utexas.edu> domo@tsa.co.uk writes: >Submitted-by: domo@tsa.co.uk (Dominic Dunlop) > >While we can wish for an ideal world where standards committees are >always able quickly to reach a broad consensus based on well-tried >existing practice, and can deliver a well-rounded document to an >accepting and grateful public, we have to concern ourself with real >life. Dominic says that we have to concern ourselves with real life. Real life is that POSIX.2 Draft 9 is an immature document. Making it a procurement specification means that system vendors will have to do a lot of work that they will, to some extent, just throw away later. Moreover, this work will be duplicated by every system vendor wanting to sell into that market. Also, since there are organizations like the Open Software Foundation and UNIX System Laboratories producing reference implementations of the operating system, these vendors could have not done the work themselves at all! This economy is development is something that must be taken into account by the US government, and in fact by any organization specifying procurement requirements. These organizations want to procure something TODAY! They want it to look like a standard implementation, but they would probably be just as happy if the applications that they really need ran. MS-DOS is not a standard, but it runs flight-simulator and Lotus. That's enough for most people. What we, as people involved in the standardization process, have to do is work with the Federal government and other organizations to help them understand the folly of prematurely pointing to standards. Those standards are, for the most part, build upon existing practice. When organizations go to put together a procurement specification, they need to know what components of that standard are stable and represent existing practice that is available to them TODAY. If they use that as the basis of their procurement they will have an Open Systems solution that they can actually get their hands on. Further, that solution will be upwardly compatible with the final standard because it is a proper subset of the functionality in that standard. A example of reasonable subsetting from Draft 9 would be system limits like LINEMAX. In POSIX.2 this is specified as being something like 4k (I can't remember). Anyway, the limit is supposed to apply to any utility that reads lines of input from the user or from text files. No system in the world that is shipping today supports this limit in every system utility. It is an ideal goal that the companies represented by the participants in POSIX.2 have agreed to move to over time. Producing a standard is just that: an agreement that all of "this" existing practice is pretty good, and here are the areas in which we agree that it should be better defined or enhanced to make the functionality maximally advantageous for application developers and end users. This is a very important point, and tends to be lost on casual observers of standardization efforts. >And I think that requiring conformance to a draft standard is a whole >lot better than not requiring conformance to anything in particular. >Sure, it will be annoying and painful to convert later when the real >thing comes along. And it will cost real money. But it will cost a >whole lot less money in total than -- say -- implementing using a >proprietary environment now, and switching to an official POSIX.2 when >it comes along. Yes, the up-front costs may be higher because a draft >9-conforming environment is likely to be more or less custom-built (or >at least, suppliers are liable to try to stick you for the costs of a >fully custom job, even if such costs are not justified). But the >downstream costs, including the costs of any draft-to-final conversion, >are likely to be way lower. Well, it depends. The cost to the system vendor will be lower, but not to the end user. Any functionality that user took advantage of that was not represented in the final standard will suddenly become non-portable. Worse yet, it may become unavailable. From a system vendors perspective, they may have to support some strange functioanlity or system limits because the draft standard required them to, some agency took advantage of it, and now they are stuck. They have to support thios non-portable functionality forever, as well as the real standard. This is not at all the goal of standardization, and should not be the goal of the agencies procuring systems. Standing on my soap-box again for a minute, we have to keep the overall goal of open systems in sight. That goal is that the application developers of the world are given a guaranteed base on which they can develop portable applications that can interoperate with one another. This means having a steady functional migration which NEVER capriciously breaks compatability. This may mean that in the short term new, exciting functionality is not introduced to the disadvantage of existing practice. This is the price we pay for keeping the application developers interested in open systems. The personal productivity application base is just coming available for open systems platforms in ways that are attractive to the casual computer user. We CANNOT abdicate our responsibility to retain that extremely hard-won base of applications by allowing radical change in the definition of the system. If we do that, we might as well go and buy DOS. Shane P. McCarron Secretary, IEEE TCOS-SS -- Shane P. McCarron Phone: +1 612-224-9239 Project Manager Internet: ahby@bungia.mn.org Volume-Number: Volume 21, Number 189
drd@siia.mv.com (David Dick) (10/25/90)
Submitted-by: drd@siia.mv.com (David Dick) In <107019@uunet.UU.NET> hl.rogers@ncrcae.Columbia.NCR.COM (HL Rogers) writes: >Submitted-by: rogers@ofc.uucp [discussion about NIST, FIPS, and IEEE standards pace omitted] >What I fail to understand is IEEE's continuing propensity to violate the >"prime directive", i.e., their failure to specify common practice. ... >Attempting to legislate change through IEEE dot n committees may even >work, but guess what? Instead of Uncle Sam buying something off the >shelf for near commodity prices, he has to buy a "special" for inflated >prices because it had to be especially developed. Nobody had it, not >common practice,... And guess what else? You, I, Roger Martin, and >the rest of us collectively make up "Uncle Sam." It's your money, ace. But isn't this exactly what has been happening for years in Federal procurement? Unfortunately, some of the same forces that encouraged this in traditional procurement must still be in operation, e.g., the need of the procurement bureaucracy to ensure its continued existence. David Dick Software Innovations, Inc. [the Software Moving Company(sm)] Volume-Number: Volume 22, Number 4