vyw@stc06.ctd.ornl.gov (WHITE V L) (01/11/90)
In a recent article Doug Gwyn <gwyn@smoke.brl.mil> writes: > The problem is, NIST prepares FIPS and there is essentially no stopping > them. Because FIPS are binding on government procurements (unless > specific waivers are obtained), they have heavy economic impact on > vendors. In the "good old days", NBS allowed the computing industry > to develop suitable standards and later blessed them with FIPS. With > the change in political climate that occurred with the Reagan > administration, which was responsible for the name change from NBS to > NIST, NIST was given a more "proactive" role in the development of > technology. Unfortunately they seem to think that forcing standards > advances the technology, whereas that would be true only under > favorable circumstances (which unsuitable standards do not promote). > (Actually I think that the whole idea of a government attempting to > promote technology is seriously in error, but that's another topic.) > > I don't know how you can tone down NIST. Perhaps if enough congressmen > receive enough complaints some pressure may be applied. I understand the sentiment behind this and other complaints that have appeared in this forum against NIST, but I am compelled nevertheless to rise to their defense. I don't believe NIST is just slap happy with power. They are reacting to pressure from other government agencies who desperately need their help to develop and maintain an open computing environment. In the good old days, these agencies had far greater freedom to buy from whomever they wished, and they could afford the luxury of allowing the industry to develop standards at its slow and careful pace. Now the stricter enforcement of the rules for open competition do not allow these agencies to specify which implementation of Unix they want or whether they get Unix at all. Applications portability as provided by 1003.1 is their greatest need, but they also have a need for shell scripts to work across different systems, for interactive environments to be similar enough across systems to minimize training costs for (and mutinies by) users, and even for system administration to be reasonably standard, especially as more users obtain workstations and become their own system administrators. The current push for the UPE and for 1003.7 may be from NIST, but it originated from beleagured federal government systems programmers. NIST wants to provide these folks something to include in a procurement specification so that they can buy systems which can be made to work together. It is quite right and a good thing for industry to balk when NIST pushes too fast. We need the ideas and the pushing/pulling from both sides to battle out just the right standard and to decide when it is appropriate to attempt the standard at all. But if a good standard is going to take awhile, I would prefer to have a not-so-good FIPS in the meantime that blesses some acceptable, widely used solution so that I can buy my system and connect it to everything else. If the time is not yet right for a standard (or even for a FIPS), then it really is the responsibility of NIST to back off. But even in that case, I would appreciate the fact that it tried, because in this it was acting as an advocate for those government systems programmers. Somebody has to. Do you know what federal agencies do when they want something not yet covered by a FIPS? They try to rely on the SVID or X/OPEN without making anybody mad (lots of luck). Much of what you get away with depends upon how much money you are spending, which vendors want a piece of it, and how paranoid your procurement attorneys are. Vendors always complain that NIST is too fast and other government agencies always complain that it is too slow. I may not always agree with its pace, either, but I am very grateful it is there. Vicky White Oak Ridge National Laboratory Oak Ridge, Tennessee vyw@ornl.gov Volume-Number: Volume 18, Number 18
gwyn@smoke.brl.mil (Doug Gwyn) (01/13/90)
In article <7552@cs.utexas.edu> WHITE V L <vyw@stc06.ctd.ornl.gov> writes: >The current push for the UPE and for 1003.7 may be from NIST, but it originated >from beleagured federal government systems programmers. There are only two relevant differences between the Federal government and other corporate entities with respect to this issue: (1) The Federal rules are relatively rigid, which precludes negotiation between vendor and customer to obtain the technically best solution (when a FIPS is in force). (2) Closed systems are not permitted to the Federal customer even when they make the most sense. These are the product of bureaucracy, which is a perennial government problem. I imagine large corporations such as General Motors also have rather inflexible rules that may in some cases run counter to their own best interests. So far as systems programming in a government UNIX environment goes, it is not radically different from the situation in commercial industry. I am (at times) a Federal government systems programmer, but I take the long view of the industry. Even if something would make my job a bit easier in the short term, I don't want it if it's going to harm the evolution of computing in the long run. Premature or hasty standards have just that effect. Volume-Number: Volume 18, Number 19