Industry Feedback for Draft RFP Release_4 MAR 2026.pdf

# Comment Answer to Industry

Section 3.6.26 in PWS references "new AS" three times in its requirements. We understand that to preclude a retrofit or upgrade of existing P5 pods. If so, we recommend that clarification to be added to the PWS.

The PWS will be updated to remove references to "new AS" as part of the draft RFP release. The IDIQ PWS, Appendix B, defines the legacy TCTS II system to distinguish from the system requirements included in this solicitation. Retrofit kits are not an acceptable approach.

The PWS states the TCTS II system requires a CDS (section 3.6.42.1) and the CDS shall meet all applicable security requirements as defined by the NCDSMO

(3.6.42.2/3/4/5/6). We assume these PWS requirements are applicable to both the GS

CDS and AS CDS as defined in SPS requirement TCTS-SS-732. Is that the correct assumption?

Yes, this is a correct assumption. The PWS was updated to clarify CDS requirements as it relates to the AS and GS.

3.6.42.6 in the PWS calls out an RTB document that is not in the references section.

Recommend adding it to the references PWS Table 2.1.1-1 was to clarify RtB reference documents.

Getting approval prior to trips and generating a trip report (PWS section 3.14.1) is unnecessary as there will be a clear WBS element accounting for all costs associated with travel. This could also introduce unwanted delays and unnecessary costs in program execution. Recommend removing this requirement.

The requirement to receive approval prior to trips and and generate a trip report remains a requirement.

The static code analysis of all third-party software (PWS section 3.9.1.10) would be extensive for this program and likely cost prohibitive. Recommend removing this requirement

The PWS was updated to clarify static code analysis requirements.

6 Will any part of the RFP documentation or response to the RFP need to be classified?

Yes, see Section L for instructions with respect to submitting classified proposal information.

Our assumption of requirement TCTS-DLT-959 referred to in section 3.1.3 in the SPS is that both waveforms are hosted at the same time. Is this assumption correct? If so, we recommend adding "simultaneous" to this requirement. This will enable a growth path to future platforms.

The Government has reviewed this recommendation and does not intend to change the TCTS-DLT-959.

Recommend adding TCTS-DLT-1111 back into the SPS (section 3.1.3.5) to be consistent with the current configuration.

The Government has reviewed this recommendation and has determined

TCTS-DLT-1111 is redundant. The Government does not intend to modify the SPS.

Recommend correcting reference in 1.3 of Draft SPS to say 'Cross Domain Solution' vs

'Cross Domain System'.

The Government has reviewed this recommendation. Please see the updated documents that are part of the Draft RFP release.

New pods is what is required is retrofit kit unacceptable: Would an upgrade kit applied to USG TCTS/P5 pods be an acceptable offering so long as all requirements in the PWS and SPS are met?

Retrofit kits are not an acceptable approach.

MRL components at 9 acceptable: We assume threshold MRL requirements (PWS

3.8.16.2, 3.6.32.2) apply to WRAs, versus the new integrated subsystems already having entered low rate initial production. Can you confirm this approach would be compliant?

No, the MRL assessment includes the integrated subsystems, not just WRAs.

DO1 reflects CDRL delivery requirements for CDRL A057.

GFE / GFP / GFI available for use: Can the government confirm all GFE/GFP/GFI they will make available in performance of this contract.

The Government will confirm all GFE/GFP/GFI in the Draft RFP release.

Interoperability: The notional CONOP image in the PWS depicts no airborne links between TCTS II and TCTS I / P5 CTS participants. However, the TCTS II OV-1 in the SPS depicts airborne links between F/A-18 and JSF participants. Since JSF today is only equipped with a P5 training datalink, can we assume there is an objective requirement for simultaneous operation of an additional P5 compatible waveform in the datalink?

The TCTS II OV-1 in the PWS indicates a notional future state, not to be inferred as current requirements.

