GDS JPO JIBM RFWP QAs_FINAL.pdf

No. SOO Section Ref Question Response Category

Could the Government confirm whether landscape orientation is permitted for tables, graphics, or charts included in the White Paper submission?

Yes. Landscape orientation is permitted.

White paper format

Could the Government specify if there is a required or preferred font type (e.g., Times New Roman or Arial Family) for the White Paper?

No preference.

White paper format

3 What is the anticipated ceiling cost for this project?

The Government does not have an anticipated ceiling cost. Vendors should earnestly provide a ROM commisurate with the level of effort in their solution.

Ceiling

Will the Government provide an estimated level of effort, including recommended labor categories and suggested labor hours, to support ROM development?

The Government does not have a recommended level of effort. We are looking for industry to tell us what they can do to accomplish the objectives in the SOO.

IGCE

Is the prototype expected to operate within a specific security enclave (e.g., IL5, IL6, IL7)? Are there hosting environment constraints we should consider?

IL5 and IL6. Hosting preference for a certified cloud platform that facilitates an iATT.

Host platform

What specific cybersecurity compliance benchmarks (e.g., RMF steps, ATO timelines) are expected prior to exercise and delivery?

Static scans expected frequently during development;

Support the iATT process prior to the joint exercise.

ATO

What specific data formats and communication protocols are expected for integration between JIBM and AGS, IBCS, C2BMC, and TOC-L systems?

Primary interface is Joint Track Management Capability (JTMC) bridge. If there are specific gaps in the data provided via the JTMC bridge, the component system C2 interfaces can be used as needed. Details including ICDs for these interfaces to be provided after contract award.

Data and Protocols

Are there any preferred or mandated programming languages, frameworks, or architectural styles (e.g., microservices, containerization) for the prototype?

Open to any approaches that maximize flexibility, scalability, openness, and modularity.

Framework

GDS JPO JIBM RFWP Q&As

Will the Government provide access to a Government-owned DevSecOps (DSO) platform, or must offerors provision their own?

The government is still evaluating the preferred government-owned DSO platform. Offerors can recommend their own platform in their response, but those that are already hosted on a government-owned platform, or that could easily migrate to a govenment-owned platform are preferred. DSO

Can you elaborate on the quantitative or qualitative metrics that will be used to evaluate “prototype functionality” during the 3QFY26 joint exercise?

The Government does not have any pre-determined metrics that will be used during the joint exercise. Prototype eval

For any COTS tools used in development, will the Government expect transfer of perpetual licenses, or is term-based licensing acceptable?

Term-based licensing is acceptable SW Licenses

What documentation must be submitted to prove NDC eligibility under 10 U.S.C. § 4022(d)(1)? Are letters of commitment required?

The Government can verify NDC status. Vendors should submit their representation and identify NDC participants and the NDC's participation/role/contribution to the project. 10 U.S.C. § 4022

Are hyperlinks, embedded prototype video links, or other media allowed within the White Paper submission?

No White paper format

In Order to Meet the Requirements of 10 U.S.C. § 4022(d)(1), does Point no "(2) All significant participants in the transaction other than the Federal Government are small businesses (including small businesses participating in a program described under Section 9 of the Small Business Act (15 U.S.C. § 638) or nontraditional defense contractors" will suffice the requirements for small business firm who are not proposinf any subcontractor or teaming partner for this effort"

Yes, one way to meet the 10 USC 4022(d) requirements is for all non-government participants to be small businesses or NDCs.

10 U.S.C. § 4022

Does the Government require Offerors to align labor hours and/or periods of performance explicitly to each proposed milestone in the detailed schedule, or is it acceptable to present labor hours and cost by PWS task or WBS element, with milestone payments tied to high-level deliverables and technical events?

Labor hours and cost can be presented by PWS task or WBS element with milestone payments tied to high-level delvierables and technical events.

But to be clear, a milestone payment schedule is not required for a WP submission. A milestone payment schedule is only required if a vendor is invited to provide a full proposal. Cost estimate

Can the Government clarify what level of detail is expected for “detailed cost elements” under the price breakout?

A detailing of cost elements is not required for WP submission. Only vendors invited to submit a full proposal will be required to provide this level of detail. Cost estimate

What specifically is meant by “Milestone Payment Schedule”? Should milestones be tied to deliverables, technical events, or calendar dates, and what level of detail is expected?

