Attachment_0010_Questions_and_Answers_Amendment_0002.xlsx

Amendment 0002 Q&A

1.2 Scope

2.1 UC Soft Client Service Hosting Objectives Statement of Objectives Attachment 1

p. 6 (final SoO) Final SoO, section 1.2:

"All hosting solutions will be COCO. The Government prefers off-premise[s] hosting wherever possible."

Final SoO, section 2.1 UC Soft Client Service Hosting Objectives:

The goal of this effort is to procure a COCO, cloud-based UC Soft Client Subscription Service. Contiguous United States (CONUS) NIPRNet UC Soft Client Subscription Services may be hosted in an on premise or off premise cloud-based environment. Statement of Objectives (SOO), (unnumbered paragraph describing the Period and Place of Performance) still indicates a preference for off-premises hosting.

For section 2.1, the reference to an off-premises hosting preference in the draft SOO has been dropped in the final SOO. Hosting is a critical aspect of the system architecture. A misunderstanding would complicate an offeror's ability to respond during the 11-day period between 20 and 31 October.

2.1.2 Off Premise[s] Hosting Statement of Objectives Attachment 1 pp. 6-7 2.1 UC Soft Client Service Hosting Objectives [. . . .] Un-numbered OCONUS and SIPRNet UC Soft Client Subscription Services must be hosted on premise[s].

2.1.2 Off Premise[s] Hosting

Off premise hosting refers to commercial data centers, systems, and Cloud Service Provider (CSPs) operating within facilities that are not under the direct control of the DoD. This option requires the contractor to obtain and maintain a DoD Provisional Authorization (PA) at level 5 (NIPRNet) and level 6 (SIPRNet). Section 2.1 mandates that all SIPRNet Soft Client Subscription Services (SCSS) and all OCONUS NIPRNet services be hosted on DoD premises, Section 2.1.2, implies the off-premises option is available for impact level (IL)-6 (SIPRNet) services.

There are a number of responses to Offerors' questions in attachment 9 that have a similar conflict, including questions:

#111 (IL-5 and IL-6 PAs are required for both on-premises and off-premises);

#131 (both on-premises and off-premises hosting options are not required);

#145 (impact level 5 and 6 systems can be hosted off-premises); and #251 (off-premises preference applies to NIPRNet and SIPRNet CONUS).

If an Offeror has a current DoD PA for its proposed Cloud Service Offering (CSO) at the required impact level (Impact Level 5 and 6) it shall submit the DoD PA memo signed by the DISA Authorizing Official.

Each Offeror responding to this RFP that does not already have a DoD PA at the required security impact level for its CSO shall submit a Third Party Assessment Organization (3PAO)-produced Readiness Assessment Report (RAR), The RAR shall include all required FedRAMP and DoD information relevant to being assessed for a DoD PA at Impact Levels 5 and 6. The updated sections of Attachment 002, requires a Readiness Assessment Report (RAR), rather than a SAR. This is a change from the draft RFP section L that stated, "Each Offeror responding to this RFP that does not already have a DoD PA at the required security impact level will submit a Third Party Assessment Organization (3PAO)-produced Security Assessment Report (SAR), The report shall include all required FedRAMP and DoD documentation relevant to being assessed for a DoD PA at SI levels 5 and 6." Similar references to the need to supply a 3PAO-produced SAR were also present in draft section M.

The Government's response to question 221 states, "IL-5 & 6 services are required and will be considered for Gate 2. Security Assessment Reports (SARs) will be required for all proposed services and will be based on offerors system only. DoD PA quick look will be evaluated as provided in Attachment 0003."

If a RAR is required to meet phase 1, gate 2, the Government should be aware the FedRAMP PMO indicates it will take two to four weeks to produce a RARs for "mid-sized, straightforward systems." In our opinion, this characterization does not adequately describe the scale or complexity of the the systems required for SCSS, and likely understates the time needed to produce the requested RAR. A RAR requirement will adversely affect Offerors that were presuming an existing SAR could be used to meet the Gate 2 requirement for 3PAO-produced documentation.