Interoperability: SPS 3.1.3(b) requires datalink capability for at least one waveform in addition to BMW. Can the government share particular waveforms of interest?

Please see SPS Sect 6.1.81 for additional waveform requirements.

Schedule: Can the government provide guidance on desired site activation, hardware delivery schedule requirements, and quantities?

The draft RFP includes additional generic information on desired site activation requirements and notional subsystem quantities. Specific requirements will be determined at the delivery order level.

BACKGROUND (PWS 1.3; Para 3): The paragraph references the LVC Capabilities

Requirements Document v.2. Is the Government able to release this document to industry as part of the solicitation?

No, the Government will not provide LVC Capabilities Requirements

Document v.2. The TCTS II LVC requirements are captured in the draft RFP's

PWS and SPS.

System Integration and Interoperability (PWS 3.6.26): The requirements outlined in the

PWS suggest that the USG intends to achieve signal-in-space compatibility with legacy

TCTSII subsystems, including alignment on message protocols, waveforms, and cryptographic elements. Meeting these objectives would necessitate full access to the legacy TCTSII Technical Data Package and significant non-recurring engineering efforts to ensure compliance. These implications appear to conflict with the stated expectation for a mature, SRL 7+ system at Milestone C. We respectfully request clarification on the

USG’s priorities regarding interoperability versus system maturity, as well as the degree of openness to alternative approaches such as ground-based interoperability solutions.

The Government cannot comment on the acceptability of an offeror's approach and requirements are clearly stated in the PWS and SPS. The

Government encourages offerors to evaluate the totality of the requirements as written.

New AS, GS and RRU (PWS 3.6.26.1.2): References are made to “new" AS, GS, and RRUs.

Could the USG clarify whether “new” is intended to mean entirely new subsystems or simply new relative to legacy configurations? Additionally, would the USG consider solutions that achieve interoperability through retrofit kits, recapitalizing existing government assets, provided these approaches meet performance and security requirements?

The PWS will be updated to remove references to "new AS" as part of the draft RFP release. The IDIQ PWS, Appendix B, defines the legacy TCTS II system to distinguish from the system requirements included in this solicitation. Retrofit kits are not an acceptable approach.

N/A: (PWS 3.8.7.2.2) Please advise if the System Architecture Model (SAM) is required to be an executable model. If no, the SAM is only intended to capture design, please advise if existing, alternative design artifacts are acceptable in lieu of a SAM.

PWS 3.8.7.2.2 and CDRL A015 defines the file format requirements. The draft RFP includes CDRL A015 for additional reference.

N/A: (PWS 3.8.21.1) Please describe the Software items that comprise "TCTS II software

Version 2.0.1" ? Is it limited to only the datalink software elements?

The software description is found in Sect J, Attachment (15), Software

Version Description Revision T (v2.0.2).

Government provided BMW software (PWS 3.8.22.1): The statement appears to indicate that the Government will provide executables to integrate on the vendor's datalink(s).

Will the legacy TCTSII Technical Data Package be released prior to the final RFP solicitation?

The Government plans to release non-proprietary technical data for the legacy system from the WRA level and higher as part the RFP release.

Cryptography Key Management (PWS 3.8.27): The PWS references FIPS-140-2, but the

System Performance Specification V5.0 does not appear to include a corresponding requirement for FIPS encryption. Could the USG clarify whether FIPS-140-2 compliance is required, and if so, where this is specified? Consistency between documents will help ensure accurate and compliant proposals.

The SPS has been updated to reflect the FIPS-140-2 (or greater) requirement.

Formal Training Course Development (PWS 3.10.9.3): Is there a specific SCORM authoring tool that the USG prefers or requires for training content development?

Guidance on preferred tools will help ensure compatibility and streamline the development process.

No, there is not a specific SCORM authoring tool. The PWS reflects SCORM compliance requirements. The Government cannot comment on the acceptability of an Offeror's approach. The Government encourages