A milestone payment schedule is not required for WP submission. Only vendors invited to submit a full proposal will be required to provide a milestone payment schedule. Milestone payments

Per the instructions to "provide a rough order of magnitude (ROM) using the Government provided WBS," could the Government clarify the availability, structure, and format of the WBS referenced?

The WBS structure in the SOO can be used as a guide and more detail or additional levels can be constructed if a vendor chooses to do so. Gov WBS

Under the Qualification and Experience section, the instruction is to “identify team member role assignments and each team member’s qualifications and experiences in comparison to the respective SOO performance requirement(s).” Could the Government clarify whether this refers specifically to named proposed personnel (e.g., subcontractor/partner individuals), or to labor category (LCAT) qualifications in general?

Vendor's should identify any other performers (e.g.

subcontractors) and their qualifications at the subcontractor level, not individual personnel level.

Qualifications and Experience

Could the Government provide a detailed architectural diagram or system-level topology of the existing GDS Command and Control (C2) ecosystem? Specifically, please include information on network segmentation, data flow paths, latency constraints, and inter-system dependencies.

This diagram does not exist at the CUI level. Architecture

Is there currently a centralized data lake, fusion node, or similar construct aggregating sensor, threat, and engagement data within the GDS ecosystem?

Alternatively, will the JIBM prototype be expected to independently perform data fusion functions?

JIBM prototype is expected to perform data fusion across C2 nodes and implement a data layer to support that function. Data layer

What cloud platforms (if any) are currently in use within the GDS operational environment (e.g., AWS GovCloud, Microsoft Azure IL6, or on-premise DoD-authorized data centers)? Are there hosting preferences or constraints Offerors should be aware of?

Not any currently in use. Hosting preference is for a certified cloud platform that facilitates both an iATT and future migration to government owned IL5 and IL6 environement(s). Host platform

For each integrated system—such as IBCS, AGS, THAAD, C2BMC, and TOC-L—could the Government provide information on the currently fielded or planned version and configuration baseline expected by FY26? This information cannot be provided at this time. This information will be provided after contract award.

Component system versions

Are there existing middleware solutions, data abstraction layers, or service buses used to interface with legacy or third-party systems that JIBM is expected to leverage for integration?

Primary interface is Joint Track Management Capability (JTMC) bridge. If there are specific gaps in the data provided via the JTMC bridge, the component system C2 interfaces can be used as needed. Details including ICDs for these interfaces to be provided after contract award. Data and Protocols

Will the Government provide Interface Control Documents (ICDs), Application Programming Interfaces (APIs), or technical interface specifications for the systems JIBM is expected to integrate with, including IBCS, AGS, TOC-L, THAAD, and C2BMC? Documentation for interfaces will be provided after contract award. Interfaces

Are any of the current C2 systems utilizing a rules engine, automated decision support logic, or Course of Action (COA) optimization framework that JIBM could potentially leverage or extend?

Each component system has its own decision logic; JIBM is expected to provide a layer of decision logic above the component systems. JIBM logic

Will the Government provide a baseline Authority to Operate (ATO) package (e.g., existing RMF artifacts or categorization data), or must Offerors plan to build the ATO package from the ground up?

Offerors are expected to build the ATO package, but in coordination with the Government. ATO

Will a Government-furnished testbed, simulation environment, or joint test facility (e.g., Joint National Training Capability [JNTC], modeling and simulation tools, virtual ranges) be made available to support validation and testing of the JIBM prototype? Yes. Test environment

29 Section 1, 3

Can the Government expand on the included threat set. Our assumption is that they include ballistic missiles, hypersonics, cruise missiles, and unmanned aerial systems. Are there other threats in the threat set?

The JIBM is indeed envisioned to address a range of threats, including those mentioned: ballistic missiles, Maneuvering re-entry vehicles (MaRVs), Hypersonic Glide Vehicles (HGVs), supersonic and subsonic cruise missiles, and potentially unmanned aerial systems (UAS).

However, the full scope and details of the threat set, including specific performance characteristics and quantities, will be delineated to offerors selected to submit proposals. This detailed information will ensure all proposers have a common and consistent understanding of the JIBM requirements.

It's also important to recognize that the threat landscape is constantly evolving. The JIBM architecture should, therefore, be designed with adaptability and scalability in mind to accommodate future threats. Offerors are encouraged to address this aspect in their white papers by demonstrating how their proposed solutions can adapt to evolving threat profiles and incorporate new threat information as it becomes available. Threat set

