EIS_RFP_QTA0015THA3003_-_SF30_-_Amend_05_(1).pdf

OMB Approval 2700-0042

1. CONTRACT ID CODE PAGE OF PAGES

AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT 1 47

2. AMENDMENT/MODIFICATION NO. 3. EFFECTIVE DATE 4. REQUISITION/PURCHASE REQ. NO. 5. PROJECT NO. (If applicable)

05 1/22/2016

6. ISSUED BY CODE 7. ADMINISTERED BY (If other than Item 6)

CODE

General Services Administration/FAS/ITS Office of Acquisition Operations

1800 F Street, NW, 4 th

Floor

Washington DC 20405

8. NAME AND ADDRESS OF CONTRACTOR () 9A. AMENDMENT OF SOLICITATION NO.

QTA0015THA3003

X 9B. DATED (SEE ITEM 11)

1710 H. Street, NW, 7 th

Floor 10/16/2015

10A. MODIFICATION OF CONTRACT/ORDER NO.

10B. DATED (SEE ITEM 13)

CODE FACILITY CODE

11. THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS

X The above numbered solicitation is amended as set forth in Item 14. The hour and date specified for receipt of Offers is __ extended, X is not extended.

Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods:(a) By completing Items 8 and 15, and returning 1 copy of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE

HOUR AND DATA SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and data specified.

12. ACCOUNTING AND APPROPRIATION DATA (If required)

13. THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACTS/ORDERS,

IT MODIFIES THE CONTRACT/ORDER NO. AS DESCRIBED IN ITEM 14.

() A. THIS CHANGE ORDER IS ISSUED PURSUANT TO: (Specify authority) THE CHANGES SET FORTH IN ITEM 14 ARE MADE IN THE CONTRACT ORDER NO. IN ITEM 10A.

B. THE ABOVE NUMBERED CONTRACT/ORDER IS MODIFIED TO REFLECT THE ADMINISTRATIVE CHANGES (such as changes in paying office, appropriation date, etc.) SET FORTH IN ITEM 14, PURSUANT TO THE AUTHORITY OF FAR 43.103(b).

C. THIS SUPPLEMENTAL AGREEMENT IS ENTERED INTO PURSUANT TO AUTHORITY OF:

OTHER (Specify type of modification and authority)

E. IMPORTANT: Contractor _ is not, _ is required to sign this document and return 1 copies to the issuing office.

14. DESCRIPTION OF AMENDMENT/MODIFICATION (Organized by UCF section headings, including solicitation/contract subject matter where feasible.)

SEE ADDITIONAL PAGES

Except at provided herein, all terms and conditions of the document referenced in Item 9A or 10A, as heretofore changed, remains unchanged and in full force and effect.

15A. NAME AND TITLE OF SIGNER (Type or print) 16A. NAME AND TITLE OF CONTRACTING OFFICER (Type or print)

Timothy Horan Contracting Officer

15B. CONTRACTOR/OFFEROR 15C. DATE SIGNED 16B. UNITED STATES OF AMERICA 16C. DATE SIGNED

(Signature of person authorized to sign)

(Signature of Contracting Officer)

NSN 7540-01-152-8070 30-105 STANDARD FORM 30 (REV. 10-83)

PREVIOUS EDITION UNUSABLE Computer Generated Prescribed by GSA

FAR (48 CFR) 53.24

RFP # QTA0015THA3003

Amendment #05

Revisions, Questions, Answers and Clarifications to the EIS RFP

This amendment includes the following:

- Questions received from potential offerors regarding the RFP. The list does not include all of the questions received thus far.

- Answers to the questions listed. Answers include changes to the RFP Sections and clarifications that do not require changes to the RFP Sections.

The revisions, questions, answers and clarifications are listed based on the UCF Sections. The question numbers are from the Acquserve portal and are not in sequential order. Please note that some answers revise more than one section of the RFP.

The RFP is amended as follows:

Question # 113 Section: Section B Section # 2.2.1.4.3

Question:

Table: Automated Attendant sizing can vary by site. The number of concurrent calls "in flight" in any given site may differ greatly from other sites. A large site with 2500 users may have an Automated Attendant that can process 30 to 40 simultaneous calls, and a small site of 30 users may only require 3 or 4 concurrent callers be supported. Given this sizing difference we request the Government consider changing the MRC CLIN VI22415 from per site to per Concurrent Caller CLIN?

Answer:

The Government will not change the charging unit for CLINs VI21415 and VI22415 from per “Site” to per “Concurrent Caller” as requested.

The RFP will be amended to reflect a change for the Auto Attendant CLINs VI21415 and VI22415 defined in Table B.2.2.1.4.3 (IPVS Feature Pricing Instruction Table) from per “Site" to per "Instance" which will represent a fixed price for each instance (associated with a telephone number) of auto attendant. The following footnote will be added under Table 2.2.1.4.3 "An Instance of IPVS: Auto Attendant is an auto attendant implementation containing the capabilities specified in Section C.2.2.1.2".

The change to Table B.2.2.1.4.3 will reflect the following:

NRC CLIN - VI21415 IPVS: Auto Attendant Charging Unit - Per Instance MRC CLIN - VI22415 IPVS: Auto Attendant Charging Unit - Per Instance

Question # 579 Section: Section B

4.1.5.1

Question:

B.4.1.4 Services Offered by Point of Presence Table includes a column for Bandwidth Group, which would be populated with the groups listed in B.4.1.5.1 Bandwidth Groups Table. However there are no entries for OWS in Table B.4.1.5.1. We recommend that GSA update B.4.1.5.1 to reflect OWS.

Answer:

The RFP will be amended to add two additional groups to table B.4.1.5.1 to accommodate future large bandwidth requirements:

16, Wireline > OC768