Offerors to evaluate the totality of the requirements as written.

N/A (PWS 3.10.18.3): The statement references that the FTSR should hold a minimum of

SECRET security clearance however the system is design to operate on TOP SECRET data.

Please advise on the contradiction.

The FTSR security clearance minimum requirement is correct.

(SPS, no section reference) It appears that the current documentation does not include specific requirements or general specifications for the Data Recording Device (DRD). Are

DRDs intended to be deliverable items under this contract? If so, will the USG provide more detailed requirements to enable industry to accurately scope and propose compliant DRD solutions?

DRD drawings provided as Sect J, Attachment (14).

System Architecture (SPS 1.3, para 3): The paragraph references an AS CDS in the form of a “will” statement. Generally, “will” statements typically indicate Government actions or intentions, not contractor requirements. Is the inclusion of an AS CDS intended as a firm requirement in this case? If so, could the USG provide the associated CONOPs or operational scenarios that necessitate CDS functions within the pod?

In addition to SPS 1.3, para 3, see additional CDS requirements TCTS-SS-732 and TCTS-SS-1101 which require the airborne subsystem to have a cross domain solution. The Government is unable to provide associated CONOPS and/or use cases due to classification.

System Architecture (SPS 1.3, para 3): The paragraph references an AS CDS. Could the

USG specify how many security channels are required for the AS CDS?

SPS 3.1.3.4.b, requirement TCTS-E-306 requires four channels.

Software Systems Architecture (SPS 3.1.2.1, TCTS-I-1056): Can the USG verify that any existing baselined reuse software incorporated into the TCTSII solution will be exempt from the FACE requirement, and that only new software developed under this contract will be subject to it?

PWS 3.6.27.1 and SPS 3.1.2.1 para (a) have been modified to reflect FACE requirements pertain to new or modified software.

Software Systems Architecture (SPS 3.1.2.1, TCTS-I-1058): The requirement specifies compliance with FACE Safety Base or FACE Safety Extended OSS profiles. For a training system that is not safety-critical, mandating these profiles imposes constraints intended for higher-criticality systems, significantly limiting the solution set to a narrow range of real-time operating systems. This approach appears misaligned with the system’s intended use and current trends in advanced sensor subsystems, which commonly employ secure Linux-based operating environments. Could the USG clarify whether the intent is to restrict solutions exclusively to RTOS platforms, or if there is flexibility to consider alternative operating systems that meet the required security posture without unnecessary complexity?

The Government affirms SPS 3.1.2.1, TCTS-I-1058, requirement is accurate.

The OSS must conform to FACE Safety Base or FACE Safety Extended OSS profiles, which requires RTOS platforms.

Datalink Range and Connectivity (SPS 3.1.3.7, TCTS-DLT-353): This requirement from the

TCTSII SPS V3.2 was removed. Is there a new link quality objective for the relay function?

The Government determined TCTS-DLT-353 was duplicative of TCTS-KPP-

214, TCTS-215, and TCTS-DLT-17.

Datalink Range and Connectivity (SPS 3.1.3.7, TCTS-DLT-66/1038): These requirements from TCTSII SPS V3.2 were removed. It is recommend reintroducing them as “will” statements. Recent SITL LVC events have demonstrated that this real-time diagnostic function provides significant value to mission operators.

The Government has reviewed this recommendation and does not intend to change requirements. Please see the Draft RFP Release.

Transmission Latency (SPS 3.1.3.9, TCTS-DLT-359): The latency requirement as currently specified does not support accurate weapon simulation results necessary to preserve mission timelines and outcomes in SITL LVC operations. Based on results of extensive field testing, overly tight or misaligned latency thresholds can compromise simulation fidelity and training effectiveness. Would the USG consider adopting a requirement aligned with the IEEE 1278.2 benchmark of 100 ms with sufficient margin to account for range infrastructure, aircraft data bus latency, and other real-world integration factors?