30 Section 3 Will the Government clarify on which network the

Joint Exercise will take place? Will it be conducted on NIPRNET, SIPRNET, or another network?

The Joint Exercise for the JIBM prototype demonstration is expected to be conducted at the Collateral SECRET level.

The specific network infrastructure (e.g., SIPRNet, JWICS, or a dedicated network enclave) will be determined and communicated to selected offerors after award. Offerors should design their proposed solutions with the flexibility to accommodate operation on various secure government networks at the Collateral SECRET level.

Joint exercise network

31 Section 3

Will the government provide detailed information on the expected timeline for the award in 1QFY26 and the Joint Exercise 3QFY26. Specifically, how does the government plan to address the potential 3-month period between the award and the Joint Exercise if you assume a late award in 1QFY26 and an early, already scheduled, Joint exercise in 3QFY26?

Award expected 4QFY25 and the joint exercise is mid-late 3QFY26 . Plan for roughly 8 months between award and the exercise.

Schedule

32 Section 3

Can the government be more specific about what they mean by "experimentation activities"? What are the "experimentation" objectives? Are there specific activities expected or planned to support "experimentation" objectives?

Experimentation activities would include demonstrating any functionality present to aid in joint battle management. Experimentation objectives align with JIBM objectives outlined in the SOO. Objectives

33 Section 3, 4.2 Can the government differentiate between the 4.1 functionality that must be available for the exercise vice final delivery, since development may continue into

4QFY26 ?

Expectation is for vendors to bring their most mature product to the joint excercise and continue to mature that product into 4QFY26. Expectations will be based on what the vendor brings as a starting point. Final delivery

34 Section 4.4 Will the Government clarify their expectations related to a certified DSO platform to support the prototype development?

A certified DSO platform is one that allows software leaving the DSO pipeline to have the security rigor behind it so that it can maintain a continous ATO. Certified DSO

35 Section 4.5 Does the government require a certified DSO for IL5, IL6, and above in cloud native environments and at the tactical edge during the prototype development?

Required, no. Hosting preference for a certified cloud platform that facilitates an iATT. Host platform

36 Section 4.5

Does the Government expect the provider to obtain an ATO as part of the prototype development to deploy on the designated network for the Joint Exercise? Considering the timeline, will the Government mitigate schedule risks associated with obtaining an ATO by streamlining the accreditation process through the accreditation authority? Expectation is to obtain an iATT for the joint exercise. ATO

37 Section 5.2 Will the Government provide clarification on the extent of the MBSE models included in the Detailed Design Documentation and what version of Cameo should be utilized?

Design should be sufficiently captured in the model to communicate to all engineering stakeholders.

CAMEO 2024x should be utilized and migration to future versions may be necessary. MBSE

38 Section 4 Will there be any GFI provided (interface/message formats, test datasets, etc.) to support software development and testing?

Documentation for interfaces will be provided after contract award. Interfaces

39 Section 1, 3

Will the government provide detailed level of JIBM functionality required for the initial integration into the Joint Exercise community. Is there a defined level of necessary JIBM functionality required for initial integration into the Joint Exercise or will there be an ‘on-line’ then ‘in-line’ process executed for JIBM integration into Joint Exercises.

Experimentation activities would include demonstrating any functionality present to aid in joint battle management. Experimentation objectives align with JIBM objectives outlined in the SOO. Objectives

40 Section 3.4 What is the Government’s desired data rights for the JIBM prototype? Unlimited or government purpose. Data rights

41 Section 5.1

Could the government specify which AI detection tools will be used during evaluation. Additionally, considering the potential for false positives with available tools, how does the government plan to address and mitigate risks associated with incorrectly identifying human-written content as AI-generated?

The Government will not identify which AI detection tool(s) it may employ. If the Government identifies concerns regarding what would otherwise appear to be AI-generated content, the Government may engage with the vendor for clarification on content.

AI detection

Will the Government allow development of a prototype in a contractor owned environment and transition to government environment upon delivery or will all development be required in government environment to be provided? Yes Contractor DSO

Would the Government consider a CPFF type agreement that include milestones because of the unknown requirements that create increased risk?

No CPFF

44 Section 4.3

The SOO at section 4.3 requires "a hardware-agnostic architecture to ensure maximum portability and deployability across a range of hardware host platforms."