17. Ethernet > 1000 Gbps

Additional corrections have been made to table B.4.1.5.1 as part of this question.

Question # 610 Section: Section B

2.4.2

Question:

B.2.4.2. CHS Basic Service Prices.The table in section B.2.4.2.2 lists the charging mechanisms for Collocated Hosting service as Rack Space (CLINs CH11003 NRC and CH12003 MRC) and Metered Power (CH13005 as Usage). This price structure is inconsistent with industry pricing structures. Industry pricing is based on Power (kW or KvA), which is the method for defining colocation space by the two largest providers of colocation space in the US. Would GSA amend the RFP to at a minimum, the industry standard for price structure for colocation as an option, and make the Usage based model Optional?

Answer:

In response to the offeror's request to revise the price structure of CHS, the following revisions and clarifications are relevant.

Section B.2.4.2 was revised in Amendment 02 to state, "The contractor shall charge a monthly recurring charge for rack space (see Section C.2.4.1). This charge shall include all elements necessary to provide the services, such as building/facilities, power systems, fire suppression, cooling systems and security. The full rack space monthly price includes standard power of 30 amps and 208 volts."

The RFP will be further amended to expand the term standard power in the last sentence of the paragraph above as follows:

"The full rack space monthly price includes basic power options of 110V/208V/220V/240V, 20A/30A, single phase/three phase, as required. Non-Basic power is ICB."

The RFP will be also be amended to change CLIN CH13005 to an ICB CLIN described as "Non- Basic Power" and an NRC CLIN will be added for "Non-Basic Power". The Notes column for CLINs CH12003 is changed to replace the word 'standard' with the word 'basic.'

Question # 621 Section: Section B Section #

2.5.1

Section B.2.5.1, Cloud Service Price Structure. This section defines the the price structure for Cloud Service as being based on the EIS Catalog approach and structure. While this model allows for flexibility to offerors in terms of the addition of services and features for standard commercial offerings and allows for agencies to order solutions based on pre-defined services available in the catalog, it does not provide the ability for agencies to procure IaaS, PaaS and/or SaaS solutions that require some level of customization, that need to meet agency-specific requirements, or that are non-commoditized services. One of the objectives of including this service to the EIS portfolio is to allow for end-to-end solutions that meet agency-specific needsto to be procured under a single contract, so not including such flexibility in this service negates that benefit to the agency. Would GSA amend the solicitation to add Task Order Unique CLINs (TUCs) to facilitate customized solutions for cloud services?

Answer:

The RFP will be amended to add Task Order Unique CLINS (TUCs) for Cloud Services as Table B.2.5.2.4

Question # 684 Section: Section B

2.8.7.5.2

Question:

Can GSA make Feature CLIN AC41003: "Audio Recording of Call - USB device" OPTIONAL since this method of recording is not a commercial standard.

Answer:

CLIN AC41003 will not be made optional. However, in response to the concern raised in the question, the RFP will be amended as follows.

CLIN AC41003 which specifies USB device storage media will be deleted. CLIN AC41002 which specifies CD/DVD storage media will be redefined as "Audio Recording of Call - Removable Storage Media" with a charging unit of "Each" allowing more flexibility in the storage media format.

Section C.2.8.7.2 Feature 1 will be amended to delete "(e.g., disc or USB device)".

Question # 718 Section: Section B

2.10.4.3

Question:

Section B.2.10.4.3 "Because all SRE MRC payments automatically cease on the end date of this contract, the contractor may, subject to government approval, be permitted to decline to provide SRE MRC term periods that are longer than the then-remaining maximum potential term of the contract." Contractors should be allowed to decline to provide SRE MRC term periods that are longer than the then-remaining months on the contract without the requirement to obtain the Government's approval. We recommend GSA remove the "subject to government approval" so that Section B.2.10.4.3 reads: "Because all SRE MRC payments automatically cease on the end date of this contract, the contractor may decline to provide SRE MRC term periods that are longer than the then-remaining maximum potential term of the contract."

Answer:

The statement below table B.2.10.4.3 will be amended to state: "Because all SRE MRC payments automatically cease on the end date of this contract, the contractor may decline to provide SRE MRC term periods that are longer than the then-remaining maximum potential term of the contract."

Question # 797 Section: Section B

2.1.1.3.2

Question:

CLINs VN21001 through VN21004 - Will GSA make the referenced service both an optional service and a part of the Managed service offering? Not all vendors will be able to offer this service on a global basis and this service requires vendor management intervention to assure the proper port rate on both PE and CE. Given the rapid provisioning SLAs, If the vendor does not have access to the CE, the vendor is put at an undue risk for SLA violations.

Answer:

The RFP will be amended. Bandwidth on Demand CLINS VN21001 through VN21004 will be made optional. The offeror may choose to provide an unmanaged or managed solution, or both.

The RFP will be further amended to make scalable CLINs VN20001 through VN20009 optional to complement the BoD CLIN changes that were requested.

Question # 893 Section: Section B

2.4.2

Question:

EXCEPTION REQUEST. B.2.4.2. CHS Basic Service Prices. The table in section B.2.4.2.2 lists the charging mechanisms for Collocated Hosting service as Rack Space (CLINs CH11003 NRC and CH12003 MRC) and Metered Power (CH13005 as Usage). This price structure is inconsistent with industry pricing structures. Industry pricing is based on Power (kW or KvA), which is the method for defining colocation space by the two largest providers of colocation space in the US. Would GSA amend the RFP to at a minimum, the industry standard for price structure for colocation as an option, and make the Usage based model Optional?

Please see the response to question 610.

Question # 932 Section: Section B

B.2.9.1.4

Question:

I failed to price some access NRC CLINs at some non-domestic NSCs but the error checker did not detect those omissions. Can you explain why it didn't?

