Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!usenix!jsq
From: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, NIST Shell-and-Tools FIPS Workshop
Message-ID: <561@usenix.ORG>
Date: 28 Sep 90 23:49:05 GMT
References: <558@usenix.ORG>
Sender: jsq@usenix.ORG
Reply-To: rja7m@chaos.cs.Virginia.EDU (Ran Atkinson)
Organization: University of Virginia
Lines: 26
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

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