THIS OPINION WAS INITIALLY ISSUED UNDER PROTECTIVE ORDER AND IS BEING RELEASED TO THE PUBLIC IN REDACTED FORM ON SEPTEMBER 7, 1994 ______________________________ DENIED: August 25, 1994 ______________________________ GSBCA 12876-P CONTROL DATA SYSTEMS, INC., Protester, v. DEPARTMENT OF THE TREASURY, Respondent, and FDC TECHNOLOGIES, INC., Intervenor. Joseph J. Petrillo and Jessica C. Abrahams of Petrillo & Associates, Washington, DC, counsel for Protester. Donald M. Suica, Robert H. Humphries, Francis C. Inserra, and Corlyss Drinkard, Office of Chief Counsel, Internal Revenue Service, Department of the Treasury, Washington, DC, counsel for Respondent. James J. Regan, Thomas P. Humphrey, Robert M. Halperin, Kathryn D. Kirmayer, and Christopher M. Farris of Crowell & Moring, Washington, DC; and Ferhan K. Doyle, Doyle & Associates, Rockville, MD, counsel for Intervenor. Before Board Judges PARKER, HENDLEY, and DeGRAFF. HENDLEY, Board Judge. The protester, Control Data Systems, Inc. (CDS), contends that the award made to the intervenor, FDC Technologies, Inc. (FDCT), was improper because its proposal failed to meet a mandatory requirement of the solicitation. The requirement in issue is the technical specification, Federal Information Processing Standard (FIPS PUB) 151-1, POSIX, or "Portable Operating System Environment." We deny the protest. Findings of Fact 1. Solicitation No. IRS-93-0006 (hereinafter referred to as "Solicitation" or "RFP") was issued by the respondent on December 2, 1992. The solicitation contemplated an indefinite quantity, indefinite delivery (IQID) contract for one base year with six option years. Protest File, Exhibit 401. 2. During early 1993, the protester chose its subcontractors, and the components of its solution. Protest File, Exhibits 227, 228. As its original solution, the protester chose a CDS [ ] CPU; the protester's proprietary, enhanced, Unix-based operating system EP/IX; the protester's proprietary Print Control Application (PCA) software, which was designed for, and currently being used on, the IRS Impact Print System; a variety of Siemens Nixdorf printers; and Roll Systems, Inc. pre- and post-processing paper handling equipment. Id., Exhibit 234. 3. FDCT's solution consisted of an IBM ES/9000 (190) mainframe; IBM's MVS/ESA version 4.3 OpenEdition operating system; IBM's JES II and Control D application software; IBM/Pennant printers; and Roll Systems, Inc. pre- and post- processing paper handling equipment. Protester's Supplement to the Protest File, Exhibit 20. The intervenor's solution remained the same throughout the procurement. Id., Exhibit 35. Timely initial proposals from the protester and the intervenor were received on May 3, 1993. Protest File, Exhibit 63. 4. The protester, just prior to the Operational Capability Demonstration (OCD), substituted a CDS 4680-312 CPU for the CDS [ ] CPU. Transcript at 452. The OCD was addressed in solicitation sections L.23 and M.4. Protest File, Exhibit 401. Neither section L.23 nor section M.4 mention POSIX or FIPS PUB 151-1. Id. The solicitation, in Question 51, Amendment 2, gave vendors the discretion to determine what equipment to use at the OCD. Id. The respondent conducted an OCD at a site chosen by each offeror. The intervenor's OCD was conducted in Gaithersburg, Maryland, on June 29-30, 1993; the protester's OCD was conducted in Boca Raton, Florida, on July 15-16, 1993. Id., Exhibits 254, 257. 5. On November 18, 1993, all offerors submitted their Best and Final Offers (BAFOs). Protest File, Exhibit 410. On January 10, 1994, all offerors submitted revised BAFOs. Formal source selection procedures were used. Id., Exhibit 30. In accordance with the source selection plan, a technical evaluation and a business management evaluation were performed and the results reported to the source selection official. Id., Exhibit 173. The Technical Evaluation Panel (TEP) and the Source Evaluation Board (SEB) issued reports on their evaluations. Id., Exhibits 169, 173. The TEP awarded the intervenor's system 198 out of 300 technical points, and the protester's system 106 points. Id., Exhibit 169. The contract was awarded to the intervenor on June 9, 1994. Id., Exhibit 175. 6. The solicitation contained over 100 operational specifications in Section C. Protest File, Exhibit 401. POSIX was addressed in the solicitation provision at C.2 and in Question 4 of Amendment 5, which read as follows: C.2 Systems Specifications Provided within this section are the IRS's input, processing, performance, output, hardware and software requirements. The system provided shall comply with all Federal Information Processing Standards Publications (FIPS PUBS) and Federal Information Standards Publications (FED-STDS) applicable to this requirement. A list of applicable FIPS PUBS and FED-STDS are provided in Attachment 9, Section J. Id. QUESTION: Since FIPS Pub 151-1 is included in Attachment 9 of the RFP, this vendor interprets this as a requirement that any proposed system must be POSIX compliant. If this is incorrect, please clarify. REFERENCE: Section C.2, page 9. ANSWER: The assumption is correct. Id. No vendors submitted any questions seeking clarification of the POSIX requirement or how compliance with the requirement would be verified. Id. Out of approximately 500 questions submitted by vendors, Question 4, above, was the only question submitted regarding POSIX. Id. Subsequent to the issuance of Amendment 5 with Question and Answer 4, no offeror referred to POSIX prior to the date the protest was filed. Id. 7. Neither FIPS PUB 151-1 nor 151-2 applies to applications software, but only to operating systems. Intervenor's Supplement to the Protest File, Exhibit 11; Protest File, Exhibit 423. The National Institute of Standards and Technology (NIST) certification under FIPS PUB 151-2 is effective to certify the operating system under FIPS PUB 151-1. Protest File, Exhibit 425. NIST does not certify applications software. Transcript at 450, 503. POSIX is a set of formal international technical standards describing the interface between an application program and the operating system. Protest File, Exhibit 412. "POSIX is not an operating system, nor does it define what an operating system should be. . . . POSIX defines only the interface between applications and operating systems. An application sees only the POSIX interface, not the underlying operating system." Id. FIPS PUB 151-1 and its successor 151-2 are publicly available software standards for operating systems issued by NIST. Intervenor's Supplement to the Protest File, Exhibit 11; Protest File, Exhibit 423. NIST also publishes its POSIX testing and certification policies. Protest File, Exhibit 425. NIST also publishes, on an electronic bulletin board, a list of all certified POSIX conformant operating systems. Intervenor's Supplement to the Protest File, Exhibit 100; Transcript at 499. In order to be certified by NIST as POSIX conformant, an operating system must be tested by an accredited testing laboratory, and the results submitted to NIST for validation of the results. Transcript at 489-90. 8. Compliance with the POSIX requirement was determined by reviewing the offerors' proposals and technical literature. Transcript at 376. The same procedures were used to evaluate all vendors' representations of compliance with the POSIX requirement in the solicitation. Id. at 382. 9. There is no solicitation requirement or FIPS PUB requirement for applications software provided under the contract to be POSIX compliant. Protest File, Exhibit 401. By definition, applications programs cannot be POSIX compliant. Transcript at 503. POSIX compliance was not an evaluation criterion, nor was it mentioned in section M. Therefore, the degree to which a system was POSIX compliant could not properly be evaluated under section M. Protest File, Exhibit 401. 10. NIST maintains a long list of certified operating systems that were available to the protester to select for its proposal. Intervenor's Supplement to the Protest File, Exhibit 100. The protester's NIST certification was for EP/IX 1.4.2. Protester's Supplement to the Protest File, Exhibit 28; Transcript at 497-98. The protester's operating system, EP/IX 2.1.1, has not been tested by an accredited testing lab or certified by the POSIX administrator as POSIX conformant, on any hardware, under either FIPS PUB 151-1 or 151-2. Transcript at 444, 498. The protester did not attempt to have its EP/IX 2.1.1 operating system certified because of the time and money involved. Id. at 443. 11. The respondent learned of the protester's failure to have its proposed version certified for compliance with the POSIX standard for the first time during discovery on this protest. Protester's Supplement to the Protest File, Exhibit 28; Protest File, Exhibits 423, 425; Intervenor's Supplement to the Protest File, Exhibit 100. 12. The intervenor had its operating system, MVS/ESA Version 4.3 OpenEdition, certified as POSIX conformant under FIPS PUB 151-2, on a different CPU than the CPU it proposed to furnish under the solicitation. Intervenor's Supplement to the Protest File, Exhibit 87; Transcript at 497. The only difference between the ES/9000 (190), the hardware proposed, and the ES/9000 (570), the hardware on which MVS/ESA OpenEdition was POSIX certified, was the speed and size of the CPU. Both CPUs utilize the same software and instruction set. Transcript at 569-71. Speed and size should not affect the ability of a system to successfully perform the POSIX test suite. Operating systems have been certified as POSIX compliant when run on everything from a laptop to a mainframe. Intervenor's Supplement to the Protest File, Exhibit 100; Transcript at 488-89. 13. In its proposal, the intervenor cited the product number of the operating system software it proposed to supply which corresponds to its listing of MVS/ESA, which identifies the operating system proposed as containing the OpenEdition feature. Protester's Supplement to the Protest File, Exhibit 21 (page 12 of B-1 Table). An employee of the intervenor testified that it is the standard practice of the software supplier, IBM, not to identify individual features in its tables. Transcript at 556- 57. For this procurement 118 separate features of the MVS/ESA 4.3 would have had to have been listed if they were to be separately identified. Id. at 565. The OpenEdition feature of MVS/ESA is identified in adequate detail and described in the intervenor's proposal as well as in the proposal's tables by referencing the appropriate product number. Intervenor's Supplement to the Protest File, Exhibit 75 at 65-66. The intervenor identified on its tables the version of MVS/ESA that it was offering. Protester's Supplement to the Protest File, Exhibit 21 (page 12 of B-1 Table). The supporting software packages needed to run MVS/ESA OpenEdition were considered to be part of the MVS/ESA OpenEdition. Transcript at 537-38, 564-69. 14. The protester also did not identify on either its B-Tables or on its components list which version of the EP/IX operating system it was proposing. Protest File, Exhibits 406, 410. However, one could also determine the software it intended to supply by the same methodology used to determine the software the intervenor proposed. 15. The protester did not identify in its BAFO components list or its B-Tables all of the software packages that are integral to its system. Protest File, Exhibits 406, 410. [ ] however, the protester did not separately price, or even specifically identify, the printserver in its B-Tables. Id. The protester bundled some of the software necessary for the printserver to operate, and did not identify all of the software needed to operate its printserver in its proposal or B-Tables. Id. We conclude that both the protester and the intervenor adequately described the functionality of their operating systems in their proposals. Id., Exhibit 407; Intervenor's Supplement to the Protest File, Exhibits 75, 76. 16. The respondent had each offeror's authorized represen- tative sign a certification expressly stating that the offeror was bound to provide the "physical design or functioning character- istics of a machine, software package, or system" described in the offeror's proposal. See Protest File, Exhibit 410 at Solicitation Section K.27. Discussion The protester filed a timely protest on June 17, 1994, alleging three grounds of protest: (1) the intervenor's proposed operating system, MVS/ESA 4.3 "OpenEdition" 1.0, was not POSIX compliant by the date of the OCD; (2) the respondent had delayed award in order for the intervenor's operating system to become POSIX compliant and commercially available by date of award; and (3) the "best value" analysis supporting award to the intervenor was flawed. Protest Complaint. The protester subsequently amended its protest twice: first, to add a fourth count, alleging unbalanced bidding, Amended Protest Complaint; and second, to drop the delayed award count, Second Amended Protest Compliant. Subsequently, the protester withdrew all counts but the POSIX count. On Friday, July 22, 1994, the intervenor moved to dismiss the protest for failure of the protester to meet a minimum mandatory requirement of the solicitation, i.e., the failure of the protester's operating system to comply with the POSIX requirements of the solicitation, the very same requirement that the protester accuses the intervenor of failing to meet. We declined to hear the motion separately, deciding instead that the allegations were the mirror image of the protester's allegations, and, therefore, amenable to resolution through a hearing on the merits. The Solicitation The solicitation was for the supply of printing systems, each consisting of printers controlled by a mainframe-like central processing unit (CPU). Finding 3. The intervenor proposed an IBM mainframe (ES/9000 - 190), the MVS/ESA Version 4.3 OpenEdition Services operating system, and IBM/Pennant printers. Id. The protester proposed a Control Data 4680-312 CPU, Control Data's EP/IX operating system[foot #] 1, and Siemens Nixdorf Printing Systems (SNPS) printers.[foot #] 2 Findings 2, 4. The solicitation required offerors to provide systems which comply with certain specified Federal Information Processing Standard Publications (FIPS PUBS) and Federal Standards Publications (FED STDS), one of which was FIPS PUB 151-1, POSIX: Portable Operating System Interface for Computer Environments, dated March 28, 1990. Finding 6. There is only one reference (in Section J, Attachment 9) to POSIX in the solicitation.[foot #] 3 The solicitation contained well over 100 separately identified specifications, one of which incorporated the POSIX standards by reference. How POSIX Compliance Was Determined Compliance with the solicitation's POSIX requirement was determined by examining the offerors' proposals and technical literature. Finding 8. POSIX compliance was not an evaluation criterion, nor was it mentioned in section M of the solicitation. Finding 9. Consequently, the degree to which a system was POSIX compliant could not be evaluated under section M of the solicitation. Id. The protester sees some significance in the fact that the respondent did not include in the OCD tests at least one test for POSIX conformance. The protester considers this as another bit of evidence that the respondent was not concerned about POSIX compliance. The respondent's evaluators used the same procedure for ----------- FOOTNOTE BEGINS --------- [foot #] 1 The operating system proposed by the protester, like that proposed by the intervenor, is a proprietary operating system which must be licensed from its owner. [foot #] 2 Both the protester and the intervenor proposed Roll Systems, Inc., pre- and post-processing paper handling equipment. [foot #] 3 No offeror objected to the minimal treatment of the POSIX requirement, nor sought clarification of the importance given the requirement. In fact, one of the few pieces of evidence in the record which addresses POSIX is a handwritten statement by the protester's Technical Analyst which states [ ] Protest File, Exhibit 427 (emphasis added). ----------- FOOTNOTE ENDS ----------- determining the compliance of all offerors. Finding 8. Based on statements in their proposals and in their technical literature that the operating systems proposed were POSIX compliant, the respondent's evaluators determined that all offerors complied with the solicitation requirement. Id. During the hearing, the protester implied that there was something inherently inadequate about the method of compliance verification used by the respondent. Transcript at 377. However, the procedures for conducting the OCD had been known to the protester since December 1992. Finding 4. It had known since that time that POSIX was not being tested by the OCD tests. Id. Under our timeliness rules[foot #] 4 an offeror claiming deficiencies in the specifications must raise the issue with the respondent prior to the date set for receipt of the initial proposals. It is too late for the protester to raise concerns about perceived deficiencies in the OCD tests. During discovery, the respondent learned that the release and version of the operating system software, EP/IX 2.1.1, proposed by the protester had never been certified by the National Institute of Standards and Technology (NIST) (formerly the National Bureau of Standards) to conform with the requirements of either FIPS PUB 151-1 or 151-2. Findings 10, 11. The POSIX standard is a public document. Finding 8. The testing and certifying policies implementing the standard are public documents. Id. The list of certified operating systems is a public document, available from electronic bulletin boards. Id. Consequently, the protester should have known that its EP/IX 2.1.1 operating system had not been tested by an accredited lab, and had not been submitted to NIST for verification and validation of the test results and certification. Until the hearing, when the NIST POSIX Administrator stated that the protester's theory that the NIST certification of an earlier version, i.e., EP/IX 1.4.2, of its proposed operating system was effective for later versions and releases of the same operating system was simply wrong, the protester had contended that the intervenor failed to meet the minimum mandatory requirement to propose a POSIX conformant operating system. ----------- FOOTNOTE BEGINS --------- [foot #] 4 Board Rule 5(b)(3). ----------- FOOTNOTE ENDS ----------- As in RGI, Inc. v. Department of the Navy, GSBCA 11752, 93-1 BCA 25,402, 1992 BPD 156, a protester's failure to ascertain what was required (here the nature and extent of the POSIX requirement) led it into the ironic position of failing to comply with the very same mandatory specification it alleged the successful offeror could not meet. In the instant case, the protester did not have the EP/IX 2.1.1. operating system certified because to do so was costly and time-consuming. Finding 10. The POSIX requirement, as interpreted by the protester, the intervenor, and the respondent, was not waived by the respondent. The respondent acted affirmatively to assure itself that the offerors met the requirement. Finding 8. All offerors represented that they met the requirement. Protester and Intervenor Are Not Equal with Regard to POSIX Compliance The intervenor's operating system software was certified by NIST operating on a computer in the family of computers that was offered for the contract. Finding 12. According to the NIST POSIX Administrator, the value of the certificate for the exact same operating system running on a piece of hardware that is different from that identified in the certificate is "up to the acquiring agency. Actually, the rule of thumb . . . is if it's a $1,000 procurement, you might be willing to accept one in the family. If it is a billion dollar procurement, you'd probably want absolutely every model tested." Transcript at 510-11. The hardware model that was certified by NIST differs from the hardware model that the intervenor proposed only in speed and size.[foot #] 5 Finding 12. Indeed, the two models use the same operating system instruction set or commands to the processor. Id. In contrast, the protester's operating system software, EP/IX 2.1.1, has never been certified by the NIST POSIX Administrator, nor has it even been tested by an accredited POSIX testing laboratory, a necessary prerequisite to obtaining certification. Finding 10. Consequently, the protester itself does not comply ----------- FOOTNOTE BEGINS --------- [foot #] 5 Speed and size should have no impact on the ability of a CPU to run a POSIX test because the list of POSIX certified systems contains hardware ranging from desktop PC's to large mainframes. Indeed, the NIST POSIX Administrator testified that the POSIX interface could reside on a mainframe, a laptop, or a scientific computer. Transcript at 569-71. ----------- FOOTNOTE ENDS ----------- with the same allegedly mandatory requirement that it contends the intervenor does not meet.[foot #] 6 In its Second Amended Complaint, the protester contends that the intervenor's proposed operating system is non-compliant because its proposal does not specifically identify the supporting software programs necessary for full functionality of its OpenEdition Services feature, and that the software programs and the OpenEdition feature are not specifically listed in the intervenor's tables. This allegation is not supportable. In addition, as before, the protester's proposal suffers from the same alleged deficiencies. As a factual matter, the protester's allegation is without merit. Regarding the OpenEdition feature of MVS/ESA, the product number corresponding to the B-Table listing of MVS/ESA identifies the operating system proposed as containing the OpenEdition feature. Finding 13. Additionally, the credible testimony of the intervenor's employee and an IBM employee established that it is standard IBM practice not to identify features in its B- Tables. Transcript at 556, 565. This is understandable in light of the IBM employee's testimony that on this procurement alone, 118 separate features would have had to have been listed in the intervenor's B-Tables. Id. at 565. The OpenEdition feature is adequately identified and described in the intervenor's proposal. See, e.g., Finding 13. It is also included in the B-Tables by referencing the appropriate product number. Id. Therefore, there is no factual support for the protester's claim that the OpenEdition feature is not included in the intervenor's proposal. As to the supporting software programs, the intervenor's programs identified by the protester were considered to be a part of MVS/ESA OpenEdition. Id. Again, the testimony of the intervenor's employee and the IBM employee was not credibly disputed on this point. The protester has provided no evidence or testimony which shows, or even implies, that the identified supporting software packages were not considered by the intervenor to be a part of the MVS/ESA OpenEdition operating system proposed and priced. It is evident that neither party thought it necessary to specifically identify in their B-Tables the software components of their operating systems. The protester's own proposal and B- ----------- FOOTNOTE BEGINS --------- [foot #] 6 Since the testimony of the NIST POSIX Administrator at the hearing, the protester has revised its theory of the case, now claiming that its failure, as well as that of the intervenor, to meet the requirement for a POSIX conformant operating system is a defect which can be cured by date of delivery of the first system. Transcript at 610. There is little left of the protester's complaint if this is a curable defect for both the awardee and protester. ----------- FOOTNOTE ENDS ----------- Tables demonstrate that the protester is trying to hold the intervenor to a much higher specificity standard than the standard adhered to by the protester itself. Findings 14, 15. First and foremost, the protester does not identify in its B-Tables or Component List which version of its EP/IX operating system it proposed. Finding 14. At least it is clear in the B-Tables which version of MVS/ESA was proposed by the intervenor. Finding 13. The protester may claim that by tracking down the operating system product number in the protester's technical literature one can identify the version proposed. While true, it is also true of the intervenor. In fact, the intervenor's product number also indicates that the version of operating system proposed is MVS/ESA OpenEdition. Id. Second, the protester's proposal component list refers to separately identified software packages, which are part of its EP/IX operating system, and which, like the intervenor's supporting software, are not listed in the B-Tables. Finding 15. It is clear that neither party felt it was required to identify specifically each feature and piece of software it was proposing. Both the intervenor and the protester adequately described the functionality of their operating systems in their proposals. Finding 15. The functionality and design features described were sufficiently specific to bind the parties to provide printing systems with thosee functional and design characteristics described. Inasmuch as the protester's proposal suffers the same flaws, real or imagined, that exist in the intervenor's proposal, it cannot successfully use such flaws as a ground of protest. Executone Information Systems, Inc. v. Department of Health and Human Services, GSBCA 12402-P, 94-1 BCA 26,274, at 130,729, 1993 BPD 203, at 15 (protester "cannot complain" of non- compliance which also exists in protester's proposal); The Orkand Corp., GSBCA 11405-P, 92-1 BCA 24,624, at 122,830, 1991 BPD 320, at 9, aff'd, 980 F.2d 742 (Table) (Fed. Cir. 1992). While the rationales of the cases cited above are based on the concept of estoppel, or lack of standing, in the instant case we are also strongly influenced by the fact that the protester's basic complaint is that the respondent did not properly enforce the requirements of the solicitation against the intervenor because the respondent misinterpreted the requirements. Our difficulty with the protester's position goes more to the concept of reasonable interpretation. We conclude that in instances where the respondent's interpretation of the solicitation coincides with that of the intervenor/successful offeror and the protester, the interpretation is, at least prima facia, reasonable. It is reasonable because all the parties to the case so interpreted the requirements. Decision For the reasons set forth above, the protest is DENIED. The suspension of the respondent's delegation of procurement authority lapses by its own terms. _____________________________ JAMES W. HENDLEY Board Judge We concur: ____________________________ ROBERT W. PARKER Board Judge ____________________________ MARTHA H. DeGRAFF Board Judge