THIS  OPINION WAS INITIALLY ISSUED  UNDER PROTECTIVE ORDER AND IS
   BEING RELEASED TO THE PUBLIC IN REDACTED FORM ON JUNE 30, 1995 
               _________________________________________
 
                          DENIED: June 9, 1995
               _________________________________________
 
 
                        GSBCA 13201-P, 13211-P 
 
 
                               C3, INC.,
 
                                  and
 
                             TISOFT, INC.,
 
 
                                           Protesters/Intervenors,
 
                                   v.
 
                    GENERAL SERVICES ADMINISTRATION,
 
                                           Respondent,
 
                                  and
 
                          UNISYS CORPORATION,
 
                                           Intervenor.
 
        Richard  J. Conway,  William M.  Rosen,  Leticia E.  Flores,
   Robert  J.  Moss,  J.  Andrew  Jackson, and  Sallie  H.  Helm  of
   Dickstein,  Shapiro & Morin, Washington, DC; Timothy Sullivan and
   Martin  R. Fischer of Dykema Gossett, Washington, DC; and Michael
   P. Flaherty, Washington, DC, counsel for Protester/Intervenor C3,
   Inc.
 
        Robert J. Kenney,  Jr., William A.  Bradford, Jr., David  W.
   Burgett,  Thomas  L.  McGovern, III,  Timothy  L.  Schroer, David
   Newmann, and S.  Gregg Kunzi of Hogan &  Hartson, Washington, DC,
   counsel for Protester/Intervenor Tisoft, Inc.
 
        George  N.  Barclay,  Roger  Waldron,  Seth  Binstock,  Jody
   Burton, Pamela J.  Reiner, and John C. Sawyer,  Office of General
   Counsel, General Services Administration, Washington, DC, counsel
   for Respondent.
 
        Rand L.  Allen, Paul F. Khoury, and David A. Vogel of Wiley,
   Rein  &  Fielding, Washington,  DC; William  A. Shook,  Donald A.
   Kaplan,  and Amy  L. Carlson  of Preston  Gates Ellis  & Rouvelas
   Meeds, Washington,  DC; and E.  Charles Rowan, Jr., and  Susan D.
   Falkson   of  Unisys   Corporation,  McLean,   VA,  counsel   for
   Intervenor.
 
   Before Board Judges DEVINE, BORWICK, and NEILL.
 
   NEILL, Board Judge.
 
        These two protests, filed respectively by C3, Inc.  (C3) and
   Tisoft,  Inc. (Tisoft),  are  pre-award, post-selection  protests
   challenging the Coast  Guard Standard  Workstation III  (CGSWIII)
   procurement.  The  procurement is being conducted  by the Federal
   Computer Acquisition  Center  (FEDCAC) of  the  General  Services
   Administration  (GSA).  Protesters  allege that the  selection of
   Unisys Corporation (Unisys) as the apparently successful  offeror
   was contrary to statute and  regulation for a variety of reasons.
   Of   particular  concern  to   both  protesters  is   an  alleged
   non-compliance of Unisys' proposal with solicitation requirements
   dealing  with portable  operating system  interface  for computer
   environments (POSIX)  and requirements  regarding the  government
   open  systems interconnection profile (GOSIP).  Both parties have
   amended their original complaints to add counts relating directly
   or indirectly to this alleged non-compliance with POSIX and GOSIP
   requirements.     
 
        Unisys  has  intervened   in  both  protests  and   the  two
   protesters have each intervened in each other's protest.  Because
   the two protests concern the same procurement and involve similar
   allegations, we have consolidated them for purposes of developing
   an  evidentiary record  and rendering  a decision  based on  that
   record.  
 
        C3's protest, as amended, now has the following counts: 
 
        Count  1:  The  Government's  selection  of  Unisys  is
        improper because  the Unisys proposal  fails to  comply
        with mandatory requirements regarding POSIX.
 
        Count  2:  The  Government's  selection  of  Unisys  is
        improper because  the Unisys  proposal fails to  comply
        with mandatory requirements regarding GOSIP.
     
        Count 3: The Government lacked sufficient knowledge  to
        assess properly  Unisys' assertions  in order  to judge
        compliance  with the  mandatory requirements  regarding
        POSIX. 
 
        Count 4:  The Government  misevaluated whether  Unisys'
        proposed relational data base management system and the
        E-Mail software run under the POSIX operating system.  
 
        Count 5: The best value  analysis and award decision is
        fatally flawed for  failing to consider the  true costs
        associated with Unisys' proposal.   
 
        Count 6:  A material misrepresentation by  Unisys makes
        Unysis ineligible for award.
 
        The  protest  of Tisoft,  as  amended, now  consists  of the
   following counts: 
 
        Count 1:  Unisys' proposal was  non-compliant with  the
        mandatory   requirement   of  the   solicitation   that
        communication  software  be  certified as  fully  GOSIP
        compliant. 
 
        Count  2: Unisys' proposal  was non-compliant  with the
        mandatory   requirement   of  the   solicitation   that
        application programs run under POSIX.
 
        Count  3:  Unisys'   proposal  fails  to   satisfy  the
        solicitation's "Open Systems Architecture" requirements
        regarding application portability and interoperability.
 
        Count   4:  Unisys   failed  to   meet  the   mandatory
        requirements of  the RFP  in the  apparent winner  live
        test demonstration.
 
        During  these  protests  the  parties   have  filed  various
   dispositive motions.   Among these  are a motion filed  by Unisys
   asking us  to dismiss the  protest of C3  as untimely filed.   In
   addition, Unisys and  GSA have moved that we  dismiss the protest
   of Tisoft  on  the  ground that  Tisoft  lacks  interested  party
   status.  In  a decision issued prior to the hearing on the merits
   of the two protests, we  denied the motions.  C3, Inc. v. General
   Services Administration, GSBCA 13201-P, et al. (Mar. 30, 1995).  
 
        Our  decision of  March 30  did not  address a  supplemental
   motion filed by  Unisys on March  27, asking that we  dismiss the
   GOSIP allegations in Tisoft's protest as untimely.   Neither have
   we  ruled  as  yet on  a  motion  filed by  Unisys  on  March 29,
   requesting that we dismiss C3's second and third amended protests
   and Tisoft's  amended protest  as untimely filed.   We  deal with
   these  remaining motions in  this decision  which denies  the two
   protests.        
 
                            Findings of Fact
 
   The Solicitation
 
        1.  Under  Request  for   Proposals  (RFP)  No.   KRF-92-006
   (hereinafter "the RFP"), FEDCAC seeks to procure on behalf of the
   United States Coast Guard (USCG) an integrated system of computer
   hardware, software and related services to be used throughout the
   USCG.   The  RFP  envisions  award  of  an  indefinite  delivery,
   indefinite quantity,  firm-fixed price  contract.   Protest File,
   Exhibit 1.
 
        2.   The  Coast  Guard is  currently  meeting its  computing
   needs  via the Standard  Workstation II (CGSWII)  contract, which
   was awarded in the summer  of 1988.  The CGSWII operating  system
   is  a Convergent Technologies  Operating System (CTOS).   Protest
   File,  Exhibit  531  at  3.   The  CTOS  hardware  platforms  are
   available from only one source.  Transcript at 167, 279, 289.
 
        3.   As  amended,  the RFP  seeks  to procure  up  to 25,000
   networked computers consisting of desktop workstations,  portable
   workstations  and network servers, as well as related peripherals
   such  as printers  and modems.   The RFP also  seeks software for
   those computers,  including operating systems,  office automation
   software  (e.g.,  word-processing,  spreadsheets  and  electronic
   mail),  a  powerful   database  system,  network   communications
   applications,  and software development tools.  Additionally, the
   RFP  requires  offerors  to  propose  such  related  services  as
   training,  installation  and  on-site  support.    Protest  File,
   Exhibit 1.  
 
 
   Evaluation and Selection
 
        4.   The  RFP states  that the  Government  will select  the
   proposal  that  represents   the  "best  overall  value   to  the
   Government."   Protest File, Exhibit  1 at 10689.   Assessment of
   proposals  is  to address  two  areas: technical  and  cost, with
   technical being more important than cost.  Id. at 10690.
 
        5.   The stated evaluation  criteria for the  technical area
   are divided into five items  (in descending order of importance):
   "system  design architecture," "ease  of use," "performance  at a
   required Live  Test  Demonstration," "file  conversion  and  form
   conversion," and  "support services."  Protest File, Exhibit 1 at
   10691-95.      
 
        6.   The Government  received proposals from  four offerors.
   The  competitive range was eventually narrowed to three offerors,
   namely Unisys, C3,  and TISOFT, who, after discussions, were then
   asked to  submit best  and final offers  (BAFOs).   Protest File,
   Exhibit 120 at 5; Transcript at 122.  
 
        7.  Under  each  evaluation  factor,  offerors  were  scored
   "plus," "check" or  "minus."   Overall proposals  could be  rated
   "blue" (exceptional),  "green" (acceptable),  "yellow" (marginal)
   or  "red"  (unacceptable).   Proposals  were  also  evaluated for
   technical risk.  Protest File, Exhibit 523 at 11-13.
 
        8.   The Source Selection Evaluation Board  had authority to
   validate  and  evaluate   proposals.    It  reported   its  final
   recommendations to the Source Selection Advisory  Council (SSAC).
   Protest File, Exhibit 523.  The SSAC's final report  sets out the
   overall technical area ratings as follows:
 
               Offeror        Rating          Risk
              [Unisys]         Blue            Low
              [TISOFT]                         Low
                [C3]                           Low
 
   Id., Exhibit  120 at  29.  The  same SSAC  report also  shows the
   following evaluated total  life cycle present value cost for each
   of the three proposals:   
 
              [Unisys]         [C3]         [TISOFT]
            $              $              $           
 
   Id. at 30.
 
        9.   Based  on the final technical and cost evaluations, the
   SSAC  "ranked  the  proposals  in  terms  of  best  value,  i.e.,
   considering both technical and cost," as follows:
 
                       First          Unisys
                       Second         C3
                       Third          TISOFT
 
   Protest File, Exhibit 120 at 31.
 
        10.  After  reviewing the  report and recommendation  of the
   SSAC,  the Source  Selection  Authority,  on  January  19,  1995,
   selected  Unisys as the  apparent winner.   Protest File, Exhibit
   125.
   The RFP Requirements Regarding POSIX 
 
 
        POSIX Described 
 
        11.  POSIX  is   a  family  of  standards   established  and
   controlled   by  the  Institute  for  Electrical  and  Electronic
   Engineers  (IEEE) and  the  International Standards  Organization
   (ISO).  Protest File, Exhibit 211.
 
        12.  As  a family of  standards, POSIX consists  of multiple
   standards, each of which is denominated by a dot and number, such
   as  POSIX.1 or  POSIX.2.  POSIX.1  has a  very narrow focus.   It
   contains only the fundamental services that should be provided by
   an  operating  system  and,  therefore,   is  minimally  defined.
   Protest File, Exhibit  211 at x, xii.   The intent is  that after
   POSIX.1  is issued, other  POSIX standards  will be  issued which
   amend and extend POSIX.1.  Transcript at 1182-83. 
 
        13.  The  POSIX.1   standard  does  not  define   an  entire
   operating system; instead, it  defines only one interface  to the
   operating   system,   through   which   applications   may   make
   standardized  calls to the  operating system in  order to produce
   predictable   results.    The   interface  often  is   called  an
   "Application  Programming Interface"  or  "API."   Protest  File,
   Exhibit 211 at  ix, xi.  POSIX.1 standardizes calls  only for the
   "C" programming language.  Id. at 5; Transcript at 1184-85.  
 
        14.  The stated goal of POSIX.1 is to enable the portability
   of source code.  Section 1 of the standard states:
 
             This  part . . . defines a standard operating
             system interface  and environment  to support
             application  portability  at  the source-code
             level.   It is  intended to  be used  by both
             application     developers     and     system
             implementers.
 
   Protest File, Exhibit 211 at 1.  
 
        15.  POSIX was originally developed  as a standardization of
   the UNIX operating  system environment to reconcile  the numerous
   inconsistencies among  the many flavors  of UNIX.   Transcript at
   1184.    However,  in  order  to  maximize   the  portability  of
   POSIX-compliant  source code, the interface defined by POSIX.1 is
   intended to  be capable of  broad implementation beyond  the UNIX
   world.  Protest File, Exhibit 211 at xii; Transcript at 1184.
 
        16.  The  Government,  through  the  National  Institute  of
   Standards and  Technology (NIST),  adopted POSIX.1  as a  federal
   standard which was designated  as Federal Information  Processing
   Standard (FIPS) 151-1.   This standard has  since been superseded
   by FIPS 151-2.  Protest File, Exhibit 108 at 1 (  3).  
 
        17.  Additional  POSIX   standards,  such  as   POSIX.2  and
   POSIX.4,  have been  developed and  are in  the process  of being
   adopted.  Several additional standards, such as DATA  and FORTRAN
   and "shells and  utilities," all of which  standardize additional
   pieces and  aspects of  an operating  system interface that  will
   extend   the  functionality  of  POSIX,  are  also  currently  in
   development  by various  IEEE committees.    Transcript at  1144,
   1183-84, 1188.  
 
        The RFP's Operating System Requirement 
 
        18.  The RFP requires offerors  to propose operating systems
   for  the  offered  servers,  desktop  workstations  and  portable
   workstations.  Protest  File, Exhibit 1  at 10422 (contract  line
   items  (CLINs) 0501,  0510,  0520).   At  Section  C3.1, the  RFP
   describes the overall requirements for these operating systems:
 
        The server  shall have a  POSIX compliant,  multi-user,
        multi-tasking OS [operating system]  that is capable of
        providing the following services  concurrently:  print,
        file, communications,  networking, and  database.   The
        server,  workstation,  and portable  workstation  shall
        have a POSIX compliant multi-tasking OS and support the
        workstation software,  print services,  networking, and
        end user communications.
 
   Id., at 10383. 
 
        19.  The   RFP's  Glossary  of  Terms  does  not  contain  a
   definition  of "operating system."  It  states, however, that for
   terms and  definitions not  appearing in the  RFP, those  in FIPS
   Pub.  11-2  (The  American  National  Dictionary  for Information
   Processing Systems)  apply.   Protest File,  Exhibit 1  at 10789.
   The  superseding version  of FIPS  Pub.  11-2 defines  "operating
   system" as:
 
        Software  that controls the  execution of programs; and
        that  provides  services such  as  resource allocation,
        scheduling, input/output control, and data management. 
 
   FIPS Pub. 11-3, at 85.  
 
        20.  When drafting the RFP, the  Coast Guard decided not  to
   require  offerors to  bid a  UNIX operating  system, in  order to
   maximize competition.  Transcript at 274, 923-24.
 
        21.  The functional  requirements for  the operating  system
   are  delineated  in Section  C17  of  the  RFP.   This  provision
   specifies  some of the  federal standards with  which the offered
   operating systems must comply:
 
        Operating systems shall be provided for the servers and
        workstations.  Offered server  and workstation (desktop
        and portable)  operating systems shall conform  to FIPS
 
        151-1 or subsequent versions to include the POSIX (IEEE
        1003.1)  standard,   and  shall   have  validation   in
        accordance with  provisions contained in FIPS  151-1 or
        subsequent  versions.    Additionally,  the  Contractor
        shall   incorporate   the  IEEE   P1003.2   (Shell  and
        Utilities) and  IEEE  P1003.4  (Real  Time  Extensions)
        standards  into  the  server  and  desktop  workstation
        operating systems and submit them to the Coast Guard as
        a Technology Enhancement either singularly or  combined
        within 12 months  of the effective date  of the FIP(s).
        A  single operating  system shall  be  offered for  the
        range  of servers.  A single  operating system shall be
        offered  for  the  range of  desktop  workstations.   A
        single  operating  system  shall  be  offered  for  the
        portable  workstations.   The  server and  workstations
        (desktop and portable) are not required to run the same
        [operating system].  The desktop and portable operating
        systems may be the same.
 
   Protest File, Exhibit 1 at 10419.
 
        22.  By requiring conformance to  POSIX.1 and then  imposing
   the requirement that offerors implement POSIX.2 and POSIX.4 after
   they  are adopted by NIST, the Coast  Guard intends to permit the
   offered  operating  systems  to  "grow"  in  POSIX functionality.
   Transcript at 148, 253, 283, 319-20.
 
        23.  In addition to  the requirements of Section  C17, there
   are  two  conditions which  offerors  are expected  to  meet with
   regard to the  RFP's requirement for a  POSIX-compliant operating
   system.  First, offerors are required to obtain certifications of
   validation  from NIST  with respect  to  their offered  operating
   systems:
 
        The offeror shall submit no later than the Government's
        request  for  Best  and Final  Offer  Certifications of
        Validation by NIST that the proposed server and desktop
        workstation   operating   systems    conform   to   the
        requirements of FIPS 151-1 or subsequent versions.
 
   Protest File, Exhibit 1 at 10629.  
 
        24.  Government  and Unisys  witnesses  testified that  they
   interpreted this  certification requirement  in conjunction  with
   Section C17 to mean an  offeror had to obtain a  certification of
   validation  from  NIST  that  the  operating  system  offered  in
   response  to  each  CLIN  for  an operating  system  provides  an
   interface which conforms to the POSIX.1 standard.   Transcript at
   168-69, 849,  939-41.   C3's  lead  person for  this  procurement
   likewise testified to the same effect.  Id. at 78, 98.
 
        25.  The second condition relating  to the RFP's requirement
   for  a  POSIX compliant  operating  system is  that  offerors are
   required to obtain  a separate certificate for  every combination
   of operating system and computer  hardware they propose.  The RFP
   states: 
 
 
        The requirement is  for POSIX operating systems  on the
        server  and   workstations.    If,  for   example,  two
        different servers  and two  different workstations  are
        offered, a total of four  different NIST Certifications
        are  required,  each  certificate  listing the  offered
        operating system on the offered hardware platform.
 
   Protest File, Exhibit 1 at 10630.  
 
        The  RFP's   Requirement  For  a   Relational  Database
        Management System and Electronic Mail
 
        26.  Section  C23  of  the  RFP  specifies  as  a  mandatory
   requirement a  multi-user relational  database management  system
   (RDBMS), and provides  that "the RDBMS shall run  under the POSIX
   operating system."  Protest File, Exhibit 1 at 10440. 
    
        27.  Section C24.3 specifies electronic mail  (E-Mail) as an
   additional mandatory requirement and  provides that "the  offered
   electronic  mail shall  run under  the  POSIX operating  system."
   Protest File, Exhibit 1 at 10449.
 
        28.  The Coast Guard  considers the RDBMS  and E-mail to  be
   "essential  applications"  that are  "crucial  to [its]  mission,
   search and rescue, [and] law enforcement."  Transcript at 159-60.
   The RDBMS is  particularly important  because of  the many  other
   "mission essential applications" that will be tied to it.  Id. at
   154.
 
        29.  The RFP specifies, as  mandatory requirements, a number
   of software applications  in addition to RDBMS and  E-mail.  E.g.
   Sections C24.2, C24.4, C24.5, C24.6, C24.7, C24.8, and C25.  None
   of these other  applications is required to "run  under the POSIX
   operating system."   Protest File, Exhibit 1  at 10448, 10451-52,
   10454, 10460, 10462.
 
        30.  As  originally drafted,  the RFP  specification for  an
   RDBMS did not  provide that "the RDBMS shall run  under the POSIX
   operating system."  Similarly, the original RFP specification for
   electronic mail did not provide that "the offered electronic mail
   shall run under the POSIX  operating system."  Transcript at 155.
   These requirements were added by amendment to the RFP.  Id.
    
        31.  A  considerable amount  of time  was  spent during  the
   hearing to determine why the  Coast Guard added to the RDBMS  and
   electronic mail requirements  the express  requirement that  they
   "run under  the  POSIX  operating system."    The  Coast  Guard's
   representative  for  this  procurement,  who  served  as  liaison
   between  the acquisition office  and the Coast  Guard's Office of
   Command, Control, and Communications, explained that the language
   was added  because of concern  regarding emulation.   Coast Guard
   technical advisors considered at the time that it was very likely
   an offeror might  propose applications designed for  an operating
   system different from that offered  in this procurement.  If this
   were to occur,  the applications would undoubtedly run  under the
   offered  operating  system  by  creating  an  emulation  of  that
   different system.   It was thought that  the possible degradation
   of  performance which sometimes results from emulation might pose
   a  threat to  the efficiency  of  the RDBMS  and electronic  mail
   applications --  both of which  were considered essential  to the
   Coast  Guard's mission.   By  insisting that  at least  these two
   applications "run under  the POSIX operating system,"  the agency
   representative  apparently   believed  any   risks  relating   to
   emulation would be avoided.  Transcript at 159-60, 163. 
 
 
        32.  Various  technical experts called to  testify regarding
   their  understanding of the  requirement to "run  under the POSIX
   operating system" were of the  opinion that this language, on its
   face, has  nothing to do  with emulation.  Transcript  at 548-49,
   620,  1224-25.    Other  witnesses  speculated  that  the  phrase
   precludes the use  of dedicated  servers running  on a  different
   operating  system,  id.  at  854-55,  1198,  or  simply  that  it
   precludes running the database elsewhere, id. at 63.  
 
        33.  The Coast  Guard's  own  representative  who  testified
   regarding the addition of this language to Sections C23 and C24.3
   freely admitted that the "RFP  did not actually say emulation was
   unacceptable for either E-mail or RDBMS  . . . ."  Transcript  at
   161.  He further stated: 
 
        As   a  technician,  I   had  not  worked   in  writing
        specifications  prior to this  for an RFP.   Myself and
        other members of  the technical team used  the language
        that we thought appropriate  to convey the government's
        requirements, to get  this across to the  vendors, that
        we believed this was a  functional statement consistent
        with other statements within the RFP. 
 
   Id. at 162.
 
        34.  We have no  reason to doubt the testimony  of the Coast
   Guard's representative regarding the reason for adding the phrase
   "run under  the POSIX operating  system" to the RDBMS  and E-Mail
   requirements.  The  testimony of the technical  experts convinces
   us that the language  clearly does not  achieve its purpose.   We
   find as fact,  however, that the Coast Guard's  reason for adding
   this language  was to  avoid any  adverse impact  which emulation
   might have on these two critical applications.  
 
        NIST Testing and Certification of POSIX Compliance
 
        35.  To  measure  the  compliance  of  software  offered  in
   federal procurements to the POSIX.1 standard stated  in FIPS 151-
   2, NIST has implemented a testing procedure.  Generally, a vendor
   or offeror hires an  approved POSIX testing laboratory (APTL)  to
   run NIST-developed test suites on the offered software.  The test
   results are then  forwarded to  NIST for  review and  validation.
   Transcript at 1186-88.  
 
 
        36.  If NIST validates  the test results, it will then issue
   a certification of validation for the tested software.  NIST also
   lists  the  software  on  a published  register.    Protest File,
   Exhibit 623.
 
        37.  In  order  to  understand the  issues  in  this protest
   regarding NIST's certification of the POSIX interface proposed by
   Unisys,  a finding regarding the implementation  of POSIX APIs is
   required.   A  POSIX-conformant API  may  be "implemented"  in at
   least  four types  of operating  system architecture.    The NIST
   Testing  Policy contains  definitions  of  these  four  types  of
   implementation.    They  are:  "native  implementation,"  "hosted
   implementation,"  "cooperating  system,"  and "cooperating-hosted
   system."  "Native implementation" is defined as: 
 
        Implementation of POSIX.1  that interfaces directly  to
        an operating system kernel.  
 
   Protest  File,  Exhibit 613  at  2.   "Hosted  implementation" is
   defined as: 
 
        Implementation of POSIX.1 that  is accomplished through
        interfaces  from the POSIX.1 services to some alternate
        form of operating system kernel services.
 
   Id.  "Cooperating system" is defined as:
 
        The      combination      of       the      development
        system[foot #] 1         and         the         target
        system.[foot #] 2   
 
   Id.  "Cooperating-hosted system" is defined as:
 
        A   single   computer   system    that   provides   the
        functionality of  both the development  system and  the
        host implementation with a single operating system, and
        provides the FIPS 151-2  conforming implementation with
        another operating system.
 
 
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 1 "Development system" is defined  as "The computer
   system used  to compile and  configure a  PCTS [POSIX  Conforming
   Test Suite]."  Protest File, Exhibit 613 at 2-3.
 
        [foot #] 2 "Target System" is defined as "The combination of
   the computer system  on which the PCTS is executed  and the parts
   of  the  development  system  that  are  used  to  generate   the
   executable code of a PCTS."  Protest File, Exhibit 613 at 2-3.
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   Id.  Particularly  relevant for these protests are  the first and
   last types of implementation.  
 
 
        38.  When  submitting  test  results to  NIST,  the  APTL is
   expected to  fill out  an application.   On the  application, the
   APTL must  identify the "product"  tested.  The  Administrator of
   the NIST POSIX Testing Program  has testified that NIST does "not
   touch" the information  on the application.   The information  is
   copied directly  to the  certificate of  validation.   Transcript
   1137-38.  NIST Testing Policy states that "the product identified
   represents the operating  system tested."  Protest  File, Exhibit
   613 at  13 (  6.4.1.1).   However, a senior  specialist from NIST
   experienced in reviewing  laboratory reports on  POSIX compliance
   testified that, as a practical  matter, the "product" is the same
   as  the operating system  tested only in  the case  of a "native"
   implementation.  Transcript at 445-49.
 
        39.  An actual  certification of validation  issued by  NIST
   does  not  state the  type  of  implementation that  was  tested.
   Protest File,  Exhibit 613  (Appendix C).   The NIST  Register of
   Validated  Products does state the type  of implementation.  Id.,
   Exhibit 623.  
 
        40.  The  NIST certification  of  validation  is a  standard
   form.    Protest  File,  Exhibit   613  (Appendix  C).    On  the
   certification,  NIST lists  the "implementation  tested" and  the
   "system  tested."  Under  "implementation tested" NIST  lists the
   "product."   This  "product" more  likely  than not  will be  the
   "product"  identified  by  the  APTL  on  the  application  form.
   Transcript at 504-05.
 
        41.  The  certification from NIST  means only that  the test
   results have been  validated.  Protest File,  Exhibit 579 (Answer
   to  Interrogatory No.  110); see also  id., Exhibit 613  at 10 ( 
   5.4).   NIST  does  not  validate operating  systems.   The  test
   results do  not test  or validate  the  operating system  itself.
   Transcript at 444.   An experienced systems  specialist from NIST
   testified that NIST  does not even have  a test suite to  test an
   operating system.   He further explained: "Well, what  we do know
   is that the API conforms [to FIPS 151-2].  That's all  we tested.
   That's all we can specify on."  Id. at 447-48.  The Administrator
   of the NIST POSIX  Testing Program, when asked at the  hearing if
   NIST has a definition of operating system, replied: 
 
        A:   No, no.  Would not touch it with a 10-foot pole.
        Q:   Is that intentional?
        A:   Yes.   If POSIX  doesn't define  operating system,
             I'm not about to define operating system.
 
   Id. at 1138-39.
 
        Unisys' Offer and the POSIX Requirements
 
        42.  Unisys  proposed Microsoft's Windows NT Advanced Server
   version  3.5  operating  system  on  its range  of  servers,  and
   Microsoft's Windows NT  Workstation version 3.5 across  the range
   of     desktop      and     portable      workstations.[foot #] 3
   Protest File,  Exhibit 2 at  20458, 20462; see also  id., Exhibit
   133 (attached briefing  chart listing proposed  operating systems
   of all three offerors).    
 
        43.  Microsoft's  Windows NT is  a product that  permits the
   user to  run simultaneously  applications that  were written  for
   different APIs.  For  example, under Windows  NT, a user can  run
   all  at once  an  application  written for  IBM's  OS/2 API,  one
   written  for the  POSIX.1 API,  and  one written  for Microsoft's
   "Win32"  API.  To enable  such functionality, Windows NT consists
   of  a  common   "kernel"  and  "executive"  with   which  various
   environment subsystems interact.  There  is an OS/2 Subsystem,  a
   Win32 Subsystem and  a POSIX Subsystem  which utilize the  common
   kernel and executive.   Protest File, Exhibit 651 at 3-30.  These
   are  called  "protected"   subsystems  because  a  crash   of  an
   application in  one subsystem  will not  interrupt processing  of
   applications in  other subsystems.   Transcript at  426-27.   The
   subsystems  are  not  separately  purchasable  products  and  are
   included when  Windows NT is purchased.  Id. at 423-25, 512, 852.
   In  the case of the POSIX Subsystem,  the subsystem is not itself
   the interface but  is that portion of the  operating system which
   implements the interface.  Id. at 1193.   
 
        44.  Technical  literature  from Microsoft  illustrates  the
   relationship of  the subsystems  to the  kernel/executive and  to
   each other.    The  kernel  and executive  directly  control  the
   computer hardware.  Each subsystem provides the interface from an
   application   (e.g.,  POSIX   or   Win32  application)   to   the
   kernel/executive.   The Win32 Subsystem provides keyboard and I/O
   (input/output) for all applications.  Consequently all subsystems
   interact to a certain  extent with the Win32 Subsystem.  In fact,
   the Win32 Subsystem is  at the heart of activities,  particularly
   since all  keyboard and display  type activities must  go through
   this subsystem, irrespective  of whether  one is  dealing with  a
   POSIX  application, a  Win32 application,  a  DOS application,  a
   regular Windows 16 application or  any other.  Transcript at 558.
   Windows  NT  also   supports  "piping"  of  commands   among  the
   subsystems.  Protest File, Exhibit 651 at 684-85.  
 
        45.  Several  witnesses  for   the  Government  and   Unisys
   testified that, at least in their common parlance, Windows NT and
   all  of its  subsystems together  constitute  a single  operating
   system.    They do  not  distinguish  the  POSIX Subsystem  as  a
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 3 Because  the parties  appear to  be  in agreement
   that the  internal structure  of Windows  NT Advanced  Server and
   Windows NT Workstation is the  same, for all purposes relevant to
   this case, in  this decision we will make  no distinction between
   the two systems, but refer instead to them as "Windows NT."  
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   "separate" operating  system.   Transcript at  220, 328,  419-20,
   852, 965.
 
 
        46.  On  the issue  of whether  Windows  NT is  one or  more
   operating systems, testimony from  the expert witnesses diverged.
   One  expert  in  operating system  architecture,  a  professor of
   computer  science from the University of Maryland with impressive
   credentials, was  called by C3 to  testify.  In his  opinion, the
   Windows NT POSIX Subsystem  (plus the kernel and the part  of the
   Win32  Subsystem that  controls  input/output)  is an  "operating
   system"  in and  of itself.    Transcript at  561-62, 586.   This
   expert contends that with the Win32 Subsystem and  OS/2 Subsystem
   as well, Windows  NT is  a "multiple operating  system."  Id.  at
   558.  He  bases his opinion on the meaning  of "operating system"
   as  that term  is currently  understood by  professionals in  the
   field of  research with  whom he interacts.   Id.  at 549.   This
   witness, however,  did testify  that  he himself  might refer  to
   Windows NT as a single  operating system in "common" parlance and
   that  books on  computers by  computer business  people refer  to
   Windows NT as one operating system.  Id. at 575-76.
 
        47.  Another expert  witness, called  by C3, with  extensive
   experience and  personal involvement  in the  development of  the
   POSIX.1  standard, described the Windows NT implementation of the
   POSIX  API as a  "cooperating-hosted" implementation.   Using the
   definition of  "cooperating-hosted system" appearing in  the NIST
   testing  policy  (Finding  37), he  concluded  that  the "another
   operating system"  mentioned in  that definition  is in  fact the
   Windows NT POSIX Subsystem and the kernel.  Transcript at 631-37;
   C3 Hearing  Exhibit 3.   Accordingly, he rejects the  notion that
   Windows NT in its entirety is a POSIX-certified operating system.
   Transcript at  646.  This  witness is  of the  opinion that  even
   within  the  Windows  NT documentation,  there  is  no consistent
   description  of an  operating  system.   Id.  at  662.   He  also
   observes  that, over  time, there have  been many  different ways
   that people have described operating systems.  Id.  We note that,
   in his testimony, this witness  himself referred to Windows NT as
   an "operating system" -- albeit "a multiple environment operating
   system."  Id. at 625-26.       
 
        48.  A   senior   architectural   engineer   for   Microsoft
   Corporation was asked  at the hearing if  Microsoft ever referred
   to the combination of the POSIX Subsystem, the kernel  and a part
   of the  Win 32  Subsystem as the  "POSIX operating  system."   He
   replied  that he  had not heard  it referred to  in that fashion.
   Rather, he  explained that Microsoft  considers the system,  as a
   whole,  to  be  a "POSIX-compliant  operating  system  because we
   provide POSIX interface to the operating system."   Transcript at
   417-20; C3 Hearing Exhibit 1.  
 
        49.  An  author  and  expert  in  the  use  of  the  POSIX.1
   interface  to develop  portable applications,  called by  Unisys,
   testified  on  the  issue  of  whether Windows  NT  is  a  single
   operating system.   He  stated that from  the perspective  of "an
   applications programmer,"  Windows NT  -- "the box  I buy  at the
   store [that]  says Windows  NT operating system"  -- is  a single
   operating system.  He based this opinion on the fact that Windows
   NT  "provides me [the programmer] different environments in which
   to develop programs."  Transcript at 1197, 1223-24.
 
 
        50.  Another  witness called by  Unisys and qualified  as an
   expert in system  integration and evaluation of  computer systems
   against  government  RFP  requirements,  testified  that  in  his
   opinion Windows NT was one operating system.  Transcript at 1260-
   62.
 
        51.  Technical   and   promotional  literature   issued   by
   Microsoft and in  the record refer to Windows NT  as an operating
   system. Protest  File, Exhibit  650 at  xviii-xix.   Reference is
   made to  Windows NT as "An Operating System  for the 1990s."  Id.
   at 1.  Elsewhere, Microsoft describes Windows NT as:
 
        a preemptive, multitasking operating  system based on a
        32 bit  design.   It includes  security and  networking
        services  as   fundamental  components   of  the   base
        operating   system.      Windows   NT   also   provides
        compatibility with  many other operating  systems, file
        systems, and networks.   This operating system  runs on
        both  complex  instruction  set  computing  (CISC)  and
        reduced instruction set computing (RISC) processors.  
 
   Id., Exhibit 651 at 3 (emphasis added).  
 
        52.  What the Microsoft promotional and technical literature
   stresses  with  regard  to  Windows  NT  is  not  that  it  is  a
   multiplicity of operating  systems but that it is  a system which
   offers  "multiple operating system environments."   Protest File,
   Exhibit 650 at 16.   Indeed, one Microsoft publication  observes:
   "An  operating  system is  a  computer program  that  provides an
   environment  in which other  computer programs can  run, allowing
   them to easily take advantage of the processor and of I/O devices
   such as disks."   Id. at 15.   The unique feature  of Windows NT,
   therefore, appears to be that this single operating system offers
   multiple  operating system environments.   This was  confirmed at
   the  hearing when a  senior architectural engineer  for Microsoft
   explained:  
 
        Well,  [there  is]   one  operating  system,   multiple
        environments,  environments where  a user  that may  be
        using  a different operating system would come over and
        say, well, this looks  like an environment I  have seen
        on OS/2  or an  environment I have  seen on,  you know,
        Windows DOS  version, and I can come  over to NT and it
        looks like those operating systems.  
 
   Transcript at 418-19.  
 
        53.  Protesters  point  out  that the  Microsoft  Windows NT
   POSIX  Subsystem POSIX Conformance  Document drafted by Microsoft
   and its APTL refers to  the "Windows NT POSIX Subsystem operating
   system."   Protest File,  Exhibit 673 at  1.   The same document,
   however,  in outlining the  process environment also  states that
   the "operating system name" is "Windows NT."  Id. at 9.   
 
        54.  In  response  to  the requirements  in  C23  and C24.3,
   Unisys proposed  Informix On Line  Dynamic Server Version  6.0 as
   the RDBMS  and Microsoft Exchange  Client as the  electronic mail
   application.   Protest File,  Exhibit 2 at  20607, 20684.   These
   applications interface  to Windows NT  through the Win32  API and
   Win32 Subsystem.  Transcript at 462 (RDBMS), 399-01 (E-Mail).  
 
 
        Unisys' Certifications of POSIX Compliance
 
        55.  In response  to the RFP  requirement, Unisys  submitted
   seven NIST certificates  of validation, one for  each combination
   of  hardware and  operating system  software  proposed.   Protest
   File, Exhibit 2 at 22935-43.
 
        56.  Under the  heading "Implementation  Tested," each  NIST
   certificate  submitted by Unisys lists the product as: "Microsoft
   Windows  NT  POSIX Subsystem,  Version  3.5."    On four  of  the
   certificates, under  the heading  "System Tested,"  the Host  and
   Development Operating System  is specified as  "Microsoft Windows
   NT Server, Version  3.5."  Protest File, Exhibits  616, 619, 620,
   622.  On  the other three certificates, the  Host and Development
   Operating  System   is   specified  as   "Microsoft  Windows   NT
   Workstation, Version 3.5."  Id., Exhibits 617, 618, 621.  
 
        57.  The NIST certifications issued  to Unisys and submitted
   with  its  proposal are  recorded  on  the  NIST Register.    The
   Register entries for all these certifications show a "Cooperating
   Hosted" implementation.  Protest File, Exhibit 623.   
 
        Validation of Compliance With Mandatory POSIX Requirements
 
        58.  The   FEDCAC's   Proposal    Evaluation   Guide   (PEG)
   established  a two-step process for evaluating proposals.  First,
   validators  were  to determine  whether proposals  and associated
   technical  literature  addressed,  in  writing,  every  mandatory
   requirement.   If  a proposal  failed to  do so,  a clarification
   request  (CR) or  deficiency  request  (DR)  was  to  be  issued.
   Protest File, Exhibit  523 at 6-8; Transcript  at 125-26, 130-31,
   158.   The second step in  the evaluation process was  the actual
   evaluation and scoring of each proposal against the  RFP's stated
   evaluation factors.  Protest File, Exhibit 523 at 8-9.  
 
        59.  To validate  whether  the operating  system offered  by
   Unisys was POSIX  conformant, the assigned validator  checked the
   certificates of  validation to  ensure they  matched the  offered
   hardware  and software.    He  also called  NIST  to confirm  the
   certifications.  Transcript at 967-68.  With regard to the Unisys
   proposal, the validator was aware that the POSIX Subsystem was an
   "integral" part  of the operating  system and  found it to  be an
   acceptable implementation of POSIX.1 interface.  Id. at 968-69.  
 
 
        60.  To   validate   whether    the   Unisys-offered   RDBMS
   application ran under  the POSIX operating system,  the validator
   responsible  for  confirming  compliance  with  this  requirement
   reviewed the  Unisys proposal to determine if the application ran
   under the  offered operating system,  Windows NT.   The validator
   did not review  whether the  offered operating  system was  POSIX
   compliant.  He  relied on the validators of  the operating system
   for that determination.  Transcript at 379-80.  The validator did
   not find language in the Unisys proposal that the application ran
   under Windows NT.  He, therefore, issued a deficiency report (DR)
   to  Unisys.   Unisys  responded  to the  DR  with  a letter  from
   Informix that  the RDBMS  application  "runs on  the NT  advanced
   server operating system."  The response satisfied the validator's
   concerns.  Protest File, Exhibit 562; Transcript at 380-84.  
 
        61.  To validate whether the Unisys-offered electronic  mail
   application ran under  the POSIX operating system,  the validator
   responsible  for  confirming  compliance  with  this  requirement
   reviewed   the  Unisys  proposal  for  "words  to  that  effect."
   Transcript at  357-58.   Not  finding such  words, the  validator
   issued a DR to Unisys.  The Unisys  response amended the proposal
   language to  state that the  offered applications "are  Window NT
   applications and run on Windows NT, the POSIX-compliant operating
   system."   Protest  File, Exhibit  565; Transcript  at 359.   The
   validator also  reviewed  the technical  literature  supplied  by
   Unisys  in  response to  the  DR.   Transcript  at  370-72.   The
   validator found this response satisfactory.  Id. at 360-62.  
 
 
   The RFP Requirements Regarding GOSIP
 
        GOSIP and the GOSIP Register 
 
        62.  GOSIP is a Government-wide standard for  communications
   that  is intended  to facilitate  communication, interconnection,
   and interoperability  among computer  systems  that are  acquired
   from different manufacturers.  Protest  File, Exhibit 648 at 1-A;
   Transcript at 728.
 
        63.  The term  X.400  is a shorthand way of referring to the
   Consultative Committee for International Telegraphy and Telephony
   (CCITT)  X.400  specification  for  Data  Communication  Networks
   Message  Handling Systems,  from which  the  United States  GOSIP
   standards  for Message  Handling Systems  are  derived.   Protest
   File, Exhibit 648 at 3 (  1.8.1).
 
        64.  Version  1 of GOSIP (FIPS Pub. 146) provided electronic
   mail and  file transfer services using OSI  standards for Message
   Handling  Systems (MHS) and File Transfer, Access, and Management
   (FTAM).   Version  2  of  GOSIP (FIPS  Pub.  146-1) expanded  the
   requirement  to  exchange  information  using  OSI (Open  Systems
   Interconnection) standards  to  cover  Virtual  Terminal  Service
   (used  for remote  log-ins or  logging-in  on other  systems) and
   other  functions.   Protest  File,  Exhibit 648  at  2.   The RFP
   incorporates by  reference FIPS  Pub. 146-1.   Id., Exhibit  1 at
   10383, 10468, 10756.  
 
 
        65.  The  GOSIP   standard  consists   of  a   seven-layered
   architecture:  Layer  1 (Physical); Layer 2 (Data  Link); Layer 3
   (Network);  Layer 4  (Transport);  Layer  5  (Session);  Layer  6
   (Presentation); and  Layer 7  (Application).   See Protest  File,
   Exhibit  648  at  8-11.   Layers  5  through 7  include  what are
   commonly referred to  as the "upper layer protocols."  Transcript
   at 818, 1085.   This  layered  GOSIP model  is sometimes referred
   to as  a  stack.   Protest File, Exhibit  648 at 9; Transcript at
   767, 771.  
        66.  NIST is  responsible for defining  and interpreting the
   requirements  of  GOSIP.    Protest File,  Exhibit  648  at  1-A.
   Products may  be certified  as conforming to  GOSIP if  they pass
   tests, known  as  abstract  test  suites, approved  by  NIST  and
   performed  by accredited testing laboratories.  Id., Exhibit 1 at
   10468; Transcript  at 727-28;  Hearing Exhibit  J1 at 11,  23-25.
   NIST  has delegated  to the  Joint  Interoperability Test  Center
   (JITC)  in Ft. Huachuca, Arizona, the responsibility of reviewing
   conformance testing results  to determine whether  communications
   products have passed  these tests.  Transcript at  732.  Products
   that  have passed  are listed  on  the GOSIP  register.   Hearing
   Exhibit  J1  at  11-12.    NIST is  the  final  arbiter  on GOSIP
   registration issues.   Transcript at  733; Hearing Exhibit  J1 at
   13. 
 
        The RFP's GOSIP Requirements
 
        67.  A clause in the first part of Section C of the RFP sets
   forth  the  "Open  Systems  Architecture"  requirements  for  the
   solicitation.  Clause C1.5 reads, in part: 
 
        The basic  architecture shall consist  of a  Government
        Open Systems Interconnection  Profile (GOSIP) compliant
        server  to   server  network   and   an  open   systems
        architecture   client    server   network    connecting
        workstations to server.
 
   Protest  File,  Exhibit  1   at  10381.    The  RFP,   therefore,
   differentiates between  GOSIP compliance, which  is required  for
   the  server to server  network, and "open  systems architecture,"
   which is required  for the client server network.   Transcript at
   1077.   Unlike  "GOSIP," the  term  "open systems  architecture,"
   particularly  when the  term is  used in the  lower case,  is not
   limited  to products that  implement federally or internationally
   agreed upon standards.  Rather, the term can include systems that
   make  use of  published protocols  available  to programmers  and
   users.  Transcript  at 718, 806-07; Protest File,  Exhibit 109 at
   7, 9, 17.    
 
 
        68.  Another  provision   illustrating  the   RFP's  limited
   reliance on  the GOSIP standard  is Clause C26, which  sets forth
   the  General Communications Requirements.  It calls for offerors'
   communications networks to support five separate configurations -
   - three of which require use of  GOSIP protocols and two of which
   do not:
 
        -    Offered server to offered  server using GOSIP
             protocols.
 
        -    Offered  server  to   GOE  [Government  owned
             equipment] server using GOSIP protocols.
 
        -    Offered workstations (including  portable) to
             offered  servers.   This configuration  shall
             not  use the  server to  server backbone  for
             workstation to server communications.
 
        -    Offered server to GOE WAN [wide area network]
             using GOSIP protocols.
 
        -    Offered portable and  standalone workstations
             from a remote site to offered server (using a
             modem).
 
   Protest  File,  Exhibit 1  at 10468;  Transcript at  784, 865-66,
   1095-96. 
 
        E-Mail
 
        69.  Section  C24 of the  RFP sets  out the  requirement for
   office automation software to run on workstations.  Protest File,
   Exhibit 1 at  10447.  As already seen, one  of these requirements
   is  for  E-Mail.    A   subrequirement  for  E-Mail  is  that  an
   interpersonal user agent (UA) be  provided.  In very basic terms,
   the function of  a UA is to interact  with the user of  a message
   handling system.  Transcript at 729.  
 
        70.  Amendment  3 to  the RFP  changed the  language of  the
   RFP's  requirement  for  an  interpersonal  UA.    Initially  the
   language read:
 
        An X.400  compliant interpersonal user  agent shall  be
        provided.
 
   Unisys Hearing Exhibit 1.   The change, deleting the words "X.400
   compliant," was in  conjunction with Question and Answer No. 122,
   which was also  published in Amendment 3.   Transcript at 867-68,
   1082, 1153-54.  The Question and Answer referenced the applicable
   provision in Section C24 and read: 
 
        QUESTION:
        Will the Government change the requirement to allow the
        use  of an X.400 gateway between the interpersonal user
        agent and the GOSIP server?
 
        RESPONSE:
        A  solution  including a  gateway  which  satisfies the
        requirement   of    C24.3   meets    the   Government's
        requirement.  See change page C48.
 
   Protest File, Exhibit 1 at 10283.
 
        71.  The RFP defines  a gateway as  [a] logical  or physical
   network  entity  that  interconnects  two otherwise  incompatible
   networks, network nodes, or devices.   Protest File, Exhibit 1 at
   10793 (Attachment 5).  An  expert called by Unisys explained that
   a  gateway is a program that changes messages from one format, or
   protocol, to another.  Transcript at 1083.  
 
        72.  The   Coast  Guard's   liaison  with  FEDCAC   on  this
   procurement testified that the purpose  of Amendment 3 of the RFP
   was to eliminate  the requirement that the  offered interpersonal
   UA be X.400 compliant.  Transcript at 1153-57.  He explained: 
 
             As a result  of the question that was  posed to us
        by the vendors, I worked  with . . . our communications
        experts  from  the  Coast Guard  and  talked  about the
        functionality required by  our electronic mail package,
        . . .  took a  look to  see what  products were  on the
        market  and determined in our opinion  that to keep the
        functionality we needed in  our electronic mail package
        and  increase competition, as  long as they  provided a
        gateway, that would meet our needs.  
 
   Id. at 1155.  This  witness further explained that by eliminating
   the phrase "X.400  compliant," it was then possible  for a vendor
   to meet the  electronic mail requirement without  offering a user
   agent which met the GOSIP standard.  Id.
 
        73.    There  are  a  number  of  other  ways  to  meet  the
   functionality specified  for the UA called  for in the RFP.   The
   number of  UAs which  are fully X.400  compliant is  very limited
   (not  more  than  three  or  four).    On  the  other  hand,  one
   knowledgeable witness estimated that there are hundreds of Uas on
   the   market  which   are  not   certified  as   GOSIP-compliant.
   Transcript at 702, 717; see also id. at 1083-84.   
 
        74.  As already noted, the UA offered by Unisys  in response
   to the  RFP's E-Mail  requirement is  Microsoft Exchange  Client.
   See Finding 54.  
 
        Message Handling System
 
        75.    The RFP  contains  a  message handling  system  (MHS)
   requirement.  Protest File,  Exhibit 1 at 10471.  Under the X.400
   standard, which deals with message handling systems, such systems
   contain an interpersonal UA and  a mail or message transfer agent
   (MTA).   Protest File, Exhibit 198 at  4; Transcript at 407, 694,
   729, 788.   In  the typical configuration,  the UA  is associated
   with the workstation  and the MTA with the server.  Transcript at
   819, 1078.   As noted, in very  basic terms, the function  of the
   user agent  is to interact with the user  of an MHS.  Finding 69.
   On the other hand, the function of an MTA is to  deliver messages
   to and from the user agent.  Transcript at 729.
 
        76.  The protocols  associated with a  fully GOSIP-compliant
   UA and MTA are,  in descending order of the GOSIP  model: P2, P1,
   Reliable  Transfer  Service  (RTS) and  Session.    Protest File,
   Exhibits 161 at 41, 198 at 1; Hearing Exhibit J1 at 22-23, 26.   
 
        77.  P2 is  the Application Layer  protocol associated  with
   the UA.   It defines the content of the  electronic mail message.
   Transcript  at 698, 731,  777-79, 1074-75; Protest  File, Exhibit
   198 at 4 (figure 3); Hearing Exhibit J1 at  23-24; Unisys Hearing
   Exhibit 4.   
 
        78.  P1 is the  Application Layer protocol that  defines the
   communication  between  mail  transfer  agents  and  is  commonly
   referred to  as the  "envelope" for the  message.   Transcript at
   1074-75; Protest  File, Exhibit 198  at 4; Hearing Exhibit  J1 at
   23; Unisys Hearing Exhibit 4.     
 
        79.  RTS  is the protocol that ensures the reliable transfer
   of messages.   Transcript at 731.  It  is defined in CCITT X.410.
   Protest  File,  Exhibit 198  at  1;  Hearing  Exhibit J1  at  23;
   Transcript at 731.   
 
        80.  The  Session Layer  is defined in  FIPS Pub.  146-1 and
   allows   cooperating  application   entities   to  organize   and
   synchronize conversation and to manage data exchange.  Transcript
   at 767-68; Protest File, Exhibit 648 at 10, 16.  
 
        81.  The  Industry/Government  Open   Systems  Specification
   (IGOSS)  Testing Framework  utilized by testing  laboratories and
   NIST lists a number of  register categories.  Category P-6 covers
   X.400   products   and   has  the   following   possible  testing
   combinations:  
 
        P1 + RTS/Session + Registered Transport Platform
        P1 + RTS + Registered Transport Platform
        P2 + P1 + RTS/Session + Registered Transport Platform
        P2 + P1 + RTS + Registered Transport Platform
        P2 + Registered P1 Platform
 
   Protest File, Exhibit 161 at 49.   
 
        82.  The first  two listings  of X.400  products in  the P-6
   category  of the IGOSS  Testing Framework represent "incremental"
   GOSIP registration because a product registered under one  of the
   first two IGOSS  architectures would not by itself  be capable of
   operating as an X.400 end system.  This is due to  the absence of
   a  P2  user  agent.    Transcript  at  739-40.    By  incremental
   registration, a  manufacturer of  an electronic  mail product  is
   able  to  register  a  subset  of  the  required  protocols   and
   functionality of an MHS and then, at a later point in time, claim
   support  for different  protocols  and additional  functionality.
   Id. at 740, 1118.    
 
        83.  As noted, normally,  the term "Message  Handling System
   (X.400)" refers  to an E-Mail system  that consists of both  a UA
   and an MTA  that comply with the  OSI protocols set forth  in the
   X.400 standard.  Transcript at 775-77, 1085.  However, as already
   seen,  under the  IGOSS  testing  framework,  the  term  "Message
   Handling System (X.400)" can be used to refer to products that do
   not  contain a  UA.   See  Finding 81.   This  is  precisely what
   occurred with regard to the Microsoft  product proposed by Unisys
   in response  to the MHS  requirements of the  RFP.  For  the MHS,
   Unisys     proposed     Microsoft     Exchange     X.400     (84)
   MTA.[foot #] 4    Protest   File,  Exhibit  2  at  20684.    This
   product  is  listed  on  the GOSIP  register  under  the  Product
   Code/Type:   "P-006 MHS."  Id.,  Exhibit 118 at 251  (product Id.
   No. 309).    Under the  "Additional  Info" heading  in  the GOSIP
   register entry for this MTA, the JITC describes the product as an
   "End System MHS-84 MTA."  Id.  
 
        84.  The  specific MHS  requirement  in  the  RFP  reads  as
   follows:   
        C27.2     CLIN 0930, Message Handling System (X.400).  
 
        Contractor shall provide a Message Handling System that
        complies  with Sections  4.2.5 and  4.2.7.3  of the  V2
        Technical Specifications  portion of FIPS 146-1.  GOSIP
        registration  of  MHS  shall  be  in   accordance  with
        paragraph 26.1.1.
 
             27.2.1  The OSI protocols required to support
             the   Message   Handling  System   shall   be
             provided.
 
             27.2.2   X.400 envelopes  shall be capable of
             carrying as  a  minimum  the  following  file
 
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 4 As  noted  elsewhere, Unisys  proposed  Microsoft
   Exchange Client in response to the E-Mail requirement of the RFP.
   Finding 54.   Microsoft  Exchange Client  and Microsoft  Exchange
   Server constitute Microsoft's client/server distributed messaging
   system.  Both Exchange Client  and Exchange Server are Windows NT
   applications.  Protest File, Exhibit 2 at 20684.   
 
                   ----------- FOOTNOTE ENDS -----------
 
 
 
             types  as  attachments  (body  parts):    IA5
             (ASCII) and binary.
 
             27.2.3      CLIN    0940,   X.400   Messaging
             Capability.  X.400 messaging capability shall
             be provided  for interpersonal  messaging, to
             include an application  programming interface
             and  required  libraries  so  user  developed
             applications may take advantage of the  X.400
             capability (i.e.  database access  and update
             via   electronic    mail).       Programmatic
             interfaces  and  libraries are  required  for
             access  to the  Message Transfer  Agent (MTA)
             and the User Agent (UA).
 
   Protest File, Exhibit 1 at 10471.  
 
        85.  A witness  called by Unisys and recognized by the Board
   as  an  expert   on  X.400  mail  systems   and  GOSIP-conformant
   Government  networks,  discussed in  detail  the requirements  of
   C27.2.[foot #] 5    In   his  opinion,  this  provision   of  the
   RFP  does not  call for  a  UA and,  therefore, does  not require
   compliance with the UA protocol, P2.  He reads C27.2 as requiring
   compliance  with two  important  sections  of  FIPS  Pub.  146-1,
   namely: Section 4.2.5 (which refers to the  Session protocol) and
   Section 4.2.7.3 (which  refers to the RTS protocol).   In C27.2.1
   he reads a requirement that  these upper layer protocols run over
   the  GOSIP transport  stack.   In  C27.2.2, he  notes that  X.400
   envelopes customarily involve  the P1 protocol.   As for  Section
   27.2.3,   he  reads  this  requirement  as  seeking  a  messaging
   capability which would permit the Coast Guard to take data from a
   database and then automatically interface it into a mail message.
   This does  not require use  of the P2  protocol.  Indeed,  in his
   opinion, this  requirement would  be somewhat  difficult to  meet
   using that protocol.  In short, this expert reads Clause C27.2 as
   calling  for  an MHS  which  provides  the  P1 protocol  for  the
   envelope, the RTS protocol, and the Session protocol in the upper
   GOSIP layers and  runs over or  is supported by  the open  system
   interface  protocols in  the  lower levels  of  the GOSIP  stack.
   Transcript at 1085-88.  
 
        GOSIP Registration of Unisys' MHS
 
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 5   Counsel for  C3 has  objected  to this  witness
   being recognized  as an  expert on the  ground that  his academic
   credentials  are of  questionable  worth.   Quite apart  from the
   witness'  academic training,  the Board  found  him qualified  to
   speak  as an  expert based  on his  experience as  an independent
   consultant.   His experience  includes designing for  the Federal
   Government   major   systems  integration   solutions   involving
   integration of networks, integration of E-Mail and, specifically,
   GOSIP certification ofE-Mail systems.  Transcript at 1049-54.    
 
                   ----------- FOOTNOTE ENDS -----------
 
 
 
        86.  The  RFP requires that all proposed GOSIP software that
   has  NIST-approved  test suites  "shall  be listed  on  the GOSIP
   Register  maintained by the Joint Interoperability Test Center in
   Ft.  Huachuca, AZ."   Protest File,  Exhibit 1  at 10468.   Under
   another provision  in the  RFP, entitled  Certification for  FIPS
   146-1, the RFP further requires:  
 
        The offeror shall submit a letter of certification that
        all  parts of the  offered GOSIP network  software (all
        layers)  for which a NIST-approved test suite exists is
        [sic]  listed on the  GOSIP Register maintained  at the
        Joint Interoperability Test Center in Ft. Huachuca, AZ.
        This letter of certification shall be due no later than
        the start of the apparent winner LTD.  
 
   Id., Exhibit 1 at 10629.
 
        87.    Microsoft,  through  an  accredited  test laboratory,
   sought to have the Microsoft  Exchange MTA registered by the JITC
   as an MTA that passed conformance testing for the test suites for
   Session, RTS, and P1.  JITC officials were uncertain as to how to
   handle  the request  that the  MTA  be registered  without a  UA.
   Protest  File, Exhibits  643, 644;  Transcript at  733-36.   JITC
   referred the matter  to NIST.  A NIST official ruled that the MTA
   should be  listed on the GOSIP  Register.  He testified  that, in
   arriving  at  this decision,  he  referred to  the  IGOSS Testing
   Framework which  is the  guideline which  GOSIP conformance  test
   laboratories  must follow.   He  reviewed  that register  product
   category, "P-6: X.400  Products," which  is listed  in the  IGOSS
   document.   There he found  the five  different architectures  or
   combinations  of OSI  protocols.    See Finding  81.   This  NIST
   official testified that the Microsoft Exchange X.400 (84) MTA fit
   into the  first architecture  listed in the  IGOSS, namely  "P1 +
   RTS/Session + Registered Transport Platform."  Transcript at 736,
   749-51.  
 
        88.  This same NIST official testified that the registration
   of the  Microsoft Exchange X.400  (84) MTA was consistent  with a
   policy  of permitting  products to  be  developed and  registered
   "incrementally."  Transcript at 740.  Because the offered product
   did not  contain an X.400  GOSIP conformance tested UA,  the NIST
   official directed  that language  be included  with the  register
   entry to make  note of that fact.   Id. at 740-41.   The language
   reads:  "End System  MHS-84  MTA;  unlikely  to  operate  without
   associated   conformance  tested   P2.     Support  of   Relaying
   capabilities not claimed and not  tested."  Protest File, Exhibit
   118 at 251 (Product Id. No. 309).
 
        89.  Notwithstanding  the cautionary  language contained  in
   the  GOSIP Registry  entry,  the  Microsoft  Exchange  MTA,  when
   working in  conjunction  with its  non-GOSIP-compliant  UA,  does
   provide the messaging functionality required by the RFP.  A Coast
   Guard  official  has  testified  that  at  a  pre-BAFO  live test
   demonstration,  Unisys  was  required to  demonstrate  the  X.400
   compliance for all  offered workstations by establishing  them as
   X.400 clients and  passing mail messages between  offered servers
   over the offered server-to-server local area network and over the
   Government-owned   equipment   wide   area   network.      Unisys
   successfully   did  so.    Transcript   at  933.    In  addition,
   Microsoft's  lead OSI test  engineer for Microsoft  mail products
   testified that Microsoft  Exchange Client and Microsoft  Exchange
   Server  are known  to interoperate with  many X.400  products and
   that Microsoft Exchange has the functionality of P2.  Id. at 692,
   700-01,  723.   Finally, the  NIST official  responsible for  the
   comment published with  the Microsoft Exchange  MTA entry in  the
   GOSIP  register testified  that  he did  not intend  the registry
   wording to mean that the registered product operating with a non-
   X.400  conformant UA  could not  interoperate  with other  E-Mail
   systems.   Rather, he claims  the language was meant  to indicate
   that, because the UA is not  a P2 UA, one does not have  an X.400
   MHS  and  thus the  MTA cannot  be  said to  operate in  an X.400
   context.  Id. at 742-43.  
 
 
        90.  The  certification  of  GOSIP   software  which  Unisys
   provided to FEDCAC  is based on the understanding  that the GOSIP
   registration  and certification provisions of the RFP require one
   registration for  each of  the GOSIP  software products  offered.
   The certification  it provided  does not  claim a  GOSIP register
   listing for  each combination of  registered transport platforms.
   Protest File, Exhibits 2 at 22921, 118; Transcript at 864-65.  
 
        Tisoft's Agency Protest and Amendment 25
 
        91.  Tisoft  believed  in  November 1994  that  the  RFP was
   ambiguous as  to whether  offered MHS products  would have  to be
   registered as tested  in conformance with P2.  Tisoft, therefore,
   filed an  agency protest  requesting that the  RFP be  amended to
   require specifically that the offered MHS be registered "based on
   Session, RTS, P1-MTA  and P2  testing" so as  to assure that  all
   offerors  were competing  on an  equal  basis.   In its  protest,
   Tisoft also asked for additional  time for offerors to have their
   products listed  on the GOSIP  register.  In its  agency protest,
   Tisoft specifically identified Microsoft Exchange X.400 (84)  MTA
   as a  product which is listed on the  GOSIP Register but "has not
   been validated for  P2 layer."   Tisoft sought confirmation  that
   such a  registration was not  compliant with requirements  of the
   RFP.  Protest File, Exhibit 130.
 
        92.  Tisoft's protest prompted FEDCAC  to issue Amendment 25
   to the  RFP.   This amendment  provided offerors  with additional
   time  to  obtain a  listing  on  the  GOSIP  register.   It  also
   contained the following question and answer: 
 
        Q:   Would the  Government please  clarify how  an
             X.400  product becomes  listed  on the  GOSIP
             register as  required by K-34 [the  RFP GOSIP
             certification requirement]?
 
        A:   There  are multiple  test scenarios  that can
             lead  to  a  product  being  listed   on  the
             register depending on  the particular offered
             solution.   Each vendor should  contact their
             testing   laboratory   and   determine   test
             requirements based on their offered solution.
 
 
   Protest File, Exhibit 1 at 10003. 
 
        93.  Tisoft read Amendment  25 to  be a  repudiation of  its
   position  that the only category of conformance testing allowable
   under the  RFP for  an X.400 product  required P2  testing (along
   with testing  for P1,  RTS, and  Session).  Unisys'  Supplemental
   Motion to Dismiss Tisoft's Protest as Untimely, Exhibit 2 at 160.
   Nevertheless,  because  it  had  obtained  additional   time  for
   testing, Tisoft elected  to withdraw its agency protest.   Id. at
   151.        
 
   The RFP's Live Test Demonstration (LTD) Requirements 
 
        Server Requirements
 
        94.  The  RFP called  for a  range of  four servers,  one to
   support  a maximum  configuration  of 8  concurrent workstations,
   another to support 16 concurrent workstations, a third to support
   32 and a  fourth to support 64 concurrent  workstations.  Protest
   File, Exhibit 1 at 10388.  
 
        95.  Under    a    section   entitled    "Internal    Server
   Architecture,"  the  RFP  calls  for  various  components.    For
   purposes of  this decision, we  note two.   One is  random access
   memory (RAM) (Section 6.1.1.2.2).  Offerors were to provide a RAM
   adequate to support  the maximum number of users  for each server
   size.  Protest File,  Exhibit 1 at 10390.   Another component  is
   "Direct Access Storage," or "DAS" (Section 6.1.6).  Offerors were
   required  to provide  one "initial"  disk drive  for each  server
   (CLIN  0013)  (Section  C6.1.6.1.1).   Besides  the  initial disk
   drive, offerors were required to propose small, medium  and large
   "expansion"   drives   (CLINs   0014   through   0016)   (Section
   C6.1.6.1.2).  Id. at 10392. 
 
        96.  Attachment  13 of the  RFP directed offerors  to submit
   system configuration diagrams.  These diagrams were to show  both
   minimum and  maximum configurations.  "Minimum  configuration" is
   defined as  "a configuration  which meets  the minimum  mandatory
   Section C requirements  with the minimum  amount of hardware  and
   software."     "Maximum   configuration"   is   defined   as   "a
   configuration  which  not  only  meets   the  applicable  minimum
   mandatory  Section C  requirements  but  maximizes  the  proposed
   hardware  and software  upper limits  .  . .  ."   Protest  File,
   Exhibit 1  at 10830.   The  RFP provided  that these  minimum and
   maximum configuration diagrams  would become part of  the awarded
   contract (Section L15.1.10).  Id. at 10646.
 
        LTD Requirements
 
        97.  The RFP provides  that after the submission  of initial
   proposals,  each offeror  shall  demonstrate the  16-user  system
   capabilities expressed in the RFP using the software and hardware
   components  proposed.   In  addition to  this  pre-BAFO LTD,  the
   apparent winner is also required  to demonstrate the 8-user,  32-
   user and  64-user system capabilities as well  using the software
   and  hardware components  proposed.   Protest File, Exhibit  1 at
   10660.    
        98.  For  the pre-BAFO  and apparent  winner  LTDs, the  RFP
   instructs offerors to propose configurations of the servers to be
   utilized   using    the   format   of    minimum/maximum   server
   configurations provided  in Attachment  13 of  the RFP.   Protest
   File,  Exhibit  1 at  10646.    The LTD  configuration  diagrams,
   although  formatted  in  accordance  with  guidance contained  in
   Attachment  13, are nonetheless  contained in a  separate section
   (Subpart H) of the technical proposal.  Id.
 
        99.  Attachment   4  of  the  RFP  delineates  the  specific
   requirements  of the  two  LTDs.   This includes  the permissible
   minimum configurations of  necessary equipment to run  the tests.
   The limitation on memory is the same for both LTDs.  Attachment 4
   provides  that "the  memory utilized  for  the LTD  should be  no
   greater than  the  minimum memory  as proposed."   Protest  File,
   Exhibit 1  at 10769 (pre-BAFO LTD), 10782  (apparent winner LTD).
   The  language regarding permissible initial disk drives, however,
   differs for  the two LTDs.   For the  pre-BAFO LTD, Attachment  4
   states:  
 
        Direct   access   storage   device  as   specified   in
        C6.1.6.1.1.[[foot #] 6]
 
   Id. at 10769.  For the apparent winner LTD, Attachment 4 states: 
 
        Direct  access   storage  device(s)  as   specified  in
        C6.1.6.1.1.
 
   Id.  at 10782 (  2.2.1.6) (8-user server), 10783 (  2.2.3.6) (32-
   user server), 10785 (  2.2.5.6) (64-user server).
 
        100. The RFP provisions in Attachment  4 permitting offerors
   to use more than one direct access storage device at the apparent
   winner  LTD  prompted  a  question  from  one  offeror  which was
   answered by the Government in the following fashion:    
 
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 6 This clause reads: "C6.1.6.1.1 CLIN 0013, initial
                                       C6.1.6.1.1 CLIN 0013, initial
   Disk Drive.
   Disk Drive.
   Provide one  DAS device capable  of storing all  orderable server
   and workstation software, listed in  section C3.4, plus at  least
   200  MB additional formatted  storage available."   Protest File,
   Exhibit 1 at 10392.   
 
                   ----------- FOOTNOTE ENDS -----------
 
 
 
        QUESTION:
        In  Section  2.2  of  Attachment  4,  the  instructions
        indicate that the items  listed therein, except memory,
        comprise the  minimum amount of  equipment necessary to
        accomplish each  LTD.   In paragraphs  2.2.1.6, 2.2.3.6
        and  2.2.5.6, which  pertain to direct  access storage,
        the  word  device(s) seems  to  indicate  that multiple
        drives can be used.  In light of this apparent consent,
        can the offered expansion drives (i.e. CLINs 0014, 0015
        and/or 0016)  be used during  the tests in  addition to
        the stated minimum?
 
        RESPONSE:
        It is  not acceptable  to use  CLINs 0014, 0015  and/or
        0016 for  the  8, 32  and/or  64 user  LTDs.   For  the
        mentioned tests, they must show the following:
             8 User Test         CLIN 0001 and CLIN 0013
             32 User Test        CLIN 0001 and CLIN 0013
             64 User Test        CLIN 0001 and CLIN 0013
 
   Protest  File, Exhibit  1 at  10011.   In stating  that expansion
   drives  could not  be used,  the  Government's response  does not
   correct  the offeror's interpretation  that multiple initial disk
   drives can be used.
 
        Unisys Proposal
 
        101.  Unisys proposed one  disk drive, the Fujitsu  M2694ESA
   1.08  GB SCSI-II  Disk Drive,  in response  to C6.1.6.1.1  for an
   initial  disk drive  (CLIN 0013).    Protest File,  Exhibit 2  at
   20209.  
        102.  In  Attachment 13  of  its technical  proposal, Unisys
   proposed only one initial disk drive (CLIN 0013) in the "minimum"
   configurations of  all  four types  of  servers.   Protest  File,
   Exhibit  2 at 23758  (8-user), 23761 (16-user),  23764 (32-user),
   23767 (64-user).   Similarly,  for the "maximum"  configurations,
   although  Unisys proposed multiple  expansion drives, it proposed
   only one initial disk drive (CLIN 0013) for each type  of server.
   Id.  at 23759 (8-user),  23762 (16-user), 23765  (32-user), 23768
   (64-user).  In all cases the  disk drive proposed is the  Fujitsu
   make.  
     
        103.  In  Subpart   H  of  its  technical  proposal,  Unisys
   proposed  to  use one  initial  disk  drive  (CLIN 0013)  in  its
   configuration of the 16 user server at the pre-BAFO LTD.  Protest
   File, Exhibit 2 at  22895.  For the  apparent winner LTD,  Unisys
   proposed  to use  two  initial  disk drives  (CLIN  0013) in  the
   configurations of the 32 and 64  user servers.  See id. at  22907
   (32-user),  22909 (64-user).   The technical manager  for Unisys'
   proposal has testified that two initial disk drives were included
   in Unisys' proposed  LTD configurations because of  the amount of
   storage  space necessary to  accommodate all of  the requirements
   for completing the LTD tests.  Transcript at 879-80, 911-12.
 
        104.  Tisoft calls our attention to  the fact that Section H
   of Unisys' proposal  contains one LTD  configuration for the  64-
   user server  which shows under CLIN  0013 a quantity of  only one
   initial  disk drive.   Protest File, Exhibit 1  at 22899.  Tisoft
   also notes that  a configuration relating  to the 32-user  server
   lists  CLIN 0013 twice but describes it first as an "Initial Disk
   Drive" and then as a "Medium Expansion Drive."  Id. at 22900.  In
   balancing this evidence against the clear listing of two  initial
   disk  drives  (CLIN  0013)  in  other  32-user  and  64-user  LTD
   configurations,  also contained  in  Section  H  (id.  at  22907,
   22909), and the  testimony of Unisys'  technical manager for  the
   proposal, we nonetheless find as fact that Unisys intended to and
   did propose  the use  of two  initial disks  (CLIN 0013) for  the
   apparent winner LTD of the 32-user and 64-user servers.
 
        105.  Unisys conducted  its  apparent winner  LTD using  two
   initial disk  drives (CLIN  0013), as proposed  for the  LTD, for
   both the  32-user and the  64-user tests.  Protest  File, Exhibit
   611 at 5 (unnumbered); Transcript at 204-06.    
 
        C3's LTD Proposal
 
        106.  A witness called by Unisys and recognized by the Board
   as  an  expert in  the  evaluation  of computer  systems  against
   Government  RFP  requirements  testified  that  he  reviewed C3's
   proposal with respect  to what it proposed  to use in the  way of
   initial  disk drives  on its  server at  the 32-user  and 64-user
   apparent winner  LTD.  He  reported that C3 proposed  an approach
   similar to that  proposed by Unisys, namely, to use more than one
   initial disk drive (CLIN 13).  Transcript at 1248, 1307.  
 
 
   Open System Requirements
 
        USCG Open Systems Policy and This Procurement
 
        107.  For  the purposes  of  this  RFP,   Open  Systems   is
   defined as:
 
        those computers and  networks that conform to  the Open
        Systems  Environment concept as defined in NIST Special
        Publication  500-187.  This includes but is not limited
        to the Government  Open Systems Interconnection Profile
        (GOSIP) for networking.
 
   Protest File, Exhibit 1 at 10794.
 
        108.  NIST  Special   Publication  500-187  is   called  the
    Application   Portability  Profile   or   APP  Guide.     As  it
   describes itself, the APP Guide  is intended to provide a catalog
   of federal standard specifications from which  procuring agencies
   may choose  when drafting an RFP.   Protest File, Exhibit  109 at
   iii.  
 
        109.  The APP  Guide provides  the following description  of
   the open systems environment concept:  
 
             An Open  System Environment [OSE]  encompasses the
        functionality  needed   to  provide   interoperability,
        portability,    and    scalability    of   computerized
        applications  across networks  of heterogeneous  multi-
        vendor hardware/software/communications platforms.  The
        OSE forms an extensible framework that allows services,
        interfaces, protocols,  and supporting data  formats to
        be defined  in terms  of nonproprietary  specifications
        that  evolve  through   open  (public)  consensus-based
        forums.  
 
             A selected suite of specifications that define the
        interfaces, services, protocols, and data formats for a
        particular  class or domain of applications is called a
        profile.  The  Application  Portability  Profile  (APP)
        integrates industry, Federal,  national, international,
        and  other  specifications into  a  Federal application
        profile  to  provide  the  functionality  necessary  to
        accommodate  a  broad   range  of  Federal  information
        technology requirements.  
 
   Protest File, Exhibit 109 at 1.  
 
        110.  The Mission Needs Statement for this procurement notes
   that  the Coast  Guard  has  experienced  difficulties  with  its
   existing  computer environment due  to the proprietary  nature of
   the computers currently in use.  The Statement reads in part:
 
        The current contract [Standard Workstation II] supports
        the  Coast Guard's  1986  requirements and  technology.
        Commercial off-the-shelf solutions  now exist that were
        not available when  our current  contract was  awarded.
        Several   third    party   solutions    to   facilitate
        interoperability  between  the  proprietary  BTOS  [now
        CTOS] and non-BTOS computers exist, but  are not on the
        current requirements  contract.  This  limits the Coast
        Guard's access  to important  data networks  in outside
        agencies  and  organizations resulting  in  delays when
        performing functions beyond basic office  automation.  
 
 
   Protest File, Exhibit 501 at 2.  
 
        111.  Internal  Coast  Guard  documents  reflect  the  Coast
   Guard's desire to move to open systems.  For example, the Mission
   Needs  Statement notes that the CGSWIII procurement "must provide
   a  federal  standards  based  open  system  environment,  support
   interoperability  with  the  Coast  Guard's  existing  base,  and
   provide  migration  services  to  facilitate  the  move  to  open
   systems."   Protest  File, Exhibit  501 at  cover page.   Another
   example  is   Coast   Guard   Commandant   Instruction   5230.45,
    Information  Systems Technology  Architecture,  dated  September
   19, 1991.  It reads: 
 
 
        This document  describes the Coast  Guard's Information
        Systems Technology  Architecture based  on open  system
        concepts.  .  .  .   A  significant  change  from  past
        practice  is  a  move  toward the  government  standard
        described  by  National  Institute   of  Standards  and
        Technologies  (NIST)  Application  Portability  Profile
        (APP)/Open Systems Environment (OSE).  
 
   Id., Exhibit 547, Appendix F at 1.  
 
        112.  Coast  Guard   representatives  have   testified  that
   CGSWIII  is intended  to provide  a "migration  path" to  an open
   systems environment.   Transcript at 142, 147, 282-85,  319.  The
   RFP contains  several general  requirements consistent  with this
   notion of  planned migration from the current CTOS environment to
   an open systems environment.  One has already been noted: Section
   C1.5 of the RFP distinguishes between  GOSIP compliance, which is
   required  for the  server  to server  network, and  "open systems
   architecture," which is  required for the client  server network.
   See Finding 67.  
        113.  Consistent with recommendations in  the APP Guide, the
   RFP  requires  offerors  to propose  hardware  and  software that
   conform to various standards listed  in the Guide.  Transcript at
   175, 281-82, 917.   Section C2 of the  RFP, entitled  Standards, 
   specifies  the particular  standards to  which  the RFP  required
   offered proposals to adhere:
 
        2.1  NIST Standards.   The Contractor  offered hardware
        and software shall comply with selected sections of the
        National Institute  of Standards and  Technology (NIST)
        Application  Portability  Profile (APP),  as  specified
        herein.
 
        2.2  FIPS  Standards.    Equipment and  software  shall
        conform to the Federal Information Processing Standards
        (FIPS),  guidelines  and  other  standards  listed   in
        Attachment 1.  All revisions to currently approved FIPS
        shall  be  incorporated  into  the appropriate  offered
        products and submitted to the Coast Guard as Technology
        Enhancements  within 12  months of  publication  of the
        final version of the new FIPS.
 
        2.3  RDBMS Standards.   The Coast  Guard will establish
        the  offered  multi-user  RDBMS  as  its  standard  for
        database application development.
 
   Protest  File, Exhibit 1 at 10383.  The RFP reveals the following
   FIPS standards referenced in various provisions: 
 
        Standard  Description                   RFP Reference(s)
 
        FIPS 1-2  ASCII character set           C6.1.2.2,
                                                C7.2.1.6.1,
                                                C9.2.2, C9.2.9,
                                                C9.3.1, C10.1.5
        FIPS 107  IEEE 802.3 LANs               C29.2
        FIPS 109* Pascal Language               C21.5
        FIPS 119* Ada Language                  C21.6
        FIPS 127-1*    Structured Query Language (SQL)    C16.3
                                                          . 3 ,
                                                          C21.1
                                                          . 6 ,
                                                          C23.1
                                                          . 1 ,
                                                          C23.1
                                                          . 4 ,
                                                          C23.1
                                                          .17,
                                                          C23.1
                                                          .20.2
                                                          ,
                                                          C23.6
                                                          . 3 ,
                                                          C24.8
                                                          .1.3
        FIPS 128  Computer Graphics Metafile (CGM)   C19.3.2.4
        FIPS 146-1*    GOSIP Version 2               C26.1.1,
                                                     C27.2 
        FIPS 147  CCITT Group III Fax           C8.1, C8.1.1
        FIPS 151-2*    POSIX.1                  C17
        FIPS 160* C Programming Language        C21.3
        FIPS 174  Twisted Pair LAN cable        C29.5
 
        * = Referenced in NIST APP. (Protest file, Exhibit 109)
 
   Id., Exhibit 1.   The RFP also incorporates a variety of industry
   (de facto) standards, including:
 
        Standard       Description              RFP Reference(s)
        ANSI/NFPA 70-1990   National Electric Code        C4
        ANSI Y14.1          Standard Paper Sizes          C10.1
                                                          .7
        ANSI Terminal       Terminal Emulation       C25.3
        ASCII Text          Text format files        C23.1.8,
                                                     C23.1.9,
                                                     C24.4.19
        ISO 9660       CD-ROM Specification          C6.1.6.4,
                                                     C7.1.2.12.
                                                     4, C13.1
        IEEE 754       Floating Point Unit      C6.1.1.6
        SCSI-II        Peripheral Interface          C6.1.6.1,
                                                     C6.1.6.3,
                                                     C6.1.7,
                                                     C6.1.8,
                                                     C6.1.8.4,
 
                                                     C7.1.2.14.
                                                     2,  C13.1,
                                                     C14
        RS232               Serial Peripheral Interface   C6.1.
                                                          8   ,
                                                          C6.1.
                                                          8.1,
                                                          C7.1.
                                                          2.14.
                                                          1.1,
                                                          C7.2.
                                                          1.11.
                                                          1   ,
                                                          C8.2.
                                                          6   ,
                                                          C29.3
                                                          .2
        Centronix I/F       Parallel Peripheral Interface C6.1.
                                                          8.3,
                                                          C7.1.
                                                          2.14.
                                                          1.2,
                                                          C7.2.
                                                          1.11.
                                                          2
        IEEE 802.3          LAN Interfaces           C6.1.9.1,
                                                     C28.1,
                                                     C29.2,
                                                     C30.1.1,
                                                     C30.1.4,
                                                     C30.2,
                                                     C30.3
        ISO 9314       FDDI Interfaces          C29.1, C30.1.3
        ISDN           Integrated Services           C26.1.4, C29.3,
                       C30.1.5
                       Network
        X.25 CCITT 1988     Public Data Networks          C6.1.
                                                          9.3,
                                                          C29.4
                                                          ,
                                                          C30.1
                                                          .2
        X.25 DDN 1984  Defense Data Networks         C6.1.9.3,
                                                     C29.4,
                                                     C30.1.2
        V.32, V.42, etc          Modem Standards          C7.2.
                                                          1.10.
                                                          2   ,
                                                          C8.2.
                                                          2   ,
                                                          C8.2.
                                                          3
        EIA/TIA-568         Unshielded Twisted Pair  C31.2
                       Cabling Specification
 
        TCP/IP         Internet Protocol Suite       C26.1.3,
                                                     C28.1,
                                                     C28.2
 
   Id.
 
        114.  In  drawing up the RFP's requirements, the Coast Guard
   attempted to maximize competition.  Transcript at 274, 279,  916.
   The  Government's  technical  group made  judgments  on  what was
   technically possible to maintain full  and open competition.  Id.
   at 273.   On occasion this meant not  making certain requirements
   subject to particular OSE standards.  For example, the Government
   rejected requiring compliance  with FIPS 158  (XWindows graphical
   user  interface) because it would  have required a UNIX solution.
   Id.  at 274,  924.   The Government  rejected requiring  a native
   POSIX implementation because that too would have  required a UNIX
   solution.   Id.  at 323.   The Government  did not  require GOSIP
   compliance between servers and workstations because it would have
   been too restrictive.  Id. at 256-57.  The decision was also made
   not to require a GOSIP-compliant user agent.  See Finding 72.  
 
        115.  The   RFP's   stated  evaluation   criteria   required
   compliance with  all  minimum mandatory  requirements.    Protest
   File, Exhibit 1  at 10690.  The RFP did not, however, contain any
   evaluation  factors concerning  the method  by  which an  offeror
   implemented  the various required  standards or how  the products
   providing   the   functionality   of   the   required   standards
   interoperate with one another.
 
        Unisys' Proposal
 
        116.  Unisys proposed to  meet all of the  federal standards
   required by the RFP and to provide an "open system" architecture.
   Its proposal reads: 
 
        The  basis  for  our solution  is  combining mainstream
        technology   and  open   systems  standards   with  the
        experience of a seasoned systems integrator.  
 
        The Unisys  solution is  based on formal  and de  facto
        standards to meet  the Coast Guard's goal of total open
        systems  compatibility.     Formal   standards  include
        Federal  Information  Processing Standards  (FIPS)  and
        international  standards  defined by  NIST,  ISO, IEEE,
        CCITT and others.   De facto standards  include Market-
        driven   standards  including   TCP/IP,  Intel,   CPUs,
        EISA/ISA expansion, and Microsoft Windows.  
 
   Protest File, Exhibit 2 at 20028.
 
        117.  As  already  noted,  Unisys  proposed  the   Microsoft
   Windows  NT  operating  system.    Finding  42.    The  Technical
   Solutions Manager for Unisys' proposal explained that the company
   had originally intended to  bid a UNIX-based operating system  on
   the servers.   Eventually, however, it decided to  use Windows NT
   for both servers and  workstations.  This witness  explained that
   Windows NT was selected because it:
 
 
        evaluated very, very  favorably against the  evaluation
        criteria  when  it  comes  to  the  ease  of  use,  the
        consistency of the way the software works; and also for
        our criteria of offering a solution to the Coast  Guard
        based on mainstream-type technology.
 
   Transcript at 844.
 
        118.  Several   witnesses   testified    that   Windows   NT
   applications   run   on  many   hardware   platforms,   and  that
   applications that run  under the Windows NT  operating system are
   widely available.    Transcript at  167, 513,  1020-22.   Unisys'
   Technical Solution  Manager for  this procurement  made it  clear
   that this was one of the reasons why Unisys ultimately elected to
   propose Windows NT.  Id. at 844-46.  A representative of Informix
   also  testified  that his  company  had recently  taken  steps to
   ensure this  RDBMS would run  on Windows NT.   He  explained that
   this  was done  in order  to  have maximum  portability of  their
   product to other environments such as Windows and other platforms
   that they know  are becoming available in this  environment.  Id.
   at 461-62.  
 
        119.  Microsoft's  Director  of   Technology  Marketing  and
   Standards testified that one objective  of the company is to make
   sure  Windows  NT,  as an  operating  system,  provides the  best
   possible open system support.  He stated:  
 
        [T]he more sets  of interfaces that we can support, the
        more number of  systems that we can  interoperate with,
        the higher degree of integration we can provide between
        applications  and  the ability  to integrate  data from
        different applications  and systems, the  more benefits
        accrue  to the  user and,  you know,  that's then  what
        fuels them to buy  more product, that's what  fuels the
        growth of the industry.  
 
   Transcript at 1015.   This witness  then cited Microsoft's  "open
   process" as an example of the company's  open system support.  He
   stated:  
 
        [Microsoft] maintain[s] what we  call the open process.
        The open  process is  a methodology  that allows  us to
        produce  specifications of  different technologies  and
        make  those  specifications  available  to  members  of
        industry, to end users, to different end user companies
        that may purchase product,  to standards organizations;
        and  those   specifications  then   can  be   reviewed,
        commented upon;  the comments are sent  into Microsoft,
        the  specs may  be updated.   Eventually, we  do design
        previews  and we again  invite many from  the industry,
 
        many companies to  come and view that.   A good example
        would be the WIN-32 interfaces. . . . The specification
        for  WIN-32 was  available .  .  . close  to two  years
        before the  first product  on the  market to  implement
        those interfaces existed . . . .
 
   Id. at  1015-16.   The API required  to write  applications under
   Windows NT is published and readily available.  Id. at 917, 1016-
   17.
 
 
   DataFocus' Association With Unisys
 
        120.  The  introduction  to  Unisys'   proposal  contains  a
   section entitled   Unisys:  Assembling  a World Class Team.    In
   this section, Unisys addresses the  roles which the various  team
   members have played and will play in conjunction with the CGSWIII
   procurement.  Protest File, Exhibit 2  at 20025.  With regard  to
   one  of  the  team  members, DataFocus  Inc.,  Unisys  states  as
   follows: 
 
        DataFocus Inc.
        DataFocus   is  a  proven   developer  of  Coast  Guard
        Mission-critical     applications,    including     the
        Operational  Intelligence  &  Security  System,  SCAMP,
        AMIS, Personnel Allowance System, and USCG Laws System.
        In addition, DataFocus  has been retained  by Microsoft
        to enhance  the POSIX  subsystem for  the NT  operating
        system.
 
   Id. at 20027 (emphasis added).
 
        121.  The president of DataFocus  testified that his company
   has  had agreements with  Microsoft Corporation  in the  past and
   that there was  a specific signed agreement during  the period of
   the CGSWIII RFP to enhance  the POSIX Subsystem and utilities for
   the Windows NT operating system.  This agreement expired sometime
   in   mid-1993.     Since   then  he   has  talked   to  Microsoft
   representatives  about additional  work which  might  be done  to
   enhance the capabilities  of Windows NT to respond  to additional
   specifications that are coming out of various standards agencies.
   As of the date of  this witness' testimony, however, no agreement
   had been  entered.   Transcript at 514-17.   A  representative of
   Microsoft has confirmed the existence of DataFocus' past contract
   with  Microsoft  to  assist with  the  enhancement  of  the POSIX
   Subsystem.  Id. at 1012, 1028, 1031, 1033.
    
                               Discussion
 
   Unisys' Proposal and POSIX Compliance
 
        Despite  the complexity of the facts relating to protesters'
   allegations  regarding  Unisys'  failure  to  comply  with  POSIX
   requirements  of the  RFP, the  ultimate question to  be resolved
   here  is  a  relatively  simple one.    Is  Windows  NT a  "POSIX
   operating system" as that term is used in the RFP?  The RFP calls
   for POSIX-compliant operating systems.  Finding 18.   It likewise
   requires that the RDBMS and E-mail run "under the POSIX operating
   system."  Findings 26-27.  If Windows NT is not a POSIX compliant
   operating system, then  protesters clearly prevail on  all counts
   of their protests which allege non-compliance with POSIX or which
   are founded on that assumption.  
 
 
        Based on the  record before us, we conclude  that Windows NT
   is  a POSIX-compliant operating  system and that,  therefore, the
   two  applications which  Unisys  has offered  and  which the  RFP
   expressly  requires to  run under  a  POSIX operating  system are
   acceptable.    The RFP  does  not require  these  applications to
   actually use the POSIX interface.     
 
        Given the  arguments put  forward by  protesters, the  first
   question we  must address  is whether Windows  NT is one  or more
   than one operating  system.  Ironic as  it may seem, we  find the
   testimony of  C3's experts  on this question  to be  too erudite.
   The  conclusion reached  by  C3's experts  that  there is  within
   Windows NT a separate and distinct POSIX operating system strikes
   us  as hypertechnical  in the  extreme.   We would  certainly not
   anticipate  that either the  Government or an  experienced vendor
   would draw such a distinction  in considering whether Windows  NT
   measures up  to the plain  meaning of the RFP's  operating system
   requirement.   On  the  other hand,  the  testimony from  Unisys'
   experts, Government  representatives, industry  professionals and
   the  product  literature  of Microsoft  itself  convince  us that
   Windows NT  can readily be  understood as an operating  system as
   that term is  used in this RFP.   See Findings 19,  43-45, 48-52.
   Indeed,  even  C3's experts  recognize  that on  a  less abstract
   level, Windows NT can readily be described in real world terms as
   an operating system.  Findings 46-47.
 
        In concluding  that Windows NT is a single operating system,
   however, we  are only  half way to  resolving the  protest counts
   regarding alleged POSIX  non-compliance.  The second  question is
   whether  Windows  NT  is  a  POSIX-compliant  operating   system.
   Testimony provided for the record by NIST employees has proven to
   be very helpful in this regard.  In a previous decision, based on
   a less complete record, we inaccurately found as fact that a NIST
   certification  under  FIPS  151-2  is  effective  to  certify  an
   operating system.   Control Data Systems,  Inc. v. Department  of
   the Treasury,  GSBCA 12876-P, 94-3 BCA   27,167, at 135,370; 1994
   BPD   182, at  3.  At the  hearing for the two  instant protests,
   NIST representatives have made it clear that this is not correct.
 
 
        These  NIST  witnesses  have explained  that  NIST  does not
   certify  operating systems as  POSIX compliant, but  rather, only
   the compliance of a system's  specific POSIX interface.   Finding
   41.  The RFP itself requires that the offered operating system(s)
   "shall conform to FIPS 151-1 or subsequent versions" by including
   the  POSIX  standard  and having  validation  in  accordance with
   provisions  contained  in  FIPS  151-1  or  subsequent  versions.
   Finding 21.    Consequently,  if  NIST issues  a  certificate  of
   validation for a  specific POSIX interface and that  interface is
   an  integral  component  of the  host  and  development operating
   system  on  which  the  validation   tests  were  run,  it  seems
   reasonable to us that one can,  at that point, conclude that  the
   operating system is itself POSIX-compliant  -- at least as far as
   that term should be understood within the context of this RFP.  
 
 
        In  this  case,  the certificates  provided  by  Unisys list
   Windows NT as the host and development operating system.  Finding
   56.   The record  confirms that the  POSIX API in  the Windows NT
   POSIX  Subsystem is  in  fact  an integral  part  of Windows  NT.
   Findings 43-44.   The issuance  of the NIST  certificates confirm
   that  the validation  tests  have  been  successfully  run  using
   Windows  NT.  Finding 55.  We consider it reasonable to conclude,
   therefore,  that Windows NT is a POSIX-compliant operating system
   for purposes of this RFP.
 
        We recognize, of course, that the NIST Testing Policy states
   that  "the  product  identified represents  the  operating system
   tested."  Finding 38.   Furthermore, it is correct that  the NIST
   certificates  submitted by  Unisys  list  the  Windows  NT  POSIX
   Subsystem as the "product."  Nevertheless, we are not prepared to
   conclude  from  this fact  that  the Windows  NT  POSIX Subsystem
   represents a  subsystem distinct from Windows NT.  Testimony from
   individuals  experienced  in  the  NIST  certification  procedure
   indicates that the  identification of the  "product" is a  matter
   left mainly to the APTL and that entries made by the APTL are not
   modified  by NIST.   In  addition,  an experienced  NIST employee
   testified that  only in  cases of  native implementation does  it
   occur  that  the  product   identified  actually  represents  the
   operating  system   tested.     Id.    As   we  have   seen,  the
   implementation   of   the   Windows   NT  POSIX   interface   was
   "cooperating-hosted."  Findings 39, 57.   
 
        Having  thus concluded that the operating system proposed by
   Unisys was a POSIX-compliant operating system, we turn now to the
   specific  requirement that the RDBMS and E-Mail applications "run
   under  the  POSIX  operating  system."    It  is  true  that  the
   applications proposed by  Unisys for RDBMS and E-Mail  do not use
   the POSIX Subsystem interface but rather the Win 32 API.  The Win
   32  Subsystem  is,  however,  an  integral  part  of  Windows NT.
   Findings 43-44.   Because this system is  itself POSIX-compliant,
   we  find  that these  two  applications  do,  in fact,  meet  the
   requirement that they run under the POSIX operating system.  
 
        Both  protesters  would   have  us  conclude,  because   the
   requirement to "run under the  POSIX operating system" is used in
   the solicitation only  for the RDBMS and E-Mail,  that this means
   these two applications, in contrast to the  others, were actually
   required to use the POSIX interface.  We do not regard the phrase
   "run   under  the  POSIX   operating  system"  as   specifying  a
   requirement to use the POSIX  interface.  Rather it is sufficient
   if the RDBMS and E-Mail use an operating system integrated with a
   validated  POSIX interface.   This  interpretation  is the  least
   restrictive and recognizes the development of advanced  operating
   systems tightly  integrated  to  a variety  of  interfaces.    As
   already stated,  we find the  Unisys proposal in  compliance with
   the requirement as it reads.  We, therefore, do not read into the
   phrase more than what is actually there.   
 
 
        Furthermore,   we  have   been  given   a  highly   credible
   explanation for why  this language was added to  the RDBMS and E-
   Mail requirements.  The intent was to preclude the possibility of
   emulation  for these two critical applications.  Findings 31, 33-
   34.  Expert  testimony convinces us,  however, that the  language
   does  not  achieve this  purpose.    Finding 32.    Consequently,
   despite the Coast  Guard's intent, we will not  read the language
   as precluding applications which rely on emulation.     
 
        Protesters' allegations  that the  Unisys proposal  fails to
   comply with  mandatory requirements  regarding POSIX,  therefore,
   are denied.  We likewise deny C3's contention that the Government
   lacked sufficient  knowledge to assess properly Unisys' assertion
   of  compliance  with POSIX  requirements.   Also  denied  is C3's
   contention that the respondent misevaluated whether Unisys' RDBMS
   and     E-Mail     run      under     the     POSIX     operating
   system.[foot #] 7           We     find      the     Government's
   interpretation  of the  RFP requirements  and  the validation  of
   compliance with them to be correct.  See Findings 58-61.  
 
 
   Unisys' Proposal and GOSIP Compliance
 
        The critical  issue underlying  the protesters'  allegations
   that Unisys' proposal does not comply with  GOSIP requirements of
   the RFP  is precisely  what the  RFP means  when it  calls for  a
   "message handling system."   The protesters argue  that, strictly
   speaking, an  MHS must include a UA.  Therefore, for an MHS to be
   on  the GOSIP  register, it  should be  tested for  all protocols
   associated  with  a  fully  GOSIP-compliant  UA  and  MTA.   This
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 7 In a  motion filed  on March  29, shortly  before
   trial, Unisys asked us to dismiss these and two other allegations
   of  C3 as  untimely filed.   Unisys'  argument regarding  all the
   allegations is  that they are  nothing more than a  recasting, by
   amendment, of  the basic  allegation contained  in C3's  original
   protest.   Unisys had  already asked us  to dismiss  the original
   allegation as  untimely.  By  decision dated March 30,  we denied
   Unisys'  earlier  motion  to  dismiss  C3's  initial  protest  as
   untimely.   C3, Inc.  v. General  Services Administration,  GSBCA
               _____________________________________________
   13201-P, et al. (March 30, 1995).  Our first decision effectively
            ______
   eliminated the predicate of Unisys' subsequent motion to dismiss.
   Accordingly, for the record, we now deny the subsequent motion as
   well.   
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   includes P2, the protocol associated with a UA.  Unisys, GSA, and
   the  Coast  Guard  contend  instead  that in  this  RFP  the  MHS
   requirement is not inclusive of a UA and, therefore, the MHS need
   not be tested for P2 in order to be listed on the GOSIP register.
 
 
 
        Given the terms of the  RFP, we find that the interpretation
   of  the MHS  requirement adopted  by Unisys,  GSA, and  the Coast
   Guard is correct while  that supported by protesters is not.   We
   say  this because  in this  RFP there  is an  altogether separate
   provision  calling for  a UA.    We consider  it only  logical to
   assume that the requiring agency expects it will be this UA which
   will interact with  the MTA offered with  the MHS much as  any UA
   would which might  otherwise be offered with the  MTA in response
   to a typical MHS requirement.
 
        Protesters consider the  separate UA requirement in  the RFP
   to be  a relatively unimportant factor in determining whether the
   UA should be  GOSIP-compliant.  They contend that  it is separate
   from  the  MHS  requirement  only  because  the  orders  for  the
   workstations (in which the UA is to reside) will  be separate and
   in greater quantity than orders placed for servers.  We disagree.
   The  RFP's UA  requirement does  not call  for  GOSIP compliance.
   This   accords  neatly  with  Clause  C1.5  (Finding  67),  which
   distinguishes between a GOSIP-compliant server to server  network
   and open system architecture which  may not be limited to federal
   or   internationally  agreed   upon   standards.[foot #] 8     It
   likewise squares readily with the RFP communications requirements
   (Finding  68)   which  do   not  require   GOSIP  protocols   for
   communications from  offered  workstations  to  offered  servers.
   Finally, the record  shows that an earlier requirement  for GOSIP
   compliance was deliberately  removed from the UA provision by the
   Coast Guard in order to enhance competition.  Findings 70-73.  
        We are, therefore, convinced that within the context of this
   RFP, the UA requirement has been deliberately broken out from the
   MHS requirement and  that the MHS requirement of  Clause C27.2 is
   not inclusive of a UA.     
 
        In  response  to  the MHS  requirement,  Unisys  has offered
   Microsoft Exchange Server.   Finding 83.   In response to  the UA
   requirement,  Microsoft  has offered  Microsoft  Exchange Client.
   Finding  54.    The  two   clearly  work  together  as  one  MHS.
 
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 8 In  this regard  we note  in  passing that  while
   Microsoft Exchange does not follow the P2 protocol for its UA, it
   does make use of an  interface known as MAPI (Message Application
   Program  Interface)  to  communicate  with  its  associated  MTA.
   Transcript  at 698.  While MAPI is proprietary, in the sense that
   it  was developed  by  Microsoft,  it is  an  open and  published
   protocol, registered by the American National Standards Institute
   (ANSI)  as  a standard  API  for  messaging,  and is  a  publicly
   available standard.  Id. at 715, 718.  
                        ___
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   Nevertheless, we find that the proposed use of Microsoft Exchange
   is in compliance with the RFP.  
 
 
        There is no requirement under the RFP for Microsoft Exchange
   Client  to be  GOSIP-compliant.   Findings 70-74.   It  need not,
   therefore, be listed on the  GOSIP register.  It should, however,
   and   apparently  does  have  the  ability  of  interacting  with
   Microsoft   Exchange  Server   to  meet   the   RFP's  functional
   requirements for messaging.  See Finding 89.   On the other hand,
   there  is  a  definite  requirement that  the  MTA  in  Microsoft
   Exchange be on the register -- and it is.  Findings 83-85, 90.  
 
        Unisys has certified  that the Microsoft Exchange MTA  is on
   the GOSIP Register.  We  find the certification offered by Unisys
   to be adequate.  Any  suggestion that a separate registration for
   each  platform  or  configuration is  required,  similar  to that
   called for in the RFP  to demonstrate POSIX compliance, is simply
   not supported  by the  language of the  RFP.  Compare  Finding 86
   with Finding 25.  The RFP's requirement for registration of GOSIP
   software states only that the  GOSIP software "shall be listed on
   the  GOSIP  Register .  .  .  ."   See  Finding 86.    We  see no
   requirement   for  multiple  registrations.[foot #] 9            
 
 
        The cautionary language included in the GOSIP register entry
   from Microsoft Exchange X.400 MTA does not trouble us.  While the
   listing of the MTA was sufficient for purposes of this RFP, there
   is no indication  that the NIST official who  ultimately ruled on
   the request for  listing was aware of the  various RFP provisions
   which support  the interpretation of  the MHS requirement  as not
   inclusive  of a UA.   Furthermore, if  he believed this  to be an
   "incremental" listing, one  can readily understand why  he deemed
   it appropriate to add the cautionary note.  Finally, from his own
   testimony as  to the  intent of the  language, we  understand his
   ultimate concern was not over any possible lack of  functionality
   but with  the prospect that persons consulting the Register might
   incorrectly conclude that  Microsoft Exchange, taken as  a whole,
   is GOSIP-compliant.  See Finding 89.      
 
        The reasonableness of the Government's position on the issue
   of GOSIP compliance is further strengthened by the fact that this
   is  not  the first  time  that  the issue  has  surfaced  in this
   procurement.   Tisoft's agency  protest and the  RFP amendment it
   prompted alerted  vendors to the fact that  "[t]here are multiple
   test  scenarios that  can lead to  a product being  listed on the
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 9 On March 15, C3 filed a motion for summary relief
   based on  the allegation that  Unisys did not have  the requisite
   number of  GOSIP  certifications  required by  the  RFP  for  the
   proposed FTAM and MHS.  The  Board deferred ruling on the  motion
   until  after  it  heard  testimony on  this  and  related issues.
   Having  now  decided this  issue on  the merits  and in  favor of
   Unisys, we dismiss the earlier motion as moot.  
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   register  depending on the particular offered solution."  Finding
   92.  The fact  that an approved testing  laboratory chose to  use
   one scenario  as opposed  to another and  that NIST  concurred in
   this and directed JITC to  list the MTA of Microsoft Exchange  on
   the  GOSIP Register  should not  come  as any  great surprise  to
   protesters.[foot #] 10        Amendment    25    to    the    RFP
   unquestionably  left  the  way  open  for this  to  occur.    The
   interpretation which the  Coast Guard and FEDCAC now  give to the
   MHS requirement  is consistent with  the amendment while  that of
   the protesters is not.
 
 
        Unisys  contends that  because of  Tisoft's agency  protest,
   Tisoft  is now  untimely in  alleging  that the  MHS proposed  by
   Unisys  fails  to meet  RFP  requirements with  regard  to GOSIP.
   Accordingly   Unisys   has   moved  that   we   dismiss  Tisoft's
   allegations.   We  deny the  motion.   Although apparently  still
   convinced that the  RFP was ambiguous even after  the issuance of
   Amendment  25,  Tisoft,  nevertheless, chose  not  to  pursue its
   demand  for clarification.   Instead,  it  withdrew its  protest.
   Finding 93.  Tisoft and C3, at  this point in time, are basically
   in  the same  position.   They  elected  to  go to  BAFO  without
   challenging the language of the amendment.  Certainly the time to
   challenge the  language of  the amendment has  now passed.   Rule
   5(b)(3)(i).  Protesters may, however, challenge the compliance of
   Unisys with this  and other related provisions of the  RFP.  This
   is what we  understand them to have  done in these protests.   In
   pressing their cases, however,  they can no longer challenge  the
   language of  Amendment 25 or  related provisions.  They  must now
   abide  by  the  interpretation  the  Government  gives  to  these
   provisions as long as the interpretation is a reasonable one.  As
   we have pointed out in the past: "Those vendors who fail  to seek
   clarification are  bound by respondent's  interpretation, if that
   interpretation  is  reasonable  and less  restrictive."    Hughes
   Advanced  Systems  Co.,  GSBCA  9601-P,  89-1  BCA    21,276,  at
   107,323,  1988 BPD   253, at 39-40;  accord HFS, Inc. v. National
   Archives  and Records Administration,  GSBCA 12010-P, 93-2  BCA  
   25,812, 1993  BPD    40; Racal  Information Systems,  Inc., GSBCA
   10264-P, 90-1 BCA   22,495, 1989 BPD   368.  
      
        Given   the  considerations  set  out  above,  we  find  the
   Government's  position correct and most certainly to be preferred
   because  it  is   less  restrictive  of  competition.     Sysorex
   Information Systems, Inc., GSBCA 11151-P, 91-2 BCA   23,979, 1991
   BPD    103; Perception  Technology,  GSBCA  9883-P,  89-2  BCA   
   21,667,  1989 BPD    85; Xerox  Corp., GSBCA  9862-P, 89-2  BCA  
   21,652, 1989 BPD   68.
 
         Accordingly,  we  deny  C3's  allegation  that  the  Unisys
   proposal fails to  comply with  mandatory requirements  regarding
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 10 This is  especially true with regard  to Tisoft,
   which expressly mentioned this possibility in its agency protest.
   See Finding 91.
   ___
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   GOSIP.  We likewise deny the allegation of Tisoft that the Unisys
   proposal   was  non-compliant  with   the  RFP  requirement  that
   communication software be certified as fully GOSIP-compliant.  
 
 
   Open System Requirements
 
 
        Both  protesters contend that Unisys' proposal fails to meet
   the  open system  requirements of  the  RFP with  respect to  the
   portability and interoperability of various application programs.
   They  contend that  the  POSIX  Subsystem of  Windows  NT is  not
   integrated in a  coherent manner with the other  tools offered by
   Unisys  in response to  the RFP's APP  requirements because those
   other tools are strictly associated  with the Win 32 Subsystem of
   Windows NT and not the POSIX Subsystem.  Tisoft observes: 
 
             The consequence  of Unisys's failure to  propose a
        coherent integrated "open systems environment" is  that
        the  Coast Guard's  critical objectives  of application
        portability  and interoperability  are achievable  only
        within  the  limited bounds  of an  environment tightly
        controlled by a single vendor -- Microsoft.
 
   Tisoft's Posthearing Brief, Vol. II at 41.  
 
        The difficulty  with this protest count is  that it attempts
   to determine  the acceptability of  Unisys' proposal in  terms of
   the proposal's compliance  with the Coast Guard's  OSE policy and
   planning objectives rather than with the specific requirements of
   the  RFP  itself.     The  record  demonstrates   an  unequivocal
   commitment on the  part of the Coast  Guard to establish an  open
   system   environment.    Findings   110-11.    The   record  also
   demonstrates that to this end  the RFP embraces numerous specific
   federal  and industry  standards.   Finding 113.   However  it is
   clear that the Coast Guard did not expect to achieve its ultimate
   OSE objective in toto with this RFP.  Findings 22, 112-13.  There
   are obvious tradeoffs made in the RFP for the sake of competition
   and, presumably, for the savings in cost which hopefully would be
   derived from the competition.  Finding 114.  
 
        The  testimony offered  by C3's technical  experts regarding
   the  achievement  of  greater  portability  and  interoperability
   through  a  more  coherent integration  of  development  tools is
   interesting.  It is not, however, relevant to the task before  us
   here.   What  we  must  determine here  is  whether the  solution
   offered by Unisys meets the specific requirements included in the
   RFP for purposes  of moving the Coast Guard  towards its ultimate
   objective of  an open system  environment.  There is  no specific
   requirement  in the  RFP that  these  various elements  promoting
   portability  and  interoperability  be integrated  to  any stated
   degree or in any specific fashion.   Neither is any more or  less
   credit given  in the  evaluation of proposals  for the  degree to
   which    a    specific   proposal    promotes    portability   or
   interoperability.  Finding 115.  
 
        We have considered  in some detail the  arguments offered by
   the protesters in  support of their  allegations that Unisys  has
   failed to  meet specific requirements  in the RFP  for compliance
   with  the POSIX  and GOSIP  standards.   The protesters  have not
   convinced   us   that    Unisys   has   failed   to    meet   the
   requirements.[foot #] 11            Furthermore,      we      are
   satisfied that the Unisys proposal  does provide the Coast  Guard
   with a greater degree of portability and interoperability than it
   has  had in the past.   See Findings 2,  116-19.  In this regard,
   therefore,  the   acceptance  of   this  proposal   represents  a
   significant step in the right direction  even if another proposal
   might take the Coast Guard closer to its open systems environment
   objective.    
 
        In  short, if  one compliant  proposal results  in a  lesser
   degree  of  portability  or  interoperability  or falls  somewhat
   shorter  of the Coast  Guard's ultimate open  systems environment
   objective than another,  this does not constitute  an independent
   ground  for  its  rejection  in  this  procurement.    Given  the
   structure  of  this  particular  RFP,  the  requisite  degree  of
   portability and interoperability will be whatever results from an
   otherwise compliant proposal.  
 
        Protesters are apparently convinced that the Unisys solution
   does  not promote  the  Coast  Guard's  open  system  environment
   objective   as  effectively   as  their   own  proposals   would.
   Consequently,  they speculate that  the acceptance of  the Unisys
   proposal will have  serious long-range  economic implications  so
   far as future software conversion  costs are concerned.  This may
   or may not be true.  What is certain, however, is that, given the
   structure of  this RFP, it  should have been clear  to protesters
   early  in this  procurement that  the degree  of  portability and
   interoperability resulting  from a  proposed solution  might vary
   from vendor  to vendor.  If  protesters mean to  suggest, at this
   point,  that this  factor should somehow  have been  reflected in
   evaluation   criteria   or   in  the   Government's   best  value
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 11 In its posthearing brief, Tisoft, in addition to
   its contention  that Unisys  has failed to  meet POSIX  and GOSIP
   requirements of the RFP, also contends that certain key APP tools
   offered  by Unisys are  non-compliant with the  RFP requirements.
   Unisys' graphic  user  interface (GUI)  offering  is said  to  be
   deficient because it  does not conform to Motif,  contrary to the
   minimum mandatory  requirement of  C21.8.1, and  because the  GUI
   proposed  for C21.8  does  not  support  the  Extensible  Virtual
   Toolkit  (XVT) called  for  in C16.3.   We  read  C21.8.1 not  as
   requiring Motif,  but only  Motif functionality.   Protest  File,
   Exhibit 1 at  10437.  C3's  own expert confirmed  this at  trial.
   Transcript at 1401.   As  to the  alleged failure of  the GUI  to
   support the XVT,  we find insufficient support in  the record for
   the allegation, especially in the absence of expert testimony and
   evidence regarding FEDCAC's validation of the Unisys' proposal on
   this point.    
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   determination, they  are obviously too late to be heard.  This is
   clearly  a matter  which should  have  been raised  prior to  the
   submission of proposals.  See Board Rule 5(b)(3)(i).  
 
 
        We, therefore, deny  any allegations by protesters  that the
   Unisys proposal  should be rejected  because it does  not provide
   m o r e      e x t e n s i v e     p o r t a b i l i t y      o r
   interoperability.[foot #] 12  
 
 
   The Apparent Winner LTD
 
        Tisoft alleges that  in the apparent winner LTD  for the 32-
   user and  64-user configuration,  Unisys failed  to meet  certain
   mandatory      requirements      of      the      RFP.[foot #] 13
   Specifically, Tisoft contends  that Unisys, by using  two initial
   disk drives in the  LTD of the 32-user server and  of the 64-user
   server,  violated the  RFP  requirement  that  the  hardware  and
   software  used in  the LTD  be identical  to that  proposed.   In
   addition, Tisoft contends  that Unisys' use  of two initial  disk
   drives  violated another RFP requirement that the memory utilized
   at the apparent winner LTD be no greater than that offered in the
   apparent winner's proposal.   
 
        We are not convinced by Tisoft's arguments.  It is true that
   in the configurations offered by Unisys in Attachment 13,  Unisys
   propose  to  use only  one  initial disk  drive  and that  in the
   apparent  winner  LTD  it  used  two.   See  Findings  102,  105.
   However, we  do not  find this to  be in violation  of applicable
   provisions of the RFP.  
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 12 Unisys has moved that we dismiss as untimely the
   open systems counts  in the amended complaints of  Tisoft and C3.
   The argument made by  Unisys is essentially the same as that made
   regarding the  other counts in  C3's amended complaint.   For the
   same reason we denied the motion regarding those other counts, we
   deny the motion to  dismiss the open system counts as  well.  See
                                                                 ___
   supra note 8.  
   _____
 
        [foot #] 13 C3 in its  posthearing brief informs us  that it
   adopts  and incorporates by  reference the findings  and argument
   advanced  by Tisoft in  its own  posthearing brief  regarding the
   impropriety of Unisys' apparent winner LTD.  C3 Posthearing Brief
   at 119.  C3 has made no mention of this issue, however, in either
   its initial or  amended complaints.  Furthermore,  the unrebutted
   testimony of a Unisys expert  is that C3's own LTD configurations
   use an approach similar to that proposed by  Unisys.  See Finding
                                                         ___
   106.   In view  of this, we  disregard C3's support  of Tisoft on
   this issue.  It is well established  that the Board will not hear
   argument from a  protester alleging a flaw  in another's proposal
   when the  protester's own  proposal contains  the same  approach.
   Control Data  Systems, Inc. v. Department of  the Treasury, GSBCA
                   ----------- FOOTNOTE BEGINS ---------
   12876-P, 94-3 BCA   27,167, at 135,374, 1994 BPD   182, at 11.   
 
                   ----------- FOOTNOTE ENDS -----------
 
 
 
        The RFP clearly distinguishes between LTD configurations and
   those proposed for delivery  in the event of award.  Findings 96,
   98.  Under the terms of  the RFP, the configurations proposed for
   use  in the apparent  winner LTD are permitted  to differ in some
   respects  from those offered in  Attachment 13, which become part
   of the  contract.  The  LTD configurations must utilize  the same
   type components as those proposed  in Attachment 13.  Finding 97.
   There is also  a requirement that the memory provided  in the LTD
   configurations be no greater  than that proposed for the  minimum
   configurations described in Attachment 13.  Finding 99.  However,
   one area where  the LTD configuration  is expressly permitted  to
   differ from those proposed in  Attachment 13 is in the  number of
   initial disk  drives permitted.   The  configurations offered  in
   Attachment 13, i.e.  the contractual configurations, are  to have
   no more than one initial disk  drive.  Finding 95.  On  the other
   hand,  the configurations proposed  for the  winner LTD  can have
   more than one initial disk drive.  Finding 99.  
 
        Unisys contends that the additional initial disk drives were
   permitted for the LTD because of the extraordinarily heavy demand
   for storage space  necessary to accommodate all  the requirements
   of the  LTD tests.  We find the  explanation a convincing one and
   note that  not only Unisys but also apparently C3 planned to take
   advantage of this special provision  for purposes of the apparent
   winner LTD.  See Findings 103, 106.  
 
        It is true  that in the  LTDs, offerors are required  to use
   the  software  and  hardware components  proposed.    Finding 97.
   Tisoft appears to understand this requirement as meaning that the
   LTD  configurations  should  be identical  to  those  proposed in
   Attachment  13.    We  think  not.     In  the  context  of  this
   solicitation,  we read this  provision as requiring  instead that
   the actual LTD configurations be  those described in Section H of
   the technical  proposal for use at  the LTD.   We also understand
   this provision to require that  the software and hardware used at
   the  LTD be at least the  same type and make  as that proposed in
   the Attachment 13 configurations.  Given the record before us, we
   conclude  that Unisys  is in  compliance  with this  requirement.
   Unisys  proposed two initial disk drives  for the apparent winner
   LTD of the 32-user and 64-user configurations; two were, in fact,
   used at the LTD.  Finding  105.  In addition, we have  found that
   the   initial  disk   drive  proposed   in   the  Attachment   13
   configurations and  in Subpart H  is the same, namely  CLIN 0013,
   the Fujitsu M2694ESA  1.08 GB SCSI-II Disk Drive.   Findings 102-
   04.  
 
        Tisoft attempts to throw  into question the validity  of the
   applicable  RFP provision permitting  more than one  initial disk
   drive for the apparent winner LTD.  It does this by  arguing that
   the RFP provision  which permits more  than one device  conflicts
   with another RFP  provision limiting the memory  proposed for the
   apparent   winner  LTD  to  that  proposed  for  the  contractual
   configurations.  See Finding  99.  This argument is based  on the
   assumption  that "memory,"  as  used  in  the  latter  provision,
   includes not  only random access  memory but also DAS  devices as
   well.  Tisoft has not referred us to any provision within the RFP
   which utilizes this more expansive meaning of the  term "memory."
   On the other hand, the RFP does speak of "memory" in reference to
   random access  memory requirements.   Finding 95.  This  plus the
   fact that  the RFP expressly  permits more than one  initial disk
   drive  in LTD configurations  (Finding 99) convinces  us that the
   two provisions should  be read in concert with each  other.  This
   leads us to the conclusion that, at least within the four corners
   of this  solicitation, the  limitation on  memory referred  to by
   Tisoft    should   be    understood    as   applying    only   to
   RAM.[foot #] 14  
 
 
        Accordingly,  we deny Tisoft's  count that Unisys  failed to
   meet the mandatory requirements of the RFP in the apparent winner
   LTD.
 
 
   DataFocus's Association with Microsoft
 
        We  turn briefly to C3's allegation  that the statement made
   by Unisys  in  the introduction  to  its proposal  regarding  the
   working relationship between DataFocus and Microsoft is false and
   renders Unisys  ineligible for  award.   The record  demonstrates
   that the statement  is in fact true.  DataFocus  was retained for
   the purpose  stated.   Finding  121.   Unisys  did not  say  that
   DataFocus  and  Microsoft  presently have  such  an  agreement in
   place,   but  simply  that   DataFocus  "has  been   retained  by
   Microsoft."  Finding  120.  We therefore deny C3's count based on
   alleged misrepresentation by Unisys.  
 
 
   The Best Value Analysis and Award Decision
 
        C3  contends  that  the best  value  analysis  regarding the
   Unisys proposal  was fundamentally  flawed because  of the  false
   predicates upon  which it was  based.  C3's Posthearing  Brief at
   153-56.   Unisys  sees this  allegation  as nothing  more than  a
   challenge to stated evaluation criteria which, under Board Rules,
   should  have been  filed prior  to the  time established  for the
   submission of proposals.   Unisys has  moved, therefore, that  we
   dismiss this count as untimely filed.  
 
        We deny the Unisys motion  to dismiss.  Our understanding of
   this count  is that it is  derived from the  other allegations in
                                                                    
                   ----------- FOOTNOTE BEGINS ---------
 
        [foot #] 14 We  recognize that a former FEDCAC employee with
   extensive LTD experience  tentatively concluded in the  course of
   his  deposition that "minimum memory"  includes both RAM and hard
   disk memory.   Hearing  Exhibit J2 at  88-89.  However,  from the
   context of this witness' deposition, we do not understand this to
   be a firm  conclusion or  one based  upon a  careful analysis  of
   other relevant RFP provisions.           
 
                   ----------- FOOTNOTE ENDS -----------
 
 
   C3's complaint  as amended.  We understand C3 to be alleging that
   if  the Unisys  proposal is  not compliant  with POSIX  and GOSIP
   standards   in  the  RFP  and  the   degree  of  portability  and
   interoperability called for in the RFP is not  met, then any best
   value  analysis  and  award  decision  founded  on  the  mistaken
   assumption that these various requirements have been met would be
   fatally flawed.  
 
 
        The  premises of  this  allegation  have  not  been  proven,
   however.   The selection of  Unisys as the  apparently successful
   offeror appears to have been in keeping with the criteria set out
   in the  RFP.   Findings 4-10.   For  that reason,  this count  is
   denied as well.  
 
                                Decision
 
        The  protests of  C3  and  Tisoft are  DENIED.   Our  orders
   suspending  the procurement  authority  of respondent  expire  in
   accordance with their terms.  
 
 
                                                ____________________
                                                EDWIN B. NEILL
                                                Board Judge 
 
   We concur:
 
 
   _______________________
   DONALD W. DEVINE
   Board Judge
 
 
   _______________________
   ANTHONY S. BORWICK
   Board Judge