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