Please clarify the circumstances where a RAR is required (including due date and systems in scope) and those where a SAR is required. If a RAR is required at the time a proposal is submitted, would the Government please adjust the proposal submission deadline to adequately account for the RAR production time?

Section 2.1 d) addressing the Performance Work Statement (PWS) states “However, an Offeror shall not include any details or proposal information within this PWS that is not relevant to the content of a PWS…”

Likewise, Section 3.2, Sub-factor 2, d (Milestone Schedule) mentions a Work Breakdown Schedule (WBS) with no further description or CDRL call out.

Our understanding of a PWS is that it states what results are expected, and a Work Breakdown Structure as called out in Section 3.2 Sub-factor 2.d (Milestone) provides pertinent information in addressing the “how” to perform work related to the proposal’s SOO. Further information may be needed in the PWS to provide a WBS that may be needed for the Milestone Schedule. The concern is that this essential information might be deemed as being outside the scope of a standard PWS. Again, given the short turnaround period between 20 and 31 October to respond after questions are answered,there is risk in being able to deliver a fully compliant proposal if our understanding is not correct.

The RFP also states in section 2.1 US Soft Client Service Hosting Objectives that OCONUS and SIPRNet are required to be hosted on premise.

There are challenges with this pass/fail requirement for both Level 5 and Level 6 to have a 3PAO RAR at time of submission:

Question 1. Level 6 certification for SIPRNet would require the Offeror to have an existing UCSCSS capability deployed “on premise” with SIPRNet connectivity for evaluation by the 3PAO. How would an Offeror have accomplished this prior to proposal submission since it requires government approval and Offeror investment in advance of the procurement notification? This approach severely limits competition except to Offerors who have an existing implementation.

Request: We ask that government either:

a. Modify gate 2 for the Level 6 requirements to state that Offerors demonstrate their experience in achieving ATO for a SIPRNet environment in lieu of submitting a 3PAO RAR of the Unified Capabilities Soft Client Subscription Service (UCSCSS) for Level 6

OR

b. Remove the requirement for a 3PAO RAR for Impact Level 6 and ask Offerors to describe in the technical proposal their plan to achieve Impact Level 6 certification aligned with the IOC requirements outlined in section 2.4 Fielding Objectives.

Army Benefit: Allows the Army to receive a broader set of qualified proposals based on approved APL technologies (Gate 1) and experience in deploying and supporting 100,000+ users (Gate 3).

Request: We ask that Government either:

c. Modify gate 2 for the Impact Level 5 requirements to state that Offerors demonstrate their experience in achieving ATO for a NIPRNet environment in lieu of submitting a 3PAO RAR of the Unified Capabilities Soft Client Subscription Service (UCSCSS) for Level 5

OR

d. Remove the requirement for a 3PAO RAR for Impact Level 5 and ask Offerors to describe in the technical proposal their plan to achieve Impact Level 5 certification aligned with the IOC requirements outlined in section 2.4 Fielding Objectives.

Army Benefit: Allows the Army to receive a broader set of qualified proposals based on approved APL technologies (Gate 1) and experience in deploying and supporting 100,000+ users (Gate 3).

Requirements and Objectives identified in the RFP state the Government's desire to obtain a cloud based solution. "Cloud" requirements include additional FIPS, FedRAMP, NIST and specifically the DoD Cloud Computing Security Requirements.

D-3. Antiterrorism Statement of Objectives Attachment 1 Pages 46-47 D-3. Contractors requiring Common Access Card (CAC)

1.2 Scope

2.1 UC Soft Client Service Hosting Objectives Statement of Objectives Attachment 1 Page 6 (draft SOO) and Page 6 (final SOO) Draft Statement of Objectives (SOO), section 1.3:

"All hosting solutions will be COCO. The Government prefers off-premise[s] hosting wherever possible."

Final SOO, section 1.3:

"All hosting solutions will be COCO. The Government prefers off-premise[s] hosting wherever possible."

Draft SOO, section 2.1:

