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