That behavior will be corrected in Amendment 05 by amending the bid model to ensure that the traffic records for access NRC CLINs at non-domestic NSCs have nonzero quantities in year 1.

Question # 939 Section: Section B

1.2.11.1

Question:

Please clarify the difference between the required CLIN Case Number and the Auto-Sold CLIN Case Number in table B.1.2.11.1 Auto-Sold CLINs. Should the case numbers be identical for a given row?

Answer:

The CLIN Case Number only applies if the CLIN is ICB. The Auto-Sold CLIN Case Number only applies if the Auto-Sold CLIN is ICB. In the event that an ICB CLIN has multiple ICB Auto-Sold CLINs related to it, the table will contain multiple rows with the same CLIN, CLIN Case Number, and Auto-Sold CLIN values, but different Auto-Sold CLIN Case Number values.

The instructions for table B.1.2.11.1 will be amended to clarify that the CLIN Case Number column shall be populated with -1 for CLINs where the case number does not apply (i.e., non- ICB CLINs), and the Auto-Sold CLIN Case Number column shall be populated with -1 for Auto- Sold CLINs where the case number does not apply (i.e., non-ICB Auto-Sold CLINs).

Question # 944 Section: Section B

1.2.14.1

Question:

Offers proposing a catalog based service are required to populate table B.1.2.14.1. for services that apply thorughout the US it appears that populating the Originating Country ID and Terminating Country ID is not sufficient. Please provide further instructions on how to populate the Originating NSC and Terminating NSC for this table since they are required.

Answer:

Section B.1.2.14 will be amended to clarify that the Originating NSC and Originating Country/Jurisdiction ID columns of table B.1.2.14.1 shall be populated with -1 when not applicable, and the Terminating NSC and Terminating Country/Jurisdiction ID columns of table B.1.2.14.1 shall be populated with null values when not applicable.

Question # 956 Section: Section B

2.1.7.3

Question:

CLINs IP10070 and IP10080 are marked as mandatory for non-domestic in Section B.2.1.7.3.

However, the CLIN reference table in AcquServe has them marked as mandatory for all regions.

Will the government please clarify the requirement?

The CLIN reference table in AcquServe will be updated to correctly identify that CLINs IP10070 and IP10080 are optional for domestic locations.

Question # 890 Section: Section C

2.5.1

Question:

EXCEPTION REQUESTS. C.2.5 Cloud Service is a catalog suite of services and cloud offerings must meet all the applicable NIST requirements. FedRAMP certification for cloud offerings is mandatory for a vendor to bid on agency task orders, and this is currently projected to begin in 2017. This is when vendor cloud offerings need to have achieved FedRAMP certification. IAW with these precepts, the language in sections C.2.5.1-C.2.5.4 should be a guide to agencies on what services can be requested within the categories of IaaS, PaaS, SaaS or CDNS. With product evolutionary cycles occuring in weeks rather than years, the product catalog will be out of date for the Cloud service descriptions before EIS contracts are awarded. To protect the integrity of what we believe GSA intended, a simple shift in section C's language from "mandatory and optional" to "Illustrative" will address industry and technology realities for cloud services. Please amend the solicitation accordingly. Section B.2.5.2, Cloud Service Price Structure. This section defines the price structure for Cloud Service as being based on the EIS Catalog approach and structure. While this model allows for flexibility to offerors in terms of the addition of services and features for standard commercial offerings and allows for agencies to order solutions based on pre-defined services available in the catalog, it does not provide the ability for agencies to procure cloud solutions that require some level of customization, that need to meet agency-specific requirements, or that are non-commoditized services. One of the objectives of including this service to the EIS portfolio is to allow for end-to-end solutions that meet agency-specific needs to to be procured under a single contract, so not including such flexibility in this service negates that benefit to the agency. Would GSA amend the solicitation to add Task Order Unique CLINs (TUCs) to facilitate customized solutions for cloud services?

See question number 621 for response.

Question # 907 Section: Section C

2.2.1.2

Question:

The submission matrix includes requirement 91 for C.2.2.1.2 as Three-way conference calling - Allows a station user to establish a multiparty conference connection of up to three conferees including themselves. However, this requirement is not found in section C.2.2.1.2. Would the Government please remove requirement 91 from the submission matrix?

Answer:

The RFP will be amended. Section J.19, Worksheet Vol. 1A, Row 161 includes an additional requirement for three-way calling which is superfluous and will be deleted.

Question # 940 Section: Section C

2.1.1.3

C.2.1.1.3 VPNS. We think GSA intended there to be a correlation in the speeds among the xDSL downlink speeds for VPNS and Access Arrangements. Can GSA please confirm... There seems to be a conflict in the area of xDSL downlink data rates between the Access B tables and Section C.2.1.1.3 (#4) VPNS. Access B tables call for xDSL up to 8 Mbps downlink; VPNS calls for up to 50 Mbps downlink. Will GSA amend the RFP so that all downlink speeds align with each other.

Answer:

RFP Section C.2.9.1.4 will be amended as follows: The Access Arrangement, capability #17, Digital Subscriber Line (DSL) Access Arrangements, ADSL downstream speed, second sentence will read “Speeds up to 50 Mbps are optional.” to reflect changes from 9 Mbps to 50 Mbps.

Question # 942 Section: Section C

2.1.2.2

Question:

C.2.1.2.1. ETS. With Amendment 2, the GSA removed the B.2.1.2.5.2 Ethernet Transport Feature Pricing table for BOD but did not make any changes to the corresponding C section requirements. Can the GSA please update the BOD Feature table in section C.2.1.2.2 to make BOD Optional to match the ETS E-LAN pricing section for scalable pricing?

Answer:

ETS Bandwidth on Demand (BoD) CLINs will remain mandatory to offer.

The RFP will be amended to delete Table "C.2.1.2.2 Features."

When Table B.2.1.2.5.2 was deleted (see answers to Questions 213, 582, 802), five BoD CLINs that were part of the table were also deleted. These BoD CLINs were for bandwidths that were in addition to the BoD CLINs in the E-LAN pricing table (B.2.1.2.4.2), which has not changed. All E-LAN BoD CLINs have been, and will remain, mandatory to offer.

For reference:

Question 213 resulted in a change to the RFP in Amendment 02.

Question 582 was answered in Amendment 03.

Question 802 was answered in Amendment 04.

Question # 182 Section: Section G

4.1.7

Question:

The RFP Section G.4.1.7 describes a new requirement not mentioned within the Draft RFP related to "Electronic Billing". The requirement references "the contractor shall input invoice summary data into a designated government system", but provides no other detail related to this requirement within Section J of the RFP with regard to the data elements which would make up an invoice summary. 1) Will GSA work with the agencies to develop specifications for standard data elements to be used within their task order requirements for the invoice summary data? 2)