"Contiguous United States (CONUS) NIPRNet UC Soft Client Subscription Services may be hosted in an on premise[s] or off premise[s] cloud-based environment, with preference to off premise hosting."

Final SOO, section 2.1:"Contiguous United States (CONUS) NIPRNet UC Soft Client Subscription Services may be hosted in an on premise[s] or off premise[s] cloud-based environment." In the draft Statement of Objectives (SOO), Section 1.3 indicates a preference for off-premises hosting, which is retained in the final SOO (although the section appears to have been merged into section 1.2 Scope).

For section 2.1, the reference to an off-premises hosting preference in the draft SOO has been dropped in the final SOO.

Response: Impact level 5 & 6 systems can be hosted off-premises but must comply with requirements as set forth in current DoD policies, guidelines and regulations. The response to this question conflicts with the SOO, in particular Section 2.1, which mandates on-premises hosting for all OCONUS and SIPRNET installations. While DoD policy may permit hosting impact level (IL)-6 systems off DoD premises, the SOO seems to require on-premises hosting.

Response: Users will utilize the Army Enterprise Service Desk as the entry point for trouble tickets. Question 1: Will the trouble ticketing function provided by the Army Enterprise Service Desk (AESD) be accessible by the Offeror's SCSS operations staff (Offeror employess or subcontractors)?

Question 2: Must the contractor record all SCSS service incidents in the AESD trouble ticketing system, such as those discovered by SCSS monitoring systems, or may an Offeror-supplied ticketing system be used? 1) Direct connections to existing Army ticketing/SMS will not be required.

2) All reportable service incidents and associated reporting thresholds will be derived from and/or captured in the SLA established between the USG and the Offeror. The Offeror will be obligated to report any and all service incidents that potentially influence SLA metrics.

34 251 Questions/Comments and Answers - Draft UC Soft Client (W52P1J-16-R-0172) Attachment 9 Question: Is the explicit preference for off-premise hosting applicable for both NIPRNet and SIPRNet instances?

2.4 Fielding Objectives Statement of Objectives Attachment 1 Pages 7 and 13 If an on premise hosting solution is proposed, the contractor must specify the number of distributed Data Centers (DC) and provide each DC requirement, such as:

• HVAC (tons) - include high density compute/cooling requirements

• Per-rack Power requirements (single phase, 3-phase, amperage, voltage, etc.)

• Floor (Rack) Space (Sq. ft.)

• Bandwidth (Mbps)

• Physical Security/Separation requirements

• Physical access requirements

• Remote management requirements

