home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.15 / text0027.txt < prev    next >
Encoding:
Text File  |  1989-01-17  |  5.8 KB  |  139 lines
  1. [ These Standards Updates are published after each IEEE 1003
  2. meeting, and are commissioned by the USENIX Association.
  3. See Part 1 for contact information.  -mod ]
  4.  
  5.  
  6.       An update on UNIX|= Standards Activities - Part 3
  7.  
  8.     NIST (NBS) Federal Inforamtion Processing Standards
  9.  
  10.                      November 18, 1988
  11.  
  12.            Shane P. McCarron, NAPS International
  13.  
  14. National Institute of Standards and Technology
  15.  
  16. On August 30th, 1988 (4 days after publication of the last
  17. article in this series) the NIST (formerly the National
  18. Bureau of Standards) published their Federal Information
  19. Processing Standard for POSIX.  I have written much about
  20. this in the past, so I won't go into the details of it now.
  21. Suffice it to say that this FIPS is finally approved, but
  22. differs substantially from the approved IEEE standard in a
  23. few key areas.  The NIST is now working to revise the FIPS
  24. so that it is more in line with the real standard.  This new
  25. FIPS should be announced in the Federal Register in early
  26. January, and after time for public comment and review will
  27. be formally approved.  The NIST expects approval sometime in
  28. the summer of 1989.
  29.  
  30. In the last article I mentioned that the NIST had announced
  31. their intent to create FIPS in a number of other areas.
  32. They have now released a preliminary FIPS for System
  33. Administration, and are about to release one for Shell and
  34. Tools. They have also stated that by year's end they will
  35. release a FIPS on utilities with User Interfaces (like vi).
  36. While in the case of Shell and Tools the NIST is going to
  37. use Draft 8 of the 1003.2 standard, there are no existing
  38. formal standards in the other areas.  Instead of waiting for
  39. standard bodies to develop mature documents, the NIST is
  40. going to a number of different versions of UNIX, and picking
  41. those things that look neat.  The System Administration FIPS
  42. in particular is disturbing.  There are a number of
  43. utilities in there from AIX (IBM's version of UNIX), Xenix
  44. (SCO or Microsoft, I can't tell), and of course the SVID
  45. (from AT&T).  This ensures that there is no existing system
  46. that will conform to the FIPS on day one, and also shackles
  47. the newly formed IEEE working group on System
  48. Administration.
  49.  
  50. __________
  51.  
  52.   |= UNIX is a registered trademark of AT&T in the U.S. and
  53.     other countries.
  54.  
  55.  
  56.                            - 2 -
  57.  
  58. I really don't know what the NIST is trying to achieve.  It
  59. appears as if they are working toward their stated goal of
  60. creating a full suite of specifications to flesh out the
  61. Applications Portability Profile (a conceptual model of
  62. portability specifications created by the NBS over the last
  63. few years).  I used to think that they had some sort of
  64. hidden agenda, but I don't believe that any more.  I used to
  65. think that they were trying to railroad standards to make
  66. sure that the government's needs were satisfied.  In this I
  67. have also been proven wrong.  They have now shown their
  68. ability to create standards at will, thereby invalidating
  69. the work of the standards bodies before they can even begin.
  70. This interesting turn of events proves that in their
  71. previous heinous acts they were just being nice.  They could
  72. have superceded the process altogether if they had really
  73. wanted to!
  74.  
  75. It was bad enough when the work of the committees was being
  76. affected by the arbitrary timelines imposed by the NIST, but
  77. now they have created a framework within which any standard
  78. on, say, System Administration will have to fall if it is to
  79. be taken seriously by the vendor community.  What vendor in
  80. its right mind would conform to a formal standard that was
  81. not in line with the standard being required by all U.S.
  82. federal agencies?  The obvious answer is "vendors that don't
  83. want to sell to the government."  In other words - none.
  84. Moreover, what vendor sponsored committee member is going to
  85. propose something for a standard that would make their
  86. employer not be able to sell to the federal government?
  87. Again, none.
  88.  
  89. I have given the NIST an opportunity to rebut the comments
  90. made above, and they are in the process of doing so.  I will
  91. publish their comments as soon as I have them available.
  92. However, I would guess that they will say something like
  93. "These are just first cuts.  In the future we will modify
  94. the FIPS to conform to standards produced by standards
  95. making bodies."  That's great, but it really doesn't help.
  96. First, it would be a disservice to the federal user
  97. community to force them to change from an environment in
  98. which they have become comfortable.  Second, it is a mistake
  99. to assume that the vendors are going to want to conform to
  100. one standard for a while, and then change over later.  If
  101. there is a standard that is being required by a substantial
  102. part of the user community, then that is the one to which
  103. vendors are going to conform.  And if vendors conform to it,
  104. it then becomes the existing practice that must be
  105. formalized by standards bodies like IEEE P1003.  It's a
  106. vicious circle, and in the end the losers are the users.
  107. They are being handed an ill-considered standard;  one that
  108. is being foist upon them just because some small group of
  109.  
  110.  
  111.                            - 3 -
  112.  
  113. people, after consulting with a handful of their (rather
  114. unique) user community, have decided that this is the way it
  115. is going to be.
  116.  
  117. In defense of the NIST, I know that they are not trying to
  118. destroy the standards making process.  In reality they are
  119. just a bunch of people trying to do their jobs the best way
  120. they know how.  It is unfortunate that in doing so they may
  121. end up doing more harm than good.
  122.  
  123. The Watchdog committee has no contact person with the NIST.
  124. For further information on NIST activities you can contact
  125. me or Roger Martin.
  126.  
  127.           Roger Martin
  128.           National Institute of Standards and Technology
  129.           Software Engineering Group
  130.           Technology Blvd.
  131.           Room B266
  132.           Gaithersburg, MD  20899
  133.           rmartin@swe.icst.nbs.gov
  134.           +1 (301) 975-3295
  135.  
  136.  
  137. Volume-Number: Volume 15, Number 38
  138.  
  139.