Will the Government provide the selected Offoror with one or more HW environments and any unique specifications as GFE/GFI as part of the prototype development effort -both for developmental test as well as support to the JIBM capability exercise in 3QFY26 as part of a joint exercise?

If not provided as GFE, will the Government provide the selected Offeror with the specifications of the HW to be leveraged in the joint exercise prior to OTA award?

No GFE provided. The government will provide target hardware specs for the joint exercise after award. Target hardware

45 Section 3

In Section 3 of the SOO, the Government specifies that the prototype JIBM must support the following timeline objective: "Prototype JIBM capability exercise in 3QFY26 as part of a joint exercise" with specified functionality.

Please clarify whether the selected Offeror is intended to support the capability exercise on-site with their prototype JIBM and, if yes, the name and location of the capability exercise.

The offeror is planned to support the capability exercise on-site. Exercise name and location to be provided after award. For planning purposes, expect OCONUS.

46 Section 4 Does the Government intend to provide the downselected Offeror(s) with Government Furnished Information (GFI) (or identify the set of GFI to be provided) as part of the proposal process, e.g., ICD information. No GFI will be provided as part of the proposal process. GFI

47 Section 4 Does the Government intend to provide the downselected Offeror(s) with with validated representations of the required JBIM prototype interfaces, or access to a validated Software/Hardware In the Loop environment? No Interfaces

48 Section 3.4.3

The Request for White Papers at Section 3.4.3 provides:

"Provide a rough order of magnitude (ROM) using the Government provided WBS and any assumptions pertaining to price for how this concept could be achieved." Please confirm the SOO represents the "Government-provided WBS," or please provide the WBS the Government wants the Offeror to use.

The WBS structure in the SOO can be used as a guide and more detail or additional levels can be constructed if a vendor chooses to do so. Gov WBS

49 Section 3.4.3

Please confirm that Offerors are permitted to use a MIL STD 881F WBS structure for estimating the ROM per Section 3.4.3 tailored in accordance with the SOO requirements. Yes. Gov WBS

What exactly is being asked for with network management? Is the Govt seeking a new/novel solution for managing the actual comms network, or is the Govt seeking an ability to operate within the confines/limitations of an existing network?

Operate within the confines/limitations of existing network(s). Network

What types of information will be available in the Common IAMD XML Schema (CIXS) interface?

Commanders Intent, ATOs, ACOs, other?

Documentation for interfaces will be provided after contract award Interfaces

52 Section 4 Subsec C

Can the Government confirm that per 10 U.S.C. § 4022(d)(1), only one of the conditions set forth in 10 U.S.C. § 4022(d)(1) is required to be met, and not all three, in order to enter into a contract for a prototype project?

The language in Section 4, Subsection c. of the request for white paper reads as if all three scenarios need to be met in order to be eligible.

Yes, only one of the conditions must be met. If the prime will be a traditional defense contractor, we expect meaningful and significant participation by a non-traditional defense contractor. We may seek a cost share if it does not appear the work to be performed by a non-traditional defense contractor is significant. 10 U.S.C. § 4022

53 Section 3.1 Is CUI level of information permitted in the white paper? Yes. Vendors can request a SAFE drop-off from the POCs in the RFWP NLT 2 days prior to the closing date. Sensitivity level

54 Section 1.2 Can you add more definition to "defend against both ballistic and non-ballistic threats" Would you please clarify what is meant by non-ballistic threats.

The JIBM is indeed envisioned to address a range of threats, including those mentioned: ballistic missiles, Maneuvering re-entry vehicles (MaRVs), Hypersonic Glide Vehicles (HGVs), supersonic and subsonic cruise missiles, and potentially unmanned aerial systems (UAS).

However, the full scope and details of the threat set, including specific performance characteristics and quantities, will be delineated to offerors selected to submit proposals. This detailed information will ensure all proposers have a common and consistent understanding of the JIBM requirements.

It's also important to recognize that the threat landscape is constantly evolving. The JIBM architecture should, therefore, be designed with adaptability and scalability in mind to accommodate future threats. Offerors are encouraged to address this aspect in their white papers by demonstrating how their proposed solutions can adapt to evolving threat profiles and incorporate new threat information as it becomes available Threat set

Does the Aegis Weapon System (AWS) include ships as well as land-based Aegis?