• Networking environment (IP addressing, sub netting, Computer Network Defense (CND) The table in Section 2.4, Fielding Objectives merges NIPRNet CONUS and EUR users into a single 300K user block. The same has been done with the 85K SIPRNet world-wide users. Presuming Soft Client Subscription Services (SCSS) must be provided in theater (EUR, PAC, etc.) and sized to its user population, it will be difficult to specify the data center requirements for each theater's SCSS installation without a more detailed breakdown of the expected per-location user populations.

Question 1: Would the Government please indicate whether users must be served by SCSS that are hosted in their theater of operations (or other geographic division), and if so, how many projected users of each type (NIPRNet and SIPRNet) are to be supported in each location?

Without this data, Offerors will likely overspecify the storage resources, causing additional cost for the Government, or underspecify the storage resources, introducing additional risk to the Offeror.

Response: Interfaces and integration are described within the SOO. Additional information is available DoD UC Framework 2013 (http://www.disa.mil/network-services/ucco/~/media/files/disa/services/ucco/ ucr2013/01_framework_2013.pdf). The question posed to the Government is a request for usage information to assist in sizing the resources in UC SCSS. The DoD UC Framework 2013 provides some guidance, but not enough to effectively estimate capacity without introducing significant increased cost to the Government or risk to the Offeror. As an example, the Framework document provides guidance regarding voice trunk sizing based on the end instrument (EI) population; however, it is likely individual users (the sizing metric used in the SOO) will have more than one EI (the sizing metric used in the UC Framework).

There are more reliable capacity calculation strategies--including those in the UC Framework--that require additional data that is not present in the current RFP documentation nor found in its referenced documents. Examples of this data are busy hour utilization; average hourly voice call frequency and durations; average hourly video call frequency, duration, and data rate; and average video conference endpoint population and duration.

Question 1: For the purposes of capacity planning, will the Government confirm each user will have one active EI?

Question 2: If not, how many active EIs should be used for the capacity planning formulas?

Question 3:Will the Government provide the additional capacity planning data requested? Question 1: Yes, only one active EI per user.

Question 2: See Question to answer 1 on this question..

Question 3: The vendor will have to follow industry best practice estimates, as the requested information is not available.

Gate 2: DoD Provisional Authorization (PA) Level 5 and 6 Certifications

Each Offeror responding to this RFP that does not already have a DoD PA at the required security impact level for its CSO shall submit a Third Party Assessment Organization (3PAO)-produced Readiness Assessment Report (RAR), The RAR shall include all required FedRAMP and DoD information relevant to being assessed for a DoD PA at Impact Levels 5 and 6. The Offeror shall also include its proposed schedule to achieve the DoD PA within 90 days of contract award. The schedule submitted shall provide detailed dependencies (contractor and USG), events in order to meet the required dates for PA, and shall provide a workflow of how it will be obtained. The RAR shall encompass each layer of the Cloud Service Offering and should be based upon DoD Cloud Computing regulations and guidance. Presumably, the Government is referencing the FedRAMP Readiness Assessment Report (RAR) when it uses the term "Third Party Assessment Organization (3PAO)-produced Readiness Assessment Report (RAR)".

Question: Is this presumption correct? If not, will the Government please clarify the RAR being requested and its controlling accreditation criteria?

Gate 2: DoD Provisional Authorization (PA) Level 5 and 6 Certifications

Each Offeror responding to this RFP that does not already have a DoD PA at the required security impact level for its CSO shall submit a Third Party Assessment Organization (3PAO)-produced Readiness Assessment Report (RAR), The RAR shall include all required FedRAMP and DoD information relevant to being assessed for a DoD PA at Impact Levels 5 and 6. The Offeror shall also include its proposed schedule to achieve the DoD PA within 90 days of contract award. The schedule submitted shall provide detailed dependencies (contractor and USG), events in order to meet the required dates for PA, and shall provide a workflow of how it will be obtained. The RAR shall encompass each layer of the Cloud Service Offering and should be based upon DoD Cloud Computing regulations and guidance. Presuming the FedRAMP RAR was intended, table 3-1 in the RAR template asks for a single FIPS 199 system impact level. Impact level (IL)-5 and IL-6 are two different system impact levels.

Question: Will the Government please indicate how many Readiness Assessment Reports must be submitted: a single RAR for both IL-5 and IL-6, or one RAR for IL-5 and a second RAR for IL-6?

Gate 2: DoD Provisional Authorization (PA) Level 5 and 6 Certifications

Each Offeror responding to this RFP that does not already have a DoD PA at the required security impact level for its CSO shall submit a Third Party Assessment Organization (3PAO)-produced Readiness Assessment Report (RAR), The RAR shall include all required FedRAMP and DoD information relevant to being assessed for a DoD PA at Impact Levels 5 and 6. The Offeror shall also include its proposed schedule to achieve the DoD PA within 90 days of contract award. The schedule submitted shall provide detailed dependencies (contractor and USG), events in order to meet the required dates for PA, and shall provide a workflow of how it will be obtained. The RAR shall encompass each layer of the Cloud Service Offering and should be based upon DoD Cloud Computing regulations and guidance. Presuming the FedRAMP RAR was intended, the RAR template states the following:

"To be considered FedRAMP-Ready, the CSP must meet all of the requirements in Section 4.1, Federal Mandates. In addition, the 3PAO must assess the CSP’s ability to meet the requirements in Section 4.2, FedRAMP Requirements. The 3PAO must use its expert judgment to subjectively evaluate the CSP’s overall readiness and factor this evaluation into its attestation."

Question 1: Is the 3PAO attestation required? If so, is the assessment limited to the FedRAMP-Ready criteria, as defined in the FedRAMP RAR template?

We are not aware of any existing IL-6 platforms that meet the Government's requirements. Given the Government's requirement for assessment against IL-6 criteria and the need for a physical platform to perform an assessment that leads to a 3PAO attestation, assessments for IL-6 systems will be impossible. This will lead to Offerors failing to meet gate 2 requirements, thereby leading to reduced competition.

Question 2: Will the Government consider eliminating the IL-6 RAR requirement from the gate 2 criteria?

If the Offeror submits a Provisional Authorization certification for its specific UC soft-client cloud service offering at the appropriate level (Impact Levels 5 and 6), the proposal will be deemed acceptable. If the Offeror submits a Third Party Assessment Organization (3PAO) Readiness Assessment Report (RAR) that demonstrates the Offeror’s ability to achieve a PA at the appropriate level within 90 days, the proposal will be deemed acceptable.

The Government will perform a quick-look review of the 3PAO-produced RAR package. The documentation package will be reviewed for completeness and the likelihood that the FedRAMP and FedRAMP+ requirements are or can be met, resulting in the required DoD PA within 90 days of contract award. Proposals that do not submit a 3PAO-produced RAR with supporting Artifacts or proposals that do not pass the quick look review will be rejected, and the Offeror's proposal will be given no further consideration, and the proposal volumes will not be opened or proceed into the source selection process. We are presuming when the Government uses the phrase "3PAO-produced RAR package" it is referencing a single document: a completed FedRAMP RAR template, including the diagrams and other information required by the embedded instructions. (The FedRAMP RAR template does not request any external supporting documentation.)

Question 1: Is this presumption correct? If not, would the Government please clarify what is meant by the referenced phrase?

We are presuming when the Government uses the phrase "3PAO-produced RAR with supporting Artifacts" it is referencing the 3PAO-produced FedRAMP RAR and the Offeror's proposed schedule for attaining a DoD PA within 90-days after contract award.

Question 2: Is this presumption correct? If not, would the Government please clarify what is meant by the referenced phrase?

Response: This depends on the hosting scenario. On premise hosting will need to work with hosting facility to meet and provide services based on requirements. Vendors are responsible to identify in a timely manner when circuit ordering, provisioning, or bulling is required to support its service level agreement. Off premise hosting will be required to provide connectivity to the CAP via meet me point or other CAP point of presence. Question 1: Outside of the current three MeetMe Points (MMPs) used to access DISA's boundary CAPs, what other CAP points of presence are available?

Presumably, the Offeror is to provide the connectivity between their cloud service offering (CSO) and the CAP point of presence.

Question 2: Is this presumption correct?

Question 3: If so, what connectivity options are available at the CAP points of presence (the MMPs or other points of presence)?

This information is needed to properly calculate the per-user costs for both CLIN 0001 and CLIN 0002. Question 1 Answer: Pleae refer to the CAP link, provided previously in draft RFP responses, for further information about DISA CAPS.

Question 2 Answer: Yes the CSP/CSO is resposible for connectivity from the service hosting location to the DISA CAP.

Question 3 Answer: The connectivity options are as defined in the CAP link provideded previously, via Meet Me Point or Leased Circuit.

Statement of Objectives VI 0005

The current CLINS blend together any NIPRNET deployments (both CONUS and OCONUS) and any SIPRNET deployments (both CONUS and OCONUS). Based upon the unique requirements of each deployment model, the four models may require different solutions and unique pricing. By blending these deployments, Army will lose the transparency & visibility of a cost benefit phased approach to deployment.

Recommendation:

We recommend creating new CLINS associated with delivering each of the following four deployment models:

1. NIPRNet CONUS

2. NIPRNet OCONUS

3. SIPRNet CONUS

4. SIPRNet OCONUS

Justification:

Changing this will allow the US Army to evaluate and select solutions relative to each unique deployment model. Otherwise, bidders may be forced to blend pricing across each deployment model to fully account for total costs.