This approach ensures high-fidelity weapon simulation while maintaining interoperability across distributed training environments.

TCTS-DLT-359 reflects latency no greater than 130 ms. The Government does not intend to change requirements.

GPS-Denied Requirements (SPS 3.1.4.2): The GPS Denied requirements allude to a specific design solution in order to ensure compatibility with legacy TCTSII system. Can the USG confirm that GPS-denied design artifacts are provided for the vendor to implement a compatible soluton?

The Government does not require a specific design solution. The

Government will provide Tactical Combat Training System Increment II TCTS

Inc II System/Subsystem Design Description (SSDD), SSDD-946-1KN3-

001_REVD, as part of the technical library in the final RFP release.

TSPI Capabilities (SPS 3.1.4.3, TCTS-TSPI-3): Is the minimum TSPI rate of 20 Hz specified to support test CONOPS for the system, or is it intended solely for training operations?

For training, a 10 Hz rate is typically sufficient to meet tracking fidelity requirements.

The Government does not intend to change the 20 Hz requirement.

Weapon Simulations (SPS 3.1.5.1, TCTS-SIM-319): This requirement appears to reference

Table 2 and Table 3, but these references may be incorrect or misplaced. Could the USG verify these citations?

The SPS has been updated.

Electronic Combat Environment (SPS 3.1.5.2, TCTS-SIM-1105): This requirement only seems to address the F/A-18E/F platform. Are there plans to perform Level 2 (Digital) or

Level 3 (LVC) integration with other required platforms such as the F-15?

The SPS reflects current platform interface requirements. Development of any future aircraft interfaces may be addressed in a separate contract, future delivery order, and/or contract modification.

Next Generation Threat System Interface (SPS 3.1.5.4, TCTS-SIM-1108): The requirement cites ICD-F/A-18-188 Rev D. Would the USG be able to furnish this document to industry participants? Access to this reference will enable a more thorough evaluation of solution compatibility and ensure alignment with the intended interface standards.

The ICDs are provided as Sect J, Attachment (13).

Environmental Conditions (SPS 3.1.6, TCTS-EV-60): This requirement appears to make an erroneous reference to Table 5. Please advise.

The reference to Table 5 in SPS 3.1.6 is correct.

Environmental Conditions (SPS 3.1.6, Table 2): The table references both ruggedized and non-ruggedized PSES components. Could the USG clarify which specific PSES components are required to be ruggedized?

PSES ruggedized requirements will be clarified in the SPS for the final RFP release.

Environmental Conditions (SPS 3.1.6, Table 2): The current documentation does not specify environmental requirements for the F-15 aircraft, such as vibration profiles.

Could the USG clarify whether F-15 specific environmental requirements will be provided?

The vibration profiles for the F-16 and the buffet motion profiles for the F-

18 E/F are worst-case scenarios thereby ensuring meeting the spec for other aircraft.

Environmental Conditions (3.1.6, Table 2): A Ship Operational Vibration profile was added for the RRU. Could the USG clarify the intended installation plan for naval vessels, and whether ship-board operational requirements also apply to ground stations?

Ship-board operational requirement for the RRU will be removed from the

SPS for the final RFP release.

Security (SPS 3.1.10, TCTS-SS-2): The SPS references an RMF categorization of High-High-

High, which is typically reserved for systems with the highest security sensitivity. Is this designation intended for the training system, or should the appropriate RMF categorization be formally determined during contract initiation (i.e. RMF Step 1)?

Applying a High-High-High categorization may drive excessive security controls and increase cost and complexity beyond what is necessary for mission requirements. For similar SITL LVC training systems, lower categorizations have proven sufficient. Can the

Government provide additional insight into the rationale for this designation and confirm whether it is required for this program? It is noted that TCTS-SS-1 was removed from

TCTSII SPS V3.2 however this requirement remains.