For the purposes of the GDS JIBM prototype and its demonstration, the focus is specifically on land-based Aegis Guam System (AGS) or a Virtualized Aegis Weapon System (VAWS) representation of the AGS, not ship-based Aegis.

The decision to utilize a land-based or virtualized system for the demonstration will depend on availability and will be communicated to the selected offerors. However, it's important to emphasize that the JIBM prototype should be designed with the flexibility to interface with various Aegis configurations in the future, acknowledging the potential for integration with ship-based AWS as the GDS architecture evolves. Architecture

Does “dynamic re-planning” include changes to system configurations (especially for surveillance radars in the fire control loops and weapons doctrine) based on immediate intel? Yes Planner

Who is responsible for the Joint Integrated Defense Planner? Is it an existing tool or will it be developed alongside this effort?

The Joint Integrated Defense Planner is a government-owned product that is being prototyped alongside this JIBM Prototype effort. Planner

Are there any airborne surveillance platforms, either manned or unmanned, that are included?

While the GDS JIBM prototype is not currently planned to directly interface with airborne surveillance platforms, manned or unmanned, the architecture should be designed with future interoperability in mind. Other elements of the GDS may indeed interact with such platforms, and their data could potentially be valuable to the JIBM's overall situational awareness.

Therefore, while direct integration is not a requirement for the initial prototype demonstration, offerors are encouraged to describe in their white papers how their proposed JIBM solution could accommodate future integration with airborne surveillance platforms. This includes considerations for data formats, communication protocols, and data fusion techniques. Architecture

59 Section 1 Background lists ABAD or TOC-L and Section 4.1 External C2 Interfaces only lists TOC-L, is this just an oversight and ABAD or TOC-L should be in both places?

Yes, ABAD or TOC-L should be listed in both places. Architecture

60 Section 1 Does the Sponsor intend to perform Joint Interoperability Certiciation of the JIBM at some point?

Yes JITC

61 Section 3, 1 Will Sponsor or contractor define the experiment for the exercise and coordinate partition with the host?

The government will define the experiment for the exercise. Objectives

Will Sponsor provide GFE the other systems connecting to the JIBM for RRE before exercise participation and during the exercise? No Test environment

Will Sponsor or contractor coordinate system of systems IATO, IATC for the RRE and exercise?

Government will coordinate all necessary activities leading up to the exercise. Test environment

64 Section 3.2 Is some level of functionality relative to each of the capabilities described in Section 4.1 required in the initial prototype?

Demonstrated functionality across all capabilities described in Section 4.1 is desired. Demonstrated functionality to meet the objectives in Section 3.1.a-c is required. Objectives

65 Section 3.1a,b,c Are each of these three capabilities demonstrating functionality and interfaces from across Section 4.1?

The three capabilities in Section 3.1a,b,c demonstrate the following functionality from Section 4.1: Joint Battle Management, Joint Warfighter Interface, External C2 Interfaces. Objectives

66 Section 3.1.a Are there requirements for the COP that are distinct from the CTP requirements of the PoRs (e.g., number of tracks, update rate, latency, etc.)?

The question regarding distinct requirements for the COP compared to the CTP requirements of the Programs of Record (PoRs), specifically concerning metrics like the number of tracks, update rate, and latency, is an important one. While the final performance parameters will be dependent on the specific systems integrated within the GDS, and therefore will be refined as the program progresses, the JIBM prototype demonstration will be expected to handle a realistic number of threats representative of the anticipated GDS operational environment.

This means that proposed JIBM solutions should demonstrate the capacity to handle a threat load commensurate with the overall GDS defense objectives.

The specific numbers will be clarified in the Statement of Objectives (SOO) provided to offerors selected to submit proposals. However, offerors are encouraged to demonstrate in their white papers a scalable architecture capable of adapting to evolving performance requirements as the GDS matures. This includes addressing anticipated challenges related to data fusion, processing, and visualization of a complex battlespace.

We believe this approach allows for innovation while ensuring the prototype aligns with the ultimate goals of the GDS. Objectives

Does the COP also include requirements to display the Mission Planning information from across the CTPs?

While the RFWP does not explicitly define these requirements at this stage, offerors are encouraged to demonstrate in their white papers their approach to integrating and displaying diverse data sources within the COP, including potential considerations for Mission Planning data. Objectives

68 Section 3.1.b Including Engagement opportunities of other distributed systems on a given systems fire control network (CEC, IFC, DIBN, etc.)? Yes Objectives

