The file's text, extracted by GovTribe without its formatting.
Amendment 0004 - Questions and Answers for 075 through 156
RFP HC1028-11-R-0104
| DOCUMENT |
| J-1 SOO, revised 11 May 11.doc |
| SECTION TEXT |
| Proof-of-concept demonstration of the offeror’s proposed solution will be required for all offerors in the competitive range. The proof-of-concept is to determine whether the solution meets DISA’s processing objectives. The offeror(s) will provide all resources required for the proof-of-concept demonstration. |
| QUESTION |
| Would DISA consider supplying the guidelines at least 30 days before POC demonstration? Can a draft version be made available prior to the final release? |
What is the projected target date for the Proof-of-Concept demonstration?
| ANSWER |
| POC demonstration will not occur until evaluations are complete and the competitive range has been determined. DISA will release the POC guidelines once the competitive range has been determined. DISA will release the POC guidelines as soon as possible, but not later than 14 days in advance. |
The projected target date for Proof-of-Concept is December 2011;January/February 2012.
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Operating Chipset Architecture/Operating environments |
| SECTION TEXT |
| The scope of this project includes the hardware/Chipset and the operating systems software, required to deliver processor capability for DISA |
| QUESTION |
| Can ‘appliance’ devices (custom server and bundled software) be considered under the Chip Architecture/Operating environment. If so how should they be submitted? |
| ANSWER |
| The vendor may propose appliances if it is an OEM product of the vendor and meets all technical specifications outlined, and the solution adheres to the defined Tier structure outlined in the SOW. The “appliance” must be capable of being administered and maintained by DISA staff members. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| SPARC (Solaris, Solaris 10 zones and Ldoms) |
| QUESTION |
| Can we submit M-Series Servers as part of the proposal even though they do not support LDOMS? |
| ANSWER |
| The vendor can propose hardware solutions that meet the technical requirements. Approaches utilizing virtualization are preferable, but DISA also has requirements for physical servers. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Future locations |
| SECTION TEXT |
| Offeror shall have the ability to support DISA or DISA approved locations worldwide where DISA CSD may acquire an operational responsibility. |
| QUESTION |
| Can response time and specific requirements be negotiated to provide support in future OCONUS locations? Can delivery time frame exceed 30 days for these locations? |
| ANSWER |
| No. Delivery is required within 30 days for CONUS and OCONUS orders. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| 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 |
| Can you please clarify the N-2 support principal for Windows Server? Is support for Windows Server 2008 R2, 2008 and 2003 R2 a reasonable interpretation of the N-2 support strategy? |
New equipment does not always support older software releases. As long as N-2 support is available for future OS releases, is that acceptable (e.g. T3-1 cannot natively run Solaris 8 or 9, but can run Solaris 10 and 11. The platform will be supported by continued Solaris updates throughout its lifecycle)?
| ANSWER |
| The “N” strategy as defined by the Government includes the major release and all associated variants as “N”. For example, the current Windows “N” for the Government is Windows 2008. The Government will collaborate with the vendor on n-2 environments to ensure that they are viable and supportable solutions. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| 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 |
| Does Red Hat Enterprise Linux mean releases specifically from Red Hat or can compatible distributions be used? |
| ANSWER |
| The requirement is specified in J-2, Requirements Document, para 1.2.1. Offered solution cannot be open source distribution. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| 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 |
| Can any Red Hat compatible Open Source distribution be used (e.g. CentOS, Fedora)? |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| 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 |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide high availability options for OS (clustering) at the local site and/or remote site for tying hardware together. |
| QUESTION |
| Request for high availability states ‘at the local site and/or remote site’ local clustering is a well-understood technology. Remote clustering is somewhat vague and open to interpretation – can you please clarify? For example does high availability mean data replication, operating system failover, and/or application failover? |
| ANSWER |
| The vendor’s proposed high availability solution should be flexible to support the possibility for data replication, operating system failover, and/or application failover. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide high availability options for OS (clustering) at the local site and/or remote site for tying hardware together. |
| QUESTION |
| Can you specify the SLA’s that you expect (e.g. Recovery Time Objective? Recovery Point Objective etc.). Does this mean transaction replication? |
| ANSWER |
| This does not mean transaction replication; this means clustering of servers to support high availability for selected provisioning requirements. RTO and RPO are dependent on individual customer application requirements. Offered solution should provide multiple high availability options. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Virtual Environments |
| SECTION TEXT |
| Provide solution that recognizes Virtual VMware environment as standard infrastructure for the x86 environment. The Government support staff will manage the ESX environment (hosts), placements, relocating environments (vmotion), and the VIC. The Virtual Environment software for all platforms will be included in the processor utility service. Offeror will provide the underlying infrastructure, tools, software, licensing, and licensing agreements to support the VMware Virtual infrastructure as well as native virtual capabilities for HP-UX and Solaris. |
| QUESTION |
| The RFP specifically asks for VMware support. If an alternative Virtual Environment with equivalent functionality and documented lower cost of ownership can be offered as a replacement, would this be acceptable to DISA? If acceptable, would any additional conditions apply (e.g. Training of DISA staff – if so can you supply the number of staff requiring training)? |
| ANSWER |
| The standard specified is VMware. Alternative solutions cannot be proposed. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Virtual Environments |
| SECTION TEXT |
| Provide solution that recognizes Virtual VMware environment as standard infrastructure for the x86 environment. The Government support staff will manage the ESX environment (hosts), placements, relocating environments (vmotion), and the VIC. The Virtual Environment software for all platforms will be included in the processor utility service. Offeror will provide the underlying infrastructure, tools, software, licensing, and licensing agreements to support the VMware Virtual infrastructure as well as native virtual capabilities for HP-UX and Solaris. |
| QUESTION |
| Would DISA consider service that provided virtual infrastructure provisioning and management services (i.e. Infrastructure as a Service)? |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Requirement for 4 network ports supporting Ethernet traffic is listed but no specific requirements’ are defined. Can you please clarify (e.g. 100 MbE, 1 GbE, 10 GbE)? |
| ANSWER |
| See Question 57, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Requirement specifies ‘four communications network ports must be distributed across 4 separate physical communication switches’. Please clarify what this is intended to mean from a system configuration perspective (does this imply 4 physical ports that are connected to separate external communication switches or something more specific in terms of system network configuration)? |
| ANSWER |
| The networks described in the section text (Production, OOB, EBN) are all physically separated switched networks that do not share infrastructure. The specific requirements for each network is separated from one another to reduce the security risk of each network. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Is additional system level network redundancy required/desired? Should this be part of the high availability option and an option available for all configurations? |
| ANSWER |
| Using the design described in the section text allows for redundant production network connections down to the physical interfaces of the system. The EBN and OOB only require 1 separated switch but can support more than one uplink from a system if required. Because EBN and OOB are not mission critical, normal configuration does not use a high availability layout at the system level. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| If 10GbE is desired but not required, should 10GbE switches be included in the rack configurations for rack local high-speed intercommunication? |
| ANSWER |
| See Question 57, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Are other high-speed network connections (e.g. Infiniband) viable options and/or future replacements/upgrades? |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Requirements are noted for 2 physical Host Bus Adapters. Can you please clarify minimum specific configuration (e.g. 4Gb or 8Gb? Dual or Single Port HBA’s?) |
| ANSWER |
| See Question 57, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| All operating environments whether physical (rack mount or blade) or virtual must be able to provide connectivity for a minimum of 4 network ports supporting Ethernet traffic, and two separate ports for fiber storage connectivity. Two network ports are utilized for production traffic, one network port is utilized for out of band (OOB) network connections, and one port is required for enterprise backup network (EBN) connectivity. Due to this requirement the four communications network ports must be distributed across 4 separate physical communication switches. Ports for fiber storage connectivity must be distributed across 2 separate physical Host Bus Adapter (HBA) cards. All communications switch equipment must be able to support the use of VLANs, as well as any other standard technologies and protocols. The proposed solution should also integrate into existing processing infrastructure with minimal disruption or reconfiguration of network infrastructure. |
| QUESTION |
| Requirement states ‘solution should integrate into existing processing infrastructure with minimal disruption’. Can you provide specific documentation on current infrastructure, a road map of anticipated changes and timing over the period of this contract for both the network (e.g. 1GbE today, moving to 10GbE in 2 years, Infiniband in 5 years) and SAN environment (e.g. 4 Gb today, moving to 8Gb in 4 years, Is FCoE being considered?) |
| ANSWER |
| See Question 57, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Maintenance Response and Repair Time |
| SECTION TEXT |
| Provide processing capacity that delivers a minimum of 99.95% availability per orderable system with options to provide up to 99.999 % availability per orderable system. Provide 24x7/365 problem escalation/resolution support for hardware, operating system software, and capacity management. The offeror will provide a multi-level solution for response after being notified by the Government, to commence remedial maintenance for hardware, operating system software, VMWare, as well as, any other software required for the contractor solution to operate. Each orderable system will be identified to a level of response based on Government need. All maintenance requirements are included in the “utility” pricing. |
| QUESTION |
| Can you please provide additional clarification on expectations of 99.95% availability measurement? Is this a measure of hardware availability (powered on and Service Processor accessible)? OS availability (does single user/maintenance mode count as availability or only multi-user mode)? Is network accessibility and/or user access the measure of availability? Application availability? What methods will be used to determine system failure versus other environmental failures (e.g. Network switch? SAN switch/storage device etc.) |
| ANSWER |
| The measurement of 99.95% availability relates to everything delivered by the vendor under this solicitation. |
The calculation identified in J-5, PWS para 6.2.1, includes “Measurement Exceptions”. Measurement Exceptions include environmental failures not attributed to the offeror. The definition for measurement exception is revised in J-5, Requirements Document, para 6.2.1 and J-3, QASP, para 5, Subtask 2.1.
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Maintenance Response and Repair Time |
| SECTION TEXT |
| Provide processing capacity that delivers a minimum of 99.95% availability per orderable system with options to provide up to 99.999 % availability per orderable system. Provide 24x7/365 problem escalation/resolution support for hardware, operating system software, and capacity management. The offeror will provide a multi-level solution for response after being notified by the Government, to commence remedial maintenance for hardware, operating system software, VMWare, as well as, any other software required for the contractor solution to operate. Each orderable system will be identified to a level of response based on Government need. All maintenance requirements are included in the “utility” pricing. |
| QUESTION |
| This section states “Options to provide availability of 99.999%”, however, Attachment J-3 QASP for Processor and Attachment J-5 Processor PWS Template both state under Task 2 – 6.2.1 Subtask 2.1 that “Processor capacity for High Availability Systems will meet or exceed 99.99%”. Given the incremental costs for additional high availability can you explain the discrepancy? |
| ANSWER |
| The High Availability option will meet or exceed 99.999%. J-2, Requirements Document, paras 1.3.1 and 2.0 revised accordingly. J-5, PWS, paras 6.2.1, 6.2.1.1, and 6.2.2.1 are revised accordingly. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Predictive Maintenance |
| SECTION TEXT |
| Contractor shall monitor equipment/component performance using diagnostics defined in paragraph 3.2.3 for the purpose of identifying whether equipment is operating in accordance with established specifications. This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall, upon determining equipment/component is about to fail or is operating outside OEM specifications, initiate action to effect repair even though no call for remedial maintenance has been initiated by the site help desk or shift supervisor. |
Contractor shall call the help desk or shift supervisor to inform them they are coming in for predictive maintenance and upon arrival on site. Contractor’s technician shall report to the site help desk or shift supervisor in order to comply with reporting requirements.
| QUESTION |
| There is no paragraph 3.2.3 in the J-2 Requirements document. Please clarify the diagnostics required? |
| ANSWER |
| See Question 25, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Predictive Maintenance |
| SECTION TEXT |
| Contractor shall monitor equipment/component performance using diagnostics defined in paragraph 3.2.3 for the purpose of identifying whether equipment is operating in accordance with established specifications. This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall, upon determining equipment/component is about to fail or is operating outside OEM specifications, initiate action to effect repair even though no call for remedial maintenance has been initiated by the site help desk or shift supervisor. |
Contractor shall call the help desk or shift supervisor to inform them they are coming in for predictive maintenance and upon arrival on site. Contractor’s technician shall report to the site help desk or shift supervisor in order to comply with reporting requirements.
| QUESTION |
| Will the government allow automated, electronic transmission (aka “phone home”) from the system to a vendor site outside of the DISA network? Will this ability extend to SIPRnet? |
| ANSWER |
| “Phone home” capability can be supported on NIPR, pending review and accreditation of vendor’s proposed solution. This capability is not available on SIPR. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remedial Maintenance |
| SECTION TEXT |
| Calls will be initiated by the site help desk or shift supervisor to the contractor’s toll free help desk service. Contractor shall respond and repair, or when necessary, obtain required OEM support, in accordance with this specification. The contractor shall complete remedial maintenance within the response and repair times per paragraph 3.2.1. Upon arrival on site, contractor’s technician shall report to the site help desk or shift supervisor in order to comply with reporting requirements. This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. |
| QUESTION |
| Question includes a reference to paragraph 3.2.1, which does not exist. Please clarify the requirements for response time? |
| ANSWER |
| See Question 25, Amendment 0003. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Will DISA allow two way electronic reporting and diagnostics from inside the DISA network to a vendor system outside the DISA network? Will this allowance extend to SIPRnet? |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Please clarify ‘permanent recorded system errors’? Does this mean critical hardware errors? All syslog error messages? All syslog messages? |
| ANSWER |
| Permanent recorded system errors would be defined as failed or failing hardware issues. Also, critical hardware errors and selected syslog errors that would relate to failing or failed hardware, no to all syslog messages. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Please clarify ‘reported to remote service center(s)’ in the case of SIPRnet or SCIF implementations? What are the available transport methods in these cases? |
| ANSWER |
| Not applicable to SIPR or SCIF environments |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Please clarify any access/security restrictions ‘diagnostic system usable by remote technician’, particularly in light of SIPRnet/SCIF implementations? |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Please clarify ‘dial-in feature’. Is this a requirement per physical system? Will each system be provided with a telephone connection? Will access to existing services be provided? Can access be provided through a ‘gateway’ system (e.g. OS provisioning system) and then access to remote diagnostics through the local network? |
| ANSWER |
| This section should be better framed around phone-home capabilities. Agents/SNMP traps /etc. are expected to be reported to a vendor provided management stack which would them transmit them to vendor Response Center for immediate action to fix and/or replace failing/failed parts. All diagnostics would be outbound to Response Centers via TCP/IP protocols. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Can other controlled access methods (e.g. ssh) be used for access to remote diagnostics versus dial-up? Can you clarify any security or other management constraints on network access to remote diagnostics? |
| ANSWER |
| VPN to management network may be used to access remote diagnostics. Security & management constraints would be include normal processes to obtain system access for remote IP to DISA assets. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Remote Diagnostics |
| SECTION TEXT |
| Permanent recorded system errors must be immediately reported to remote service center(s). This includes hardware, operating system software, VMWare, as well as, any other software required for the offeror solution to operate. The contractor shall provide written confirmation that reports and remote diagnostics support for applicable equipment exist within 7 calendar days after contract performance start. |
Verbal contact between the local maintenance technician and an off-site support technician is not acceptable for remote diagnostics. There shall be a diagnostic system usable by the remote technician.
The dial-in feature can be used, but ONLY with site authorization. The feature must be capable of disabling and set up to provide the site the ability to enable the feature upon request from the contractor.
| QUESTION |
| Can remote Virtual Display Interface (VDI) technologies be used as an alternative access? Can you clarify any security or other management constraints of a VDI approach? |
| ANSWER |
| Yes VDIs can and are being used. VPN access is a constraint. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Change Management |
| SECTION TEXT |
| An established process for handling change to the processor infrastructure on a continual basis shall be developed. Over an eight year period (5 year base with 3 option years) technologies will change, software will be revised, and hardware will be phased out by the manufacture. By having a process in place to handle these inevitable events, time and money can be saved. It will also be necessary to incorporate DISA customer requests for new or revised functionality. Changes in focus and/or mission of some or all the DISA business processes will play a role in the type of changes that may need to be incorporated into Tech Refresh Program over an eight year span. This will specifically address end of life and unsupportable issues which may occur during the life of this contract. |
| QUESTION |
| Please clarify “specifically address end of life unsupportable issues which may occur during the life of the contract”. Does this refer to a desire for extended hardware support from non-vendor sources (e.g. Grey market legacy support)? |
| ANSWER |
| The vendor may provide end of life hardware declared unsupportable by the manufacturer only if requested by DISA and supportable by the vendor. The Government views this requirement to be used on a very infrequent basis. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Change Management |
| SECTION TEXT |
| An established process for handling change to the processor infrastructure on a continual basis shall be developed. Over an eight year period (5 year base with 3 option years) technologies will change, software will be revised, and hardware will be phased out by the manufacture. By having a process in place to handle these inevitable events, time and money can be saved. It will also be necessary to incorporate DISA customer requests for new or revised functionality. Changes in focus and/or mission of some or all the DISA business processes will play a role in the type of changes that may need to be incorporated into Tech Refresh Program over an eight year span. This will specifically address end of life and unsupportable issues which may occur during the life of this contract. |
| QUESTION |
| Is legacy software support required, and if so is third party support leveraging open source versions acceptable (e.g. Open Solaris support for extended period of contract for equivalent of Solaris 10 support if vendor support is not available for the specified period)? |
| ANSWER |
| No, legacy software support is not required for Open Solaris support. The Government does not use open source. See question 80. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Change Management |
| SECTION TEXT |
| An established process for handling change to the processor infrastructure on a continual basis shall be developed. Over an eight year period (5 year base with 3 option years) technologies will change, software will be revised, and hardware will be phased out by the manufacture. By having a process in place to handle these inevitable events, time and money can be saved. It will also be necessary to incorporate DISA customer requests for new or revised functionality. Changes in focus and/or mission of some or all the DISA business processes will play a role in the type of changes that may need to be incorporated into Tech Refresh Program over an eight year span. This will specifically address end of life and unsupportable issues which may occur during the life of this contract. |
| QUESTION |
| Are optional software migration services viable as a mechanism to move applications to a supported version of the operating environment? If so, how should they be presented within the Bid framework? |
| ANSWER |
| No, optional software migration services are not required. The Government is responsible for application migration. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Configuration Management |
| SECTION TEXT |
| An established process for managing the infrastructure’s processor configuration shall be developed by the offeror. One method to reduce the cost of Configuration Management is to reduce the types of hardware in the environment. By maintaining the configurations over the eight year period, DISA will be able to improve break-fix and trouble tickets because less time will be spent on issue resolution. Further, this reduces the over-all complexity of the infrastructure from a management standpoint. The contractor will provide monthly configuration/asset summary reports for configuration/asset validation by the Government. |
| QUESTION |
| Please clarify the level of detail required for ‘monthly configuration/asset summary reports’. Is this for physical system characteristics (e.g. model, memory, network)? OS version (e.g. OS release x.y)? OS details (e.g. update releases installed, patches installed)? |
| ANSWER |
| Yes, the level of detail for monthly configuration/asset summary reports is for physical system configuration, OS version, and OS details. The vendor technical solution should address their solution for the monthly |
configuration/asset summary report.
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
| SECTION NAME |
| Release Management |
| SECTION TEXT |
| An established process for performing package releases to the infrastructure shall be developed. Release Management works to ensure you have strong Configuration Management and Change Management, and works alongside Asset Management to ensure that any assets are introduced into the infrastructure correctly and with the minimum of difficulty. |
| QUESTION |
| Please clarify if it is acceptable to offer Release Management tools not on the Enterprise Management Products for Servers (Attachment Three of the Requirements document)? Please clarify if any additional justification or requirements provisions should be addressed in this event. |
| ANSWER |
| Yes, the vendor may offer other Release Management tools (in their technical solution) which are not included on Attachment Three. The vendor must be able to address accreditation and certification requirements IAW the STIGs. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide ability to validate and view HW features and components installed. |
| QUESTION |
| What is the required latency for asset configuration/validation? Real-time? Is the validation required to be run on the client system or can it be run on the reporting system? Can the reporting be based on periodically collected data? |
What is the minimum latency for reporting data (1 minute, 1 hour, 1 day, 1 week)? Is there a requirement for a summary of asset changes over a specified time period?
| ANSWER |
| Real-time is not required. The minimum requirement for reporting is on a monthly basis. Yes, there is a requirement for a complete list of vendor assets to include a summary of asset changes . The vendor's technical |
solution should provide the best approach for this requirement to include where the validation will run, collection of data, and period of collection, to ensure a sound reporting methodology is provided.
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide central management capability and reporting to include hardware utilization, error diagnostics of installed hardware components, and environmental telemetry information to measure power consumption and HVAC impact to CSD facilities and infrastructure. |
| QUESTION |
| Please clarify ‘environmental telemetry’ in terms of attributes and measurement points (e.g. CPU temperature versus measurement of heat in specified areas of the rack). Are there other attributes in addition to temperature that are required (e.g. humidity? Airflow? Etc.) |
| ANSWER |
| The solution should provide meaningful data to enable measurement of environmental impact to a data processing facility. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide central management capability and reporting to include hardware utilization, error diagnostics of installed hardware components, and environmental telemetry information to measure power consumption and HVAC impact to CSD facilities and infrastructure. |
| QUESTION |
| Please clarify ‘power consumption’ in terms of measurement points (e.g. CPU? PCI cards? From system power supplies? From rack PDU?). Is a point in time measurement required or a total consumption measurement required? |
| ANSWER |
| The solution should provide meaningful data to enable measurement of power consumption in a periodic, repeatable method. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide central management capability and reporting to include hardware utilization, error diagnostics of installed hardware components, and environmental telemetry information to measure power consumption and HVAC impact to CSD facilities and infrastructure. |
| QUESTION |
| Please clarify ‘HVAC impact’, as this will be impacted by airflow, cool approaches etc. Does this imply rack level temperature/airflow monitoring? Does this imply Data Center airflow and HVAC monitoring (if so please provide Data Center specifications such as room size, current HVAC implementation etc.)? |
| ANSWER |
| The solution should provide meaningful data to enable measurement of environmental impact created by their provisioned equipment. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide provisioning servers to support the infrastructure. These servers must be provided by the offeror in order to image hardware with the current agreed upon images. Provisioning cannot be accomplished via the wide area network (WAN). |
| QUESTION |
| Can physical media updates be used in the degenerative case of sites with 5 or less servers instead of a provisioning server? |
| ANSWER |
| No, the requirement is as stated in J-2, Requirements Document, para 3.1. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide processing capacity that is priced on a utility (as used) basis and tier size. |
| QUESTION |
| What is meant by “as used”? Utility pricing implies a metered service. This contradicts Section 13.8.1 which states ‘creates invoices directly from the order data and does not require the collection, manipulation or review of utilization data’. Section 13.8.1 implies an allocation service (e.g. a room rental) not a utility service (e.g. Power, Gas). |
Please clarify which is type of service is desired.
| ANSWER |
| The Government requirement is to be billed on a monthly basis for installed capacity based upon the tier level identified on the call order. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide processing capacity for Classified workloads. This must be separate hardware infrastructure including channels and networks, not sharing components as instructed by DISA Security Technical Implementation Guides (STIGs) http://iase.disa.mil/stigs/stig/index.html. This requirement does not have any impact on the security clearance provisions of the solicitation |
| QUESTION |
| The link http://iase.disa.mil/stigs/stig/index.html returns Server Error 404 - File or directory not found. Please provide a correct link. |
| ANSWER |
| The link + http://iase.disa.mil/stigs/stig/index.html works as posted. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide processor capacity that does not adversely impact existing production workload. |
| QUESTION |
| Please clarify the meaning of ‘processor capacity’ in this context. Adds only? Reduction of resources? Physical instance? Virtual Instance? Does this apply to sub components (e.g. memory, HBA etc.)? |
| ANSWER |
| The requirement is as stated in J-2, Requirements Document, para 3.0. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide processing capacity that is moveable. If this requires the movement of equipment the first move of each piece of equipment shall be at no cost to the Government. Movement is defined as the transfer of equipment within the same DISA site or from one DISA site to another DISA site within CONUS. There will be a “Relocation Services” CLIN to support this requirement. Once the free move has been used for specific hardware, subsequent moves are billable via a call order. |
| QUESTION |
| Please clarify that the ‘first move of each piece of equipment shall be at no cost to the government’ applies to the move of equipment AFTER initial installation (i.e. first move does not include initial installation). Please clarify the expected frequency of equipment first moves? Should this be factored into the price of each system or a percentage of systems? |
| ANSWER |
| First moves do not include initial installation. Cost should be considered in vendor proposal structure. The potential exists to move all hardware utilizing the first move option. |
| DOCUMENT |
| J-2 Requirements Document, revised 11 May 11.doc |
SECTION NAME
| SECTION TEXT |
| Provide processing capacity that is moveable. If this requires the movement of equipment the first move of each piece of equipment shall be at no cost to the Government. Movement is defined as the transfer of equipment within the same DISA site or from one DISA site to another DISA site within CONUS. There will be a “Relocation Services” CLIN to support this requirement. Once the free move has been used for specific hardware, subsequent moves are billable via a call order. |
| QUESTION |
| Please clarify if this applies to ‘alternate configurations’ for example a high-density rack configuration? If so would it apply to an individual system and restricted to a move to a similar high density rack at another location? Would the high-density rack and/or entire configuration be moved? Is it reasonable to expect functionality identical external configuration for high-density environments (power etc.) in other locations? |
This is the start of the file's text. The full file is on GovTribe.
Defense Information Systems Agency