SPS sections 3.1.10.c, 3.1.10.d and Table 12 will be updated and included in the Final RFP release.

Airborne Subsystem Specific Requirements (SPS 4.3.2): There is a reference to aircraft

“C” in the documentation. Could the USG clarify which specific aircraft is intended by this designation?

SPS 4.3.2 will be updated to remove the referenced error and is reflected in the Final RFP release.

Aircraft Supported (SPS 4.3.2.4): The list of required aircraft for flight testing in Section

4.3.2.4 does not align with the aircraft identified in Section 4.3.2. Could the USG clarify which aircraft are required for flight testing and resolve any discrepancies between these sections?

SPS 4.3.2 and 4.3.2.4 will be updated as required to clarify aircraft flight testing requirements and will be reflected in the Final RFP release.

(SPS, General) There are numerous “shall” statements in the documentation that do not have requirement IDs assigned, even though such statements are typically considered requirements in system specifications. Could the USG clarify whether these “shall” statements are intended to be binding requirements, and if so, provide or assign corresponding requirement IDs?

All tasking in the SPS is required tasking. The Government has confirmed that all requirements in Section 3 include a corresponding ID number in the

SPS. Shall statements in section 4 are test / verification methods, not an SPS requirement, and do not require IDs.

(PWS/SPS General) The current specification and PWS do not address requirements for supporting airworthiness certification, Air Traffic Control (ATC) compliance, or Authority to Operate (ATO). Could the USG clarify whether these activities are expected as part of this contract, and if so, provide guidance on scope and applicable standards?

There are no support requirements for functions that are inherently governmental. The PWS and SPS reflect requirements and deliverables necessary to support these functions.

Electrical Power (SPS 3.1.8, TCTS-P-1077) : Could the USG confirm the availability of

28VDC power on all listed aircraft and specify which weapon stations will provide this power?

SPS 3.1.8 power requirements are accurate as written. Electrical power requirements are agnostic to the weapon station utilized.

Security (SPS 3.1.10, item g): The requirement specifies TEMPEST Level 1 compliance for both the airborne pod and ground station. This level of protection is typically associated with systems handling highly sensitive information and will significantly impact cost, schedule, and design complexity for a training system. Previous training systems, such as

P5CTS, were subject to less stringent TEMPEST requirements. Could the USG clarify the rationale for mandating Level 1 compliance and confirm whether a Certified TEMPEST

Technical Authority (CTTA) evaluation will occur as part of this contract?

TCTS II TEMPEST requirements in the the SPS align with LVC roadmapped capabilities per the LVC CRD and the requisite classification level of data the

TCTS II system may process. SPS 4.3.3 defines the TEMPEST testing conditions and SPS 3.1.10 defines the TEMPEST requirements.

Security (SPS 3.1.10, TCTS-SS-1015): The specification requires the system to receive, transmit, process, and store data up to TOP SECRET. Could the USG clarify the associated use case for handling TS data, such as whether this is intended for tactical overlays, data aggregation, or other mission functions? There are significant implications to maintaining TS capability, including key management renewal cycles, physical protection requirements, and RMF security overlays. Understanding the operational need will help ensure the solution aligns with mission objectives without introducing unnecessary complexity.

The TCTS II System is required to support fully informed training & platforms. The Government does not intend to provide use cases since this is a production contract. Use cases have already been developed and are represented in the requirements.

NSA Approved Cryptography (SPS 3.1.10.1, TCTS-E-297): The updated requirement specifies that the ECU must use NSA-approved Suite A and Suite B encryption, whereas the previous version referenced compliance with CNSA Suite 2.0. This change appears to move away from the CNSA modernization path, which is intended to align with current cryptographic standards and future-proof systems against emerging threats. Could the

USG clarify the rationale for this shift? Is the intent to maintain compatibility with legacy systems, or will CNSA Suite 2.0 compliance be considered as an acceptable or preferred approach?

The Government affirms NSA approved cyrptography requirement is accurately reflected in SPS 3.1.10.1, TCTS-E-297 and SPS 6.1.41 as well as maintaining interoperability with the legacy TCTS II system. The

Government cannot comment on the acceptability of an Offeror's approach.

The Government encourages Offerors to evaluate the totality of the requirements as written.

(SPS, General) The acronyms “PS” and “AS” appear to be used interchangeably throughout the documentation. Can the USG confirm whether these terms refer to the same subsystem, or if they denote distinct system configurations?

The SPS has been updated. The Government intends to distinguish

Participant Subsystem (PS) variants; the airborne pod nomenclature is

Airborne Subsystem (AS).

Encryption (SPS 3.1.10.1, TCTS-E-918, TCTS-E-722): The requirement specifies that all recorded classified and unclassified data must be secured using NSA-approved cryptography. This approach suggests a CONOPS where removable media containing encrypted data is treated as unclassified CCI, rather than classified material. However, other systems achieve compliance using FIPS-validated solutions, with removable media still handled under standard OPSEC procedures for classified data. Could the USG clarify the operational justification for mandating NSA-approved cryptography in this context?

Is the intent driven by a specific CONOPS requirement, or is there flexibility to consider alternative approaches that meet security objectives without imposing excessive cost and complexity?

The USG rationale is to mitigate additional risks to maintain classified data by using the NSA approach of AES encryption for Secret and FIPS-140 for unclassified per CNSS Policy 7 and CNSS Policy 11 for CONUS and OCONUS operations.

Airborne Subsystem Interface and Control (SPS 3.2.7, TCTS-I-362): The current requirement specifies support for MIL-STD-1553B operation modes, including Bus

Monitor and Remote Terminal, while Bus Controller has been removed. We are concerned that retaining Bus Monitor capability introduces potential security vulnerabilities, particularly given prior guidance from airworthiness stakeholders indicating a preference for Remote Terminal-only configurations. Could the USG clarify the operational need for Bus Monitor functionality in this training system? Is this requirement driven by a specific mission scenario, or is there flexibility to align with a more secure RT-only approach?

The Government has reviewed this recommendation and does not intend to change TCTS-DLT-362. Removing this requirement may limit solutions to future capabilities and customer's needs.

TCTS Inc II Verification Cross Reference Matrix (SPS Table 9, Item 3.1.6e): The verification table indicates that requirement TCTS-UI-1026, which encompasses all environmental requirements, is scheduled to be verified at the contractor facility, during government testing, and again during system testing with LRIP production assets. This appears excessive and may be unintended. Could the USG confirm whether the intent is to conduct full environmental testing across all three phases, or if this is a documentation error?

The environmental testing conducted in DT-B1 will not be repeated during

DT-B2 and DT-C1. DT-B1 includes all contractor testing required to demonstrate hardware is capable of meeting environmental conditions defined in the SPS. Final verification that the system meets performance requirements under actual environmental conditions will be conducted during Government testing (DT-B2 and DT-C1) on representative aircraft and ranges. The delivery order will define contractor requirements for supporting Government testing during DT-B2 and DT-C1.

Electromagnetic Envrionmental Effects (SPS 4.3.1.7): The paragraph references F-35 EMI testing. Is this reference to the F-35 intentional, or was it included in error?

SPS 4.3.1.7 will be updated and reflected in the Draft RFP release.

Live Monitor Display and Control Functions (SPS 3.3.3.1, TCTS-GS-424): The specification requires the system to publish and subscribe to both DIS and TENA data and interface with multiple TENA-based systems. Could the USG clarify the rationale for mandating support for multiple protocols when government-owned data brokers such as LMOC

TENA Gateway and JBUS already exist to facilitate interoperability? Leveraging these brokers could reduce integration complexity, minimize interoperability risk, and align with NIS standards. Is there flexibility to rely on these existing solutions rather than implementing full native support for multiple protocols?

The Government has reviewed this recommendation and does not intend to change the SPS.

(SPS, Genral) Could the USG provide the operational use cases or CONOPS artifacts that drive these requirements? Clarity on key concepts such as Multiple Independent Levels of Security (MILS), rangeless versus range-based architectures, representative training scenarios like Counter-Air, and coalition or joint interoperability would help ensure proposed solutions align with mission objectives without unnecessary complexity.

The Government will not disclose any use cases or CONOPS.

58 How will the government evaluate offerors delivering in less than 24 months? Evaluation factors are included in Sections L & M.

Can the government confirm that a delivery order for hardware will be placed at the beginning of the program award?

The Government intends to award Delivery Order 0001 alongside the IDIQ

Contract Award. Please see the Draft RFP release for further information with respect to Delivery Order 0001.

We recommend in Section C that Tactical Guard & Ground Guard Drawer should be added under CLIN 0001, CLIN 0002 & CLIN 0005 to be shipped separately per NCDSMO requirements.

NCDSMO shipping requirements are included in PWS Sect 3.6.48.1, reference NCDSMO-R-00010-001_00. Sect B and Sect L directs this requirement to be included, as applicable, in hardware CLIN 0001, CLIN

0002 and CLIN 0005. To comply with NCDSMO policy, shipping addresses will be included at the delivery order level.

How should industry factor the Value Engineering Change Proposals (VECPs) into the offering and how will it be factored into the total evaluated price?

Please see FAR 52.248-1 Value Engineering, which is a Contract Clause not an evaluation criterion and is not factored into total evaluated price. Section

L&M specifies the evaluation factors and is included in the Draft RFP release.

62 What budget line item will be utilized to qualify a proposed system to the PWS/SPS?

The Government intends to award Delivery Order 0001 alongside the IDIQ

Contract Award. Please see the Draft RFP release for further information with respect to Delivery Order 0001.

In Section B Table B.1, procuring a single Airborne Subsystem (AS) will factor in a minimum order quantity across several supplier furnished components, which makes the price of a single AS uneconomical. We recommend the government specify the minimum order quantity of 10.

The Government has reviewed this recommendation and does not intend to change requirements. Attachment L-3 identifies quantity ranges.

In Section F, page 11, the Period of Performance (POP) is listed from 25 Sep 2026 to 25

Sep 2030 (4 years). In Section H, page 16, the ordering period is 5 years after date of contract award. Can the government explain the difference between the ordering period and POP?

The Ordering Period is the time period during which orders can be placed against the Basic IDIQ Contract; this will be 5 years after IDIQ award. Each issued Delivery/Task Order will have a Period of Performance and/or

Delivery Date which will describe when products are services are to be delivered/performed. Section F of the IDIQ has been corrected to clarify this distinction.

For Section C, CLIN 0011 and 0012 can the government provide additional clarity on the purpose of having ICS and depot support services in separate CLINs?

The CLIN separation in Section C is based on differing scopes of work in the

PWS.

For Section C, CLIN 0012, will industry be providing depot support services at a government owned depot?

The Government intends to award depot services from a competitively awarded future contract for long-term sustainment of the TCTS II system. If the subsytems delivered under this IDIQ require ICS or depot services while the commerical depot is being established, this contract vehicle may be used. There will be no Government-owned depot facility. The Government will not provide space for depot work as part of CLIN 0012.

For Section C, CLIN 0012 does the government intend to flow all TCTS II depot repair/replacement work through this contract vehicle?

Depot level support for the legacy TCTS II is not in scope for this contract vehicle. CLINs 0011 or 0012 is established should the Government require

ICS or depot support services while the long-term depot sustainment contract is pursued.

Section D, page 9 describes foreign military sales (FMS requirements, are there any FMS requirements for this effort?

There are no planned FMS requirements, please see the Draft RFP Release for updated Section D language.