What are the transmission/data exchange method(s) prescribed for this type of invoice summary data submissions (e.g., Secure FTP, manual entry into the agency's website, or other transmission type)? 3) Please modify the solicitation to reflect the timeframe for delivery of the summarized invoice to be subsequent to a date later than the BI (Billing Invoice) deliverable?

Answer:

Question 1 The contractor shall comply with the invoice data summary format of the system selected at the

TO.

More details on the systems listed in Section G.4.1.7 can be found in the following links:

- WebVendor: https://finance.ocfo.gsa.gov/webvendors/UserGuideForRO.aspx

- Vendor and Customer Self Service (VCSS) system: https://vcss.ocfo.gsa.gov/

- Invoice Processing Platform (IPP): http://www.ipp.gov/

- Other systems as specified in the TO The government plans to specify data standards and exchange mechanism for electronic invoicing in the future. Please refer to OMB Memo M-15-19.

Question 2 There is no requirement for system to system data exchange/transmission for contractors to provide electronic invoice summary data in order to process payments. Contractors will use the respective secure web-based system to provide the invoice summary data.

Question 3 The Government doesn’t intend to specify when the Contractor needs to provide an electronic summary invoice, however both the Billing Invoice (Section J.2.5) and the electronic summary invoice (Section G.4.1.7) must be submitted before the prompt payment clock begins.

The RFP will be amended in Section G.4.1.7 to change the reference from “Section J.2.4” to “Section J.2.5”.

Question # 388 Section: Section J

J.1.2.1

Question:

Table J.1.2.1 appears to list CONUS as a non-domestic location. Will the government confirm that CONUS should be removed from the table?

The RFP will be amended to remove Domestic: CONUS from the table.

Question # 757 Section: Section J

2.10.2.1.9

Question:

Per J.2.10.2.1.9 Dispute, "agency_task_order_num" is to be provided if applicable. Every Dispute should have an associated Task Order Number, since no service orders can be placed unless they are associated to a task Order. Please provide an example of when a TO number would not be available. Alternatively, we recommend changing the Value Requirement to

'Always'.

The RFP will be amended in Section J.2.10.2.1.9 to change the value requirement for "agency_task_order_num" to "Always" vs. "If Applicable".

Question # 761 Section: Section J

2.10.2.1.6

Question:

J.2.10.2.1.6 Central Billed Agency Setup lists the data elements contained in the CBAS file delivered by GSA and includes "gsa_account_number". The description for "gsa_account_number" states: "GSA Account Number is account number provided after TO award." We are concerned that there is no association of the GSA account number and the vendor account number to a specific Task Order. We recommend GSA add "agency_taks_order_num" as a data element in the CBAS File defined in J.2.10.2.1.6.

Answer:

The GSA account number is only intended to link the CBAS to the CBASR. The primary reference point for each TO is the TO number (agency_task_order_num).

The RFP requirements for CBAS, CBASR, and DBAS will be amended as follows:

In Section J.2.10.2.1.6, insert the following line after contract_number:

Element Name: contractor_invoice_level_account_number Value Requirement: If Applicable

In Sections J.2.10.2.1.6, J.2.10.2.1.7, and J.2.10.2.1.8 insert the following line after contractor_invoice_level_account_number:

Element Name: agency_task_order_num Value Requirement: Always

In Sections J.2.10.1.3.3.1 and J.2.10.1.3.3.2 to update the attachments with files containing XSDs and WSDLs that reflect the above changes.

Question # 931 Section: Section J

2.10.2.1.24

Question:

The TAX data set requires reporting individual tax items that are aggregated in the BI. However in the case of usage CLINs (and possibly other cases) a single UBI may appear on the BI multiple times with no clear mechanism to indicate on the TAX data set which appearance of a given UBI a tax is associated with. Without the ability to connect these values in an automated manner, reconciling tax records will require manual review and any discrepancies will require extensive auditing on both the government and contractor sides. If a data element is included to connect the data, reconciliation can occur automatically and any discrepancies will be easily traced.

The RFP will be amended as follows:

In Sections J.2.10.2.1.4, J.2.10.2.1.9, and J.2.10.2.1.10, insert the following line after tax_item_number:

Element Name: billing_invoice_line_sequence_number Value Requirement: If Applicable

In Section J.2.10.2.1.24, insert the following line after tax_item_number:

Element Name: billing_invoice_line_sequence_number Value Requirement: Always

In Section J.2.10.3.1.2, insert the following line (table is sorted alphabetically by Element Name):

Element Name: billing_invoice_line_sequence_number Description: Billing Invoice Data Transaction line sequence number. Each data record must have a unique line item number.

Data Type: Numeric Length: 14 Edit Mask: [BLANK]

Question # 945 Section: Section J Section # 19

In Amendment 4, the Submission Matrix row for RFP Section C.2.1.1.1.4 ID 10 has a "C" to the far right beyond the proposal page number column. If this "C" is intended to mean that GSA expected a "change" to this requirement, neither the Submission Matrix nor the RFP text in that Section C reference have changed. Did GSA intend to make a change to the requirement at

C.2.1.1.1.4 ID 10?

Answer:

The change was made in Amendment 02, not Amendment 04. The 'C' indicator for C.2.1.1.1.4 ID 10 in J.19 vol. 1a has been removed.

Question # 946 Section: Section J Section # 19

In Amendment 4, the Submission Matrix row for RFP Section C.2.1.2.1.4 ID 2 has a "C" to the far right beyond the proposal page number column. If this "C" is intended to mean that GSA expected a "change" to this requirement, neither the Submission Matrix nor the RFP text in that Section C reference have changed. Did GSA intend to make a change to the requirement at

C.2.1.2.1.4 ID 2?

Answer:

The change was made in Amendment 02, not Amendment 04. The 'C' indicator for C.2.1.2.1.4 ID 2 in J.19 vol. 1a has been removed.

Question # 948 Section: Section J Section # 19

In Amendment 4, the text of the Submission Matrix for C.2.1.3.1.4 does not match the RFP text for C.2.1.3.1.4. Please revise the Submission Matrix to match the requirement text of the RFP.

Answer:

The RFP will be amended to include the full text of items 1, 2 and 3 for C.2.1.3.1.4 in submission matrix J.19 vol. 1b.These are marked with the 'C' change indicator.

Question # 950 Section: Section J Section # 19

In the Amendment 4 Submission Matrix, there is a new requirement noted for Section C.2.2.1.2 ID 3. However, RFP Section C text was not revised to add #3 for three-way conference calling.

Please remove the Submission Matrix row for Section C.2.2.1.2 ID 3 addressing three-way conference calling.

Answer:

The RFP will be amended and the three-way conference calling row for Section C.2.2.1.2 ID 3 will be removed from the J.19 submission matrix worksheet vol. 1A.

Question # 952 Section: Section J

2.10.3.1.2

Question:

In Amendment 04, in its response to Question #674, h), GSA provided the following: h) In Section J.2.10.3.1.2, insert the following line (table is sorted alphabetically by Element Name): - Element Name: adjustment_detail_tax_billed - Description: Adjustment detail of the aggregated tax - Data Type: Numeric - Length: 23 - Edit Mask: NNNNNNNNNNNNNNNN.NNNNNN In the Amendment 04 update of the RFP for this section, the description for this Element Name included in the RFP section's table is incorrectly documented as "Disputed" rather than "Adjustment" as follows: adjustment_detail_tax_billed=Disputed detail of the aggregated tax. We request that GSA update the appropriate cell in the Section J table to correct this.

Answer:

The RFP will be amended in Section J.2.10.3.1.2 for the item "adjustment_detail_tax_billed" description to read "Adjustment detail of the aggregated tax" vs. "Disputed detail of the aggregated tax".

Question # 957 Section: Section J

.2.10.2.3.3

Question:

The TO Financials deliverable contains the financial data for each TO, provided by fiscal year.

However, periods of performance do not have to follow the Government fiscal year.

The RFP will be amended as follows:

In section J.2.10.2.3.3 to read "for each Performance Period covered by the TO (i.e. the TO "base" and any TO "option periods")." vs "for each fiscal year covered by the TO."

In section J.2.10.2.3.3 table, remove the following lines:

Element name: “fiscal_year” Element name: “fy_funding”

In section J.2.10.2.3.3 table, insert the following lines after to_ceiling:

Element name: “performance_begin_date” Description: Performance period begin date

Element name: “performance_end_date” Description: Performance period end date

Element name: “performance_period_funding” Description: Dollar value of the funding for the performance period defined by the performance_begin_date and performance_end_date

Question # 930 Section: Section M

M.2.2(1)

Question:

Shouldn't the Quality of Systems in M.2.2(1) be amended to synchronize with the language in Section L.30.1.1(a)?

Answer:

Yes, as a result of amendment 02 (see questions 37 and 543) the language in M.2.2(1) will be amended to say:

1. Quality of Systems. Degree to which the offeror’s approach demonstrates the capability to provide user-friendly, compliant and efficient support systems, including: "Ordering, Billing, Business Support Systems, Customer Support Office and Technical Support, Trouble Ticket Management, Inventory Management, Service Level Management, and Training."

Questions and Answers That Do Not Include RFP Changes

Question # 220 Section: Section B

2.5.2.1

Table B.2.5.2.1. Please specify how offerors should propose multiple line items associated with the same CLIN in B.2.5.2.1 and B.2.5.2.3. For example if offerors price two IaaS configurations with Usage-based pricing would both be labeled as CLIN IA900003?

Answer:

In table B 2.5.2.1 the columns labeled Vendor Unique ID (e.g., SKU) and Case Number are the specified methods for unambiguously identifying items. In the example cited in the question, each variation of the configurations would have different and unique Vendor ID and Case Number.

Question # 354 Section: Section B

2.2.3.4.2

Question:

B.2.2.3.4.2, page 77. There are currently NO CLINS for Faxback service - as this generally requires a high degree of customization, it should not be part of the basic TFS IVR service. We request that there be 3 CLINS for Faxback: NRC for implementation of service, MRC (usage) for use of the service (i.e., per page sent) and NRC for design of service (professional services).

Answer:

Section B Table B.2.2.3.4.2 contains the TFS Feature Pricing Instructions. NRC CLIN TF90031 is used for Interactive Voice Response (IVR) and is an ICB CLIN. Faxback capability is an option and may be included when pricing this CLIN based upon agency requirements. The government does not see the need for additional CLINS.

In Section C, Table C.2.2.3.2, ID number 14, Description 8, the faxback capability was made an optional sub-feature. (See question #353, amendment 04)

Question # 375 Section: Section B

1.3.3

Question:

As drafted section B.1.3.3 Termination of Support obligates awardees to continue to provide support for the existing item at the established price until a solution acceptable to the government is implemented by the contractor. Would the GSA consider amending this provision to allow awardees to withdraw services at the end of each of the three contract periods (base period + two option periods). If GSA would permit awardees to withdraw a service at the exercise of an option period the awardee would be obligated to meet all obligations for any existing orders of that service while not being obligated to continue to take new orders for such services

See the answer to question 374.

Question # 558 Section: Section B

2.1.3.2

For Metro OWS services how does the offeror define the NSCs that the wave would go between? We understand that table B.4.1.12 defines the NSC but wouldn't that only be for one end point not two? How does the government define OWS services that would fall under the Metro category? Is it a service that goes between two of the NSCs identified in table B.4.1.12?

Answer:

Metro OWS is a multipoint service that only requires that an NSC be added to the group. Only the originating NSC is required to purchase the service.

Question # 584 Section: Section B

2.1.7.3.2

Question:

B.2.1.1.3 VPNS Transport states: "All configurations of Quality of Service (QoS) are defined in Section C.2.1.1.1.4. Capabilities #7, #8, and #9 shall be included in the port price (i.e., NSP).

Since QoS is also ICB, a case number shall be assigned for each port purchase and a description shall be provided of how the port will be configured." However, under B.2.1.7.3.2 IPS Port Pricing Instructions Table, CLIN IP50001 IP Quality of Service (QoS) is defined as NSP, meaning all IPS QoS features described in C.2.1.1.1.4 are to be included in the port price.

Under these requirements, the vendor is expected to include QoS in the port pricing and to submit a mod in "gen_ICB" B table format to describe the QoS configuration for all circuits that require any QoS levels. We recommend that CLIN IP50001 IP Quality of Service (QoS) be priced as ICB, and not included in the port pricing (i.e. NSP), as QoS cost can vary by jurisdiction.

Answer:

The government's intent is to include the price of the Quality of Service (Qos) in the Port pricing.

The purpose of the ICB designation of the QoS CLIN is to allow a unique description of how each port will be configured.

Question # 598 Section: Section B

2.1.7.3.2

Question:

C.2.1.7.2 Features states: "The contractor shall accommodate and optimize an agency's applications to enable the network to accurately and consistently allow for traffic prioritization and cost-efficiencies. The Classes of Service or prioritization levels may be categorized as: 1.

Premium - for time-critical traffic such as voice and video; 2. Enhanced - for business-critical traffic such as transactions; 3. Standard - for non-critical traffic such as email." However, under B.2.1.7.3.2 IPS Port Pricing Instructions Table, CLIN IP50001 IP Quality of Service (QoS) is defined as NSP, meaning all IPS QoS features described in C.2.1.7.2 are to be included in the port price. We recommend that the Enhanced and Premium classes of services be priced using specific ICB CLINs and not bundled into the port pricing. This will allow vendors to offer different levels of service at different price points to align with customers' specific needs.

Answer:

The government's intent is to include the price of the Quality of Service (QoS) in the Port pricing.

The purpose of the ICB designation of the QoS CLIN is to allow a unique description of how each port will be configured.

Question # 605 Section: Section B

2.1.2.4.2

Question:

B.2.1.2.1. Ethernet Transport Service Price Structure states "All configurations of Quality of Service (QoS) are defined in Section C.2.1.2.1.4. Capability #29 shall be included in the port price (i.e., NSP). Since QoS is also ICB, a case number shall be assigned for each port purchase and a description shall be provided of how the port will be configured." However, B.2.1.2.4.2 E-LAN Port Pricing Instructions Table, CLIN EN50001 E-LAN Quality of Service (QoS) is defined as both NSP and ICB. Question 1. C.2.1.2.1.4 does not include an item #29 for QoS. Did GSA intend to reference, #26. Quality of Service (QoS): "The contractor shall support traffic prioritization that enables higher priority traffic to be transmitted first." Question 2. All IPS QoS feature described in C.2.1.1.1.4 are to be included in the port price (i.e., NSP). However, the vendor is still expected to submit a mod in "gen_ICB" B table format to describe the QoS configuration for all circuits that require any QoS levels. We recommend that CLIN EN50001 E- LAN Quality of Service (QoS) be priced as ICB, and not included in the port pricing, as QoS cost can vary by jurisdiction.

Answer:

Response to Part 1 of question: The RFP was amended for B.2.1.2.1 paragraph 2 to reference technical capability #26 instead of #29. The change is included in Amendment 02.

Response to Part 2 of question: The government's intent is to include the price of the Quality of Service (Qos) in the Port pricing. The ICB designation of the QoS CLIN allows offerors to price and describe how each port will be configured.

E-LAN Port prices table B.2.1.2.4.1 includes a Country/Jurisdiction ID field.

Question # 633 Section: Section B

2.1.3.2.3

Question:

OWS instructions include a table for OCONUS transport with no provision for OCONUS-to- CONUS Jurisdiction pairs. Will the Government please confirm that OCONUS OW transport prices should include all relevant OCONUS-to-CONUS Jurisdiction pairs?

Answer:

Yes. When pricing pairs, if the pair is CONUS to CONUS use the CONUS table. If it's OCONUS to CONUS, or CONUS to OCONUS, or OCONUS to OCONUS, use the OCONUS table. If one side is non-domestic, then use the non-domestic table.

Question # 640 Section: Section B

2.1.3.2.4

OWS instructions include a table for Non-Domestic transport with no provision for Non-

Domestic-to-CONUS or Non-Domestic-to-OCONUS Jurisdiction pairs. Will the Government please confirm that Non-Domestic OW transport prices should include all relevant Non- Domestic-to-CONUS or Non-Domestic-to-OCONUS Jurisdiction pairs?

Please refer to question 633 for the answer.

Question # 644 Section: Section B

2.1.3.2.2

Question:

OWS instructions include a table for in-country CONUS transport with no provision for in-country OCONUS/Non-Domestic transport. Will the Government please consider accommodating OCONUS/Non-Domestic transport in the price/instruction tables and identifying them as ICB?

Answer:

The referenced requirements will continue to be fixed-price. The method for in-country pricing of OCONUS/non-domestic is to put the same Country/Jurisdiction in both parts of table B.2.1.3.2.3/ B.2.1.3.2.4.

Question # 658 Section: Section B

2.8.7.3.2

Question:

Can the government please remove Reservation-less CLINS AC21003 and AC21004 from the ACS Reservation Pricing table B.2.8.7.3.2. Reservation-less prices are captured in the ACS Basic Usage Price Table B.2.8.7.2.2.

This question was answered in question #288 in Amendment 01.

Question # 668 Section: Section B

2.10.5

Question:

Often equipment manufactures will offer multple service levels of maintenance especially for software. It is recommended that the government allow manufacturers' service/maintenance part numbers as SREs?

Answer:

There are multiple ways to accommodate items needed to configure or support equipment as catalog items. For example, where software licenses are charged separately, the software maintenance may be entered using Pricing Element 3 described in section B.2.10.3 and Table B.2.10.3.1. In another example, for multiple maintenance options whether hardware or software, separate case numbers could be defined using the part number (or any other unique identifier) for the item being maintained as determined by the offeror. Note also that "additional pricing elements may be defined upon request by the contractor." These could be used to identify other maintenance options that apply to catalog items, for example. Alternative strategies are available for using MNS ICB CLINs to define various maintenance options associated with delivering MNS.

Question # 680 Section: Section B

2.1.3.2.3

Question:

Can the government change the OWS OCONUS pricing requirement to Optional similar to the OWS Non-Domestic price requirement? Given the bandwidth requirement for OWS, OCONUS to CONUS/OCONUS/Non-Domestic would be a custom solution.

Answer:

The referenced requirements will remain mandatory. Given the now highly-predictable CONUS/OCONUS per-mile costs for OWS (or DWDM), the government is requesting fixed prices for the service.

Question # 726 Section: Section B

2.1.1.3.2

Question:

Under B.2.1.1.3.2 VPNS Port Pricing Instructions Table, the RFP states: "For each T3 burstable or Ethernet burstable MRC CLIN, a corresponding burstable overage usage CLIN shall be auto-sold to simplify ordering. For example, Ethernet burstable overage CLIN VN31500 shall be auto-sold with Ethernet burstable transport CLIN VN30024, and T3 burstable overage CLIN VN30009 shall be auto-sold with T3 burstable CLIN VN30003." Unlike the overage CLINs for the standard Ethernet burstable transport CLINs (VN31020, VN31030, VN31040, VN31050,VN31200, VN31300, VN31400, VN31500, and VN31600), the T3 burstable overage CLIN has not been broken down into separate CLINs for each bandwidth. We recommend CLIN VN30009 be broken into separate corresponding CLINs as the RFP suggests. This would include a separate overage CLIN for VN30001, VN30002, VN30003, VN30004, and VN30005 to replace the one overage CLIN VN30009.

Answer:

The offeror's suggestion will not result in a change to the RFP. The difference between T3 and Ethernet overage pricing is that the government does not expect there to be much of a difference in the per-megabit price for T3 overage--regardless of the committed rate. For Ethernet overage, the per-megabit cost can vary significantly depending on the committed rate, thus there are CLINs to allow for offerors to account for these variations.

Question # 728 Section: Section B

1.3.3

Question:

B.1.3.3 Termination of Support states: "If the contractor desires to discontinue support for an item (for example, an item that will no longer be supported by the manufacturer), the contractor shall notify the GSA CO and any affected agencies at least 18 months before support is stopped

(see Section B.2.10.7 for an exception for mobile devices). As appropriate, at time of notification, the contractor shall also recommend a solution acceptable to the government that ensures service continuity. The contractor shall continue to provide support for the existing item at the established price until a solution acceptable to the government is implemented by the contractor. Following notification of the GSA CO and affected agencies, the contractor shall no longer accept orders for the item." In the event that the GSA CO approves a new acceptable solution to replace a service to be terminated, but another agency refuses to transition after 18 months' notice, will the GSA CO approve termination of the service from EIS and require the agency to place disconnect orders to transition from the terminated service?

Answer:

Section B.1.3.3 is only applicable to items included in the contractor's catalog. Changes to a catalog do not necessarily result in changes to TOs. For the removal of an item from a TO, the OCO would have to review and approve a modification to the TO. The GSA CO is not involved in approving the termination of the item at the task order level.

Question # 742 Section: Section B

2.1.1.3.2

Question:

B.2.1.1.3.2 VPNS Port Pricing Instructions Table states: "Because agencies have differing interests for balancing budgetary control against ordering complexity, Table B.2.1.1.3.2 includes two mandatory pricing mechanisms for achieving dynamic bandwidth: scalable bandwidth and burstable bandwidth." Regarding the use of Burstable Bandwidth for Layer 3 VPNs: Since most agency VPNs consist of numerous locations, implementing this feature over multiple VPNS ports without carefully controlling data usage could cause monthly overage fees to quickly escalate beyond agency budget targets. Scalable Bandwidth capability, on the other hand, helps agencies maintain cost control because network administrators initiate bandwidth increases with the full understanding of the financial impact these increases would incur. We recommend Scalable Bandwidth be the sole mandatory pricing mechanism offered in order to preserve an Agency's financial posture, and that Burstable Bandwidth be an optional pricing mechanism.

Answer:

Burstable bandwidth will remain a mandatory requirement. As with any usage based service, agencies, in some cases with the help of tools supplied by the offeror, are responsible to monitor their usage. Where applicable, agencies can use contracting methods, such as including NTE (Not to Exceed) clauses in their TOs, to ensure they do not exceed their budget for any given service.

Question # 744 Section: Section B

2.10.4

Question:

B.2.10.4 Payment Methods reads: "If an SRE MRC period selected by a user is terminated by the user before the period has concluded (for the purpose of having SRE removed by the contractor), in addition to all applicable SRE MRCs due up to the notice of termination, a refurbishment payment equal to 25% of the remaining projected payments due for the selected

SRE MRC term period shall apply. However, in no case shall the amount of the refurbishment payment exceed the SRE NRC. If a user initially selects an SRE MRC payment term, and subsequently chooses to terminate its SRE MRC payment term early and continue using the associated SRE, the user shall pay the SRE NRC, less the cumulative SRE MRC payments (exclusive of finance charges defined by the Monthly Payment Factor) paid up to the time of notification of such selection." We agree with the provisions stated in B.2.10.4 when SREs removed by the contractor can be refurbished and resold by the contractor. However, if an SRE MRC period selected by a user is terminated by the user before the period has concluded (for the purpose of having SRE removed by the contractor), AND that SRE cannot be refurbished or resold (e.g. it must be destroyed due to regulations, FARs, or security protocol), we recommend that the user be charged a refurbishment payment equal to 100% of the remaining projected payments due for the selected SRE MRC Term period.

Answer:

The RFP will not be changed. The contractor is not prevented by the terms and conditions of the RFP from refurbishing and reusing the equipment under another non-EIS contract.

Question # 813 Section: Section B

2.10.4.1

Question:

Will GSA make the amount payment for early termination of SRE equal to the remaining amount on the lease? Failing that will GSA clarify that Re-Stocked SRE is allowable for reuse on EIS.

Answer:

The RFP will not be changed. Restocked or refurbished equipment may not be offered under EIS. However, the contractor is not prevented by the terms and conditions of the RFP from refurbishing and reusing the equipment under another non-EIS contract.

Question # 843 Section: Section B

1.3.2

Question:

May vendors require User registration and authentication?

Answer:

Yes. B.1.3.2 bullets 2 and 3 are consistent with allowing the contractor to place access controls on the catalog. The EIS CO will have general oversight of the process, but will not be involved in approving individual registration.

Question # 908 Section: Section B

2.8.1.3.2

Question:

OLD QUESTION # 311: Would the Government define "small", "medium", and "large"?

ANSWER # 311: The government is not defining "small", "medium", etc. The offeror shall describe their approach to device size assignment as required in Section L.34.1 Price

Response, bullet #8. In addition, if an offeror decides to propose SREs, then each device shall be classified in the SRE catalog (section B.2.10.2.1 SRE Catalog - Product Specification Table), specifically the field labeled "device size". OLD QUESTION # 331: The table in B.2.8.1.3.2 specifies different CLINs for different sized devices. Please provide a better description of each size. For example: extra small may mean a desk top or hand held devices where extra-large may refer to a piece of equipment that is 10 or more rack units or larger. ANSWER # 331: The government is not defining "small", "medium", etc. The offeror shall describe their approach to device size assignment as required in Section L.34.1 Price Response, bullet #8. In addition, if an offeror decides to propose SREs, then each device shall be classified in the SRE catalog (section B.2.10.2.1 SRE Catalog - Product Specification Table), specifically the field labeled "device size". OLD QUESTION # 397: The pricing table for MNS device management has 5 CLINs (1 Extra Small - 2 Small - 3 Medium - 4 Large - 5 Extra-Large) without further description of parameters in Section C. Please describe and elaborate on bandwidth - physical size -system scope etc. ANSWER # 397: The government is not defining "extra small", "small", "medium", etc. The offeror shall describe their approach to device size assignment as required in Section L.34.1 Price Response, bullet #8. In addition, if an offeror decides to propose SREs, then each device shall be classified in the SRE catalog (section B.2.10.2.1 SRE Catalog - Product Specification Table), specifically the field labeled "device size". NEW QUESTION # 311-331-397: Answers # 311, 331, and 397 provided by the Government essentially leave classification of MNS device size up to individual offerors for pricing purposes - which may result in a wide variety of definition among offerors. The Traffic Model to evaluate MNS pricing has the following Year One quantities: MN10001 1265; MN10002 9106; MN10003 5303; MN10004

3169; MN10005 14; MN11001 213; MN11002 1631; MN11003 875; MN11004 545; ; MN11006

4. The fact that NRC quantities are much lower than MRC quantities implies a necessity to manage existing equipment: in which case - will the Government please provide detailed data on current devices that will need such management? (Without such detailed data - offerors -particularly non-incumbent offers - will lack knowledge of the universe of devices to manage -which may give a distinct and unfair advantage to incumbents and slant the playing field.)

Answer:

The draft RFP released in February 2015 provided a list of all the equipment in use and quantities via the AcquServe portal. This list was available to all offerors. In Amendment 04, a copy of that table was placed in the Final RFP reference tables. The table "equipment_in_use" is in the reference table (wdm_eis) schema in AcquServe.

For evaluation purposes only, the traffic model divides up the total NRC quantity corresponding to the MRC quantity and then distributes it across all contract years rather than placing…