69 Section 3.1.c Is the prototype's shot selection cardinality 1:1 to the threat or do we need to consider n:m shots to threats and shot combinations? Consider n:m shots to threats and shot combinations Objectives

70 Section 3.3 Is there a timetable beyond the final prototype delivery in 4Q26 that should be used to timebox or bound the path to operational JIBM capability?

The selected vendor will collaborate with the Government to develop a Statement of Work meant to capture this timeline. Schedule

Is the Release Management Plan CDRL in Section 5.2 where the path forward roadmap will be captured?

Yes - the Release Management Plan should address release methodology and schedule Schedule

72 Section 4.1 Can we assume the context of the Joint Battle Management is in a JFCOM RADC/SADC type of command element (e.g., not other missions like strike)?

Yes Operator

Please provide clarity on what is meant by "dynamic" CoA optimization?

Optimize COAs across component system static responses to account for the dynamic environment and evolving threat picture. Objectives

Are there requirements (number of objects, update rate, etc.) on the JWI Ux for the SA functions?

Not currently defined, but will be derived from operator needs Objectives

Other than the listed JTMC interface, are there other interface specifications required (e.g., OMS UCI, etc.)?

Primary interface is Joint Track Management Capability (JTMC) bridge. If there are specific gaps in the data provided via the JTMC bridge, the component system C2 interfaces can be used as needed. Details including ICDs for these interfaces to be provided after contract award.

Data and Protocols

Is the CIXS exchange required to be 2-way between higher level operational systems (e.g., C2BMC) and lower level tactical systems (e.g., IBCS)?

For this effort, CIXS exchange is required between the JIDP and the Prototype JIBM. Planner

Is there an ability to put JIBM and all the connected C2 systems into a training mode simultaneously using the training mode capability of the discrete systems?

That is an implementation detail regarding Joint Training that may be included as part of the proposed JIBM solution. Training

78 Section 4.2 Does the Sponsor have a desired containerization solution in mind (e.g., Docker, Kubernetes, OpenShift)?

No. Framework

79 Section 4.4 Are any specific IL5, IL6 cloud environments (e.g., AWS) being identified for the deployment?

Hosting preference is for a certified cloud platform that facilitates an iATT. Host platform

80 Section 4.5 Has the Sponsor identified the Authorizing Official (AO) for ATO/IATT? No, but anticipate the JPEO to be the AO. ATO

81 Section 5.2

Can the detailed design MBSE model be provided in lieu of documentation? Would the Sponsor be open to a model deliverable with embedded templates for the autogeneration of documentation and specification? Is there a DID desired for this design documentation?

Detailed design documentation may be provided via MBSE in lieu of documentation. Desire is for MBSE models over written documents. Autogeneration of documents from delivered MBSE models is also acceptable. DID to be provided at a later time. MBSE

Does this mean (10 + 2 + 1 + 3 =) 16 total pages Plus the Cover?

Yes, but the technical approach is limited to no more than 10; Q&E is limited to no more than 2; Schedule is limited to no more than 1; and ROM costs are limited to no more than 3. White paper format

83 Section 1.3 & 3.1

Given the overall unclassified response and SOO (CUI), can the government clarify the requirement regarding the storage and processing of classified information? Are there additional classified documents required for the JIBM prototype development and JTMC Bridge capabilities?

Yes - This program requires the storage and processing of classified information. Yes, there are additional classified documents required for the development of the JIBM Prototype and implementation of JTMC Bridge capabilities. Sensitivity level

84 Section 2.1 What is the funding ceiling for each prototype award?

The Government does not have an anticipated ceiling cost. Vendors should earnestly provide a ROM commisurate with the level of effort in their solution.

Ceiling

85 Section 3.4 Will the government provide a reference architecture with the SOO? No. Framework

86 Section 3.4 Will the government provide a Technical Data Package (TDP) for the JTMC Bridge? Documentation will be provided after contract award. Interfaces

What exactly is being asked for with network management? Is the Govt seeking a new/novel solution for managing the actual comms network, or is the Govt seeking an ability to operate within the confines/limitations of an existing network?

Ability to operate within the confines/limitations of existing networks. Network

What types of information will be available in the Common IAMD XML Schema (CIXS) interface?

Commanders Intent, ATOs, ACOs, other?

Documentation for interfaces will be provided after contract award. Interfaces