AMENDMENT 0003 - Questions and Answers for 026 through 044
(Includes Revised 012 and 017 answers.)
for RFP HC1028-11-R-0104
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11 |
| SECTION TEXT |
| “Equipment will be connected to BAS system for control and monitoring” |
| QUESTION |
| What is the BAS system? |
| ANSWER |
| BAS is Building Automation System. J-2, Requirements Document, para 6.3 and J-5, PWS, para 6.8.2.3 have been revised. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11 |
| SECTION TEXT |
| “IAW DoD Cybercom USB Flash Media Communication Tasking Order (CTO) 10-084, USB Flash Media/Thumb drive devices are prohibited in DoD” |
| QUESTION |
| Please provide a hyperlink or reference to where the CTO can be found. |
| ANSWER |
| Vendors may request a copy of the document by emailing the Contracting Officer and Contract Specialist. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NAME |
| Technical Requirements |
| SECTION TEXT |
| Section 1.2.3.1 of the Technical Requirements document states: "Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards.” |
| QUESTION |
| Fibre Channel HBA cards generally come as dual port cards and have extremely low failure rates as they contain no moving parts. Forcing vendors to bid two separate fibre channel cards for each server will: increase the cost of the configuration, increase power consumption, and heat generation, and not greatly increase availability. We request that this requirement be changed to: "Ports for fiber storage connectivity must be distributed across 2 separate fibre channel links." for all systems. |
| ANSWER |
| Requirement of dual HBA cards is necessary to ensure hardware solution provides availability and maintainability for any hosting requirement faced by CSD. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NO. |
| UX-Itanium Tier Definitions |
| SECTION NAME |
| UX-Itanium Tier Definitions |
SECTION TEXT
| QUESTION |
| Attachment 1 (Page 20) of the Technical Requirements document (UX-Itanium Tier Definitions) states a Tier 2 requirement for "Npar" which refers to hardware level partitioning, a form of virtualization. Vpar and Software virtualization, which is included as a requirement for Tier 2, can provide the same functionality at a much lower hardware cost. We request that this requirement be removed for the UX-Itanium Tier 2 systems. |
| ANSWER |
| Requirement for “Npar” in Tier 2 stands as long as the technology is available and supported by the OEM. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NO. |
| UX-Itanium Tier Definitions |
| SECTION NAME |
| UX-Itanium Tier Definitions |
| SECTION TEXT |
| Table requirements |
| QUESTION |
| Attachment 1 (Page 20) of the Technical Requirements document (UX-Itanium Tier Definitions) states a requirement for "Hot pluggable CPU/memory" for all three tiers. Hot pluggable CPU/memory is not a standard feature of entry and mid-tier business critical servers to help reduce the cost of these systems, but is a feature found on high-end servers. We request that this requirement be removed for the HP-Itanium Tier 1 and Tier 2 systems. |
| ANSWER |
| Requirement of “Hot pluggable CPU/Memory” is necessary to ensure hardware solution provides availability and maintainability for any hosting requirement faced by CSD. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NO. |
| UX-Itanium Tier Definitions |
| SECTION NAME |
| UX-Itanium Tier Definitions |
| SECTION TEXT |
| Table requirements |
| QUESTION |
| Attachment 1 (Page 20) of the Technical Requirements document (UX-Itanium) states a requirement for "Dynamic Reconfiguration", a form of hardware virtualization, for all three (3) system tiers. Dynamic Reconfiguration is not a standard feature of entry and mid-tier business critical servers to help reduce the cost of these systems, but is a feature found on the high-end servers. We request that this requirement be removed for the HP-Itanium Tier 1 and Tier 2 systems. |
| ANSWER |
| Requirement of “Dynamic Reconfiguration” is necessary to ensure hardware solution provides availability and maintainability for any hosting requirement faced by CSD. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NO. |
| X86 W/L/L Tier Definitions |
| SECTION NAME |
| X86 W/L/L Tier Definitions |
| SECTION TEXT |
| Table requirements |
| QUESTION |
| Attachment 1 (Page 22) of the Technical Requirements document (X-86 W/L/L Tier Definitions) states a requirement for "Hot pluggable CPU/memory" for all five (5) system tiers. Hot pluggable CPU/memory is not a standard feature of industry standard x86 architecture, but is a feature generally found on more expensive business critical servers. We request that this requirement be removed for all five x-86 system tiers. |
| ANSWER |
| Requirement of “Hot pluggable CPU/Memory” is necessary to ensure hardware solution provides availability and maintainability for any hosting requirement faced by CSD. |
| DOCUMENT |
| J-2 Requirements |
| SECTION NO. |
| X86 W/L/L Tier Definitions |
| SECTION NAME |
| X86 W/L/L Tier Definitions |
| SECTION TEXT |
| Table requirements |
| QUESTION |
| Attachment 1 (Page 22) of the Technical Requirements document (X-86 W/L/L Tier Definitions) states a requirement for "Dynamic Reconfiguration", a form of hardware virtualization, for all five (5) system tiers. Dynamic Reconfiguration is not a standard feature of industry standard x86 architecture. It is a feature generally found on more expensive business critical servers. We request that this requirement be removed for all five x-86 system tiers. |
| ANSWER |
| Requirement of “Dynamic Reconfiguration” is necessary to ensure hardware solution provides availability and maintainability for any hosting requirement faced by CSD. |
| DOCUMENT |
| Attachment J-5 PWS |
| SECTION NAME |
| Performance Req |
| SECTION TEXT |
| X-86 (Windows Server, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Solaris, VMware) |
| QUESTION |
| The OS Requirements denotes ‘N’ as being the most current major release, N-1 being the most recent prior release, and N-2 as being two major releases back. Please provide clarification of N, N-1, and N-2. There are multiple variants of maintenance releases (e.g., RHEL 5.0 through 5.6), editions (e.g., Windows Server 2008 R2 includes Windows Server 2008 R2 Enterprise, Windows Server 2008 Datacenter, Windows Server 2003 32-bit and 64-bit, etc.) that can possibly fall within the parameters of N, N-1, and N-2 OS major release definitions. Is the vendor to be responsible for providing all possible minor releases and editions that are within the N, N-1, and N-2 parameters? In addition, there may be instances wherein N-1 and N-2 may not be available or applicable for the proposed chipsets due to end-of-life or hardware architecture support restrictions. It is proposed that an exception be added to this requirement that N-1 and N-2 are only applicable when older major and/or minor releases are supported by the proposed chipsets and are still under mainstream support. |
| ANSWER |
| ‘N’ designations include support for minor releases and editions within the specified ‘N’, ‘N-1’ and ‘N-2’ major releases. |
| SECTION NAME |
| 15th of the Month Rule |
| SECTION TEXT |
| “Acceptance” or “Deactivation” that occurs prior to 15th of the month will be billed for the month “Acceptance” or “Deactivation” occurs. “Acceptance” or “Deactivation” that occurs after to 15th of the month will be billed for the following month. |
| QUESTION |
| 15th of the Month Rule should state: Acceptance that occurs prior to the 15th of the month will be billed for the entire month in which acceptance has occurred. Acceptance that occurs after the 15th of the month, billing will beginning with the following month. For deactivations that occur prior to the 15th of the month, no billing will occur for the entire month in which the deactivation occurs. For deactivation's that occur after the 15th of the month, billing will be for the entire month. |
| ANSWER |
| J-2, Requirements Document, para 13.8.1.1 and J-5, PWS, para 9.4.1.1 is revised accordingly. |
| SECTION NO. |
| UX-Itanium Tier Definition |
| SECTION NAME |
| UX-Itanium Tier Definition |
| SECTION TEXT |
| Table requirements |
| QUESTION |
| UX-Itanium Tier Definition - This table denotes three (3) tiers. However, the J-8 Itanium Chipset Pricing Model 2 Jun 2011.xls document denotes 4 tiers. Please clarify desired number of HP-UX Itanium Tiers. |
| ANSWER |
| J-8, Itanium Chipset Pricing Model has been revised. J-9, SPARC Chipset Pricing Model has been revised. J-10, IBM System P Chipset Pricing Model has been revised. J-2, Requirements Document, Attachment One, Server Chipset Tiers Sparc, P-Series, and UX Itanium has been revised. J-5, PWS, para 6.3.3 has been revised with new Attachment One. |
PAGE
SECTION TEXT
| QUESTION |
| DD254 states the security requirement for this contract is Secret however there are several references throughout the document that mention SCI which is TS/SCI. Request change in DD254 to reflect TS/SCI. |
| ANSWER |
| Offerors will not have access to TS/SCI data, therefore TS/SCI is not required for access to hardware. If TS/SCI is required during performance, the DD254 will be revised to reflect the TS/SCI requirement. |
| SECTION NO. |
| Attachment 5, Page 1 of 5 |
| SECTION NAME |
| Attachment 5, Page 1 of 5 |
SECTION TEXT
| QUESTION |
| DISA called out a rack requirement which does not align with the current deployment strategies of DISA CSD. If this strategy is implemented, it will force industry to a single source to provide the rack required in RFP attachment J2, attachment 5, “Rack Maximum Depth of 114.3cm”. In order to insure competitive sourcing on racks we request the government to change the Rack Maximum Depth to 122cm. |
| ANSWER |
| DISA is seeking to establish rack size standards. Vendors may submit deviations to the standard rack configurations IAW Attachment 5 which must be validated and approved by DISA during evaluations. |
| SECTION NO. |
| Attachment 5, Page 1 of 5 |
| SECTION NAME |
| Attachment 5, Page 1 of 5 |
SECTION TEXT
| QUESTION |
| DISA called out a rack requirement which does not align with the current deployment strategies of DISA CSD. If this strategy is implemented, it will force industry to a single source to provide the rack required in RFP attachment J2, attachment 5, “Rack Maximum Height of 199.1cm”. Most vendors provide a standard 2 Meter Rack which are 1 to 2cm taller. DISA currently is using some racks with heights of 200.4 cm. Request Rack Maximum Height be changed to 201cm. |
| ANSWER |
| DISA is seeking to establish rack size standards. Vendors may submit deviations to the standard rack configurations IAW Attachment 5 which must be validated and approved by DISA during evaluations. |
| SECTION NAME |
| OS Requirements |
| SECTION TEXT |
| For Operating systems listed under each chipset, the offeror will provide the most current operating system; additionally provide and support for two versions back. The Government defines the most current version as N and the two proceeding versions as minus two (-2). Therefore N-2 is used to describe an OS current version and two major releases back (supportable by the OEM). An example being RHEL (Red Hat) 6, RHEL 5, and RHEL 4. |
| QUESTION |
| Please clarify the phrase “Therefore N-2 is used to describe an OS current version and two major releases back (supportable by the OEM)”. Is this meant to imply that the vendor only supply OS versions that are currently supportable by the OEM? |
| DOCUMENT |
| RFP, HC1028-11-R-0104 |
| SECTION NAME |
| Section M, B. Factor 1 |
SECTION TEXT
| QUESTION |
| It is our understanding the DISA will be conducting price reasonableness on the offers proposal. Section M.B.Factor 1 Technical/management does not evaluate the offerors program management office that is required to support: The government refers to risk in several places (transition, implementation, SLA…) as well as assigns a risk rating to each section of the evaluation. The government does not evaluate the offerors management plan that is required to support: OS requirements; OEM technical support; image; additional hardware components; virtual environments; software; operating system console management; 99.95% availability; 24x7/365 problem escalation/resolution; validate and view HW features and components; provide central management capability and reporting; maintenance; delivery and installation; processing capacity that is scalable; provisioning to support the infrastructure; provide processor capacity that does not adversely impact existing production; provide processing capacity that is moveable; capacity requirements can be cancelled; training; infrastructure that interoperates with DISA’s ESM; managed remotely; dedicated backup; operate seamlessly with DISA’s processor and storage infrastructure; package OS, manage the OS repository, mainframe and server; installation/configuration, ensure personnel are trained and certified; compliance with DISA STIGs; standard rack and power specifications; high density cooling configurations; quarterly reports for environmental telemetry data; analysis for power/heat load mitigation; technology refresh program; removal of equipment; quality program; reporting requirements; meeting requirements; technical assistance and consulting services; and ordering/payment process. |
Does the government want to see an offerors proposed management structure with key personnel identified or is industry to assume that this is not a part of the service that DISA is requesting?
| ANSWER |
| J-5, PWS para 5.4 identifies that offerors should discuss proposed program management structure. |
| DOCUMENT |
| RFP, HC1028-11-R-0104 |
| SECTION NAME |
| Technical/Management Risk Rating |
| SECTION TEXT |
| The Technical/Management Risk evaluation focuses on the weaknesses and significant weaknesses associated with an Offeror's proposed approach and includes an assessment of the potential for disruption of schedule, increased cost, or degradation of performance, the need for increased Government oversight, and the likelihood of unsuccessful contract performance. |
Each Technical/Management Subfactor will receive one of the risk ratings described in the DISA Source Selection Procedures, paragraph 4.5.1.2, Table 2 – Technical/Management Risk Ratings, excerpted below. The ratings focus on the risks, i.e., weaknesses and significant weaknesses of the Offeror’s proposed approach to each of the technical/management subfactors. For any weakness identified, the evaluation will address the Offeror's proposed mitigation and why that mitigation approach is or is not considered manageable.
| QUESTION |
| The government refers to risk in several places (transition, implementation, SLA…) as well as assigns a risk rating to each section of the evaluation. The government does not evaluate the offerors management plan that is required to support: OS requirements; OEM technical support; image; additional hardware components; virtual environments; software; operating system console management; 99.95% availability; 24x7/365 problem escalation/resolution; validate and view HW features and components; provide central management capability and reporting; maintenance; delivery and installation; processing capacity that is scalable; provisioning to support the infrastructure; provide processor capacity that does not adversely impact existing production; provide processing capacity that is moveable; capacity requirements can be cancelled; training; infrastructure that interoperates with DISA’s ESM; managed remotely; dedicated backup; operate seamlessly with DISA’s processor and storage infrastructure; package OS, manage the OS repository, mainframe and server; installation/configuration, ensure personnel are trained and certified; compliance with DISA STIGs; standard rack and power specifications; high density cooling configurations; quarterly reports for environmental telemetry data; analysis for power/heat load mitigation; technology refresh program; removal of equipment; quality program; reporting requirements; meeting requirements; technical assistance and consulting services; and ordering/payment process. |
Does the government want to see an offerors proposed management structure with key personnel identified or is industry to assume that this is not a part of the service that DISA is requesting and a lack of management approach proposes no performance, schedule, or cost risk to DISA?
| ANSWER |
| J-5, PWS para 5.4 identifies offerors should discuss proposed program management structure. IAW RFP HC1028-11-R-0104, para 4.2.2.1, requires the offeror to “address technical/management risk by identifying those aspects of the proposal you consider to have the potential for disruption of schedule, increased cost, poor performance, the need for increased Government oversight, and/or the likelihood of unsuccessful contract performance.” |
| DOCUMENT |
| RFP, HC1028-11-R-0104 |
| SECTION NO. |
| Section L, 5.1 |
| SECTION TEXT |
| Experience as a prime or teaming partner may carry more weight than experience as a subcontractor. |
| QUESTION |
| The government is suggesting that given the critical nature of this contract and to ensure a prime contractor will not put the DISA CSD mission at Risk, specifically due to the DoD data consolidation. With the subjectivity given to the evaluation of past performance, IAW section M of the RFP, this greatly increased DISA’s RISK with regards to performance, schedule and cost risk. To mitigate that risk, we recommend DISA change the language to: |
“Experience as a prime will carry more weight than experience as a subcontractor or teaming partner”.
| ANSWER |
| The verbiage will remain as written. After further review, it was decided to delete the last sentence in the first subparagraph of paragraph 5.1 in Section L of the RFP. |
| SECTION TEXT |
| Travel will be priced on a cost basis, in accordance with Joint Travel Regulations (JTR). Travel may be required on limited basis as requested by DISA. Travel will be permitted with authorization from the Contracting Officer Representative (COR) by issuance of call order authorizing estimated travel expenses for work to be performed. Reimbursement will be IAW JTR only after receipt of expense details. Charges for travel are permissible only in connection with a call order placed for technical support services as called for in the PWS. All other travel costs will be included in the utility chipset cost. |
| QUESTION |
| Will the government reimburse the contractor for travel to program meetings, contract kickoff meetings, semi annual review meetings, installation, repair, moves, maintenance, under the Travel CLINs contained in the RFP pricing model attachments? |
| ANSWER |
| Para 14.0 of J-2, Requirements Document and J-5, PWS para 6.15 states “Program meetings will be required and held at various geographical locations. The Contractor shall include all costs associated with meeting attendance in the proposed prices.” |
| DOCUMENT |
| RFP, HC1028-11-R-0104 |
PAGE
SECTION NO.
SECTION NAME
SECTION TEXT
| QUESTION |
| It appears that DISA is merely seeking commercial services, therefore, non-commercial item clauses should not be included in the RFP. Will DISA remove all non-commercial item clauses from the RFP? |
| ANSWER |
| No. There are many clauses required by other parts of the FAR beyond FAR Part 12, such as FAR Part 17 for option clauses. |
| SECTION NAME |
| Government-Furnished Equipment (GFE)/Government-Furnished Information (GFI). |
| SECTION TEXT |
| “GFP determined necessary for performance under the Enterprise Storage Services contract will be provided.” |
| QUESTION |
| Will DISA provide GFE/GFP, to include workspace, cubicle, desktop and or laptop, LAN connectivity, etc. for vendor staff located at DISA data centers in Mechanicsburg, Ogden, Oklahoma City, Montgomery, St Louis, San Antonio, Columbus, Denver, Ft. Meade, MD, and other locations as needed for vendor delivery team staff? |
| ANSWER |
| J-2 Requirements Document has been revised to add para 19.0. J-5, PWS para 14.0 has been revised. Cubicle space will be provided to the vendor for capacity management and provisioning. Location will be determined after contract award. |
Defense Information Systems Agency