Chapter 5. Configuration Management

41. The NISP is updated once a year to account for the evolution of standards and profiles.

42. Request for Change (RFC) to the NISP will be processed by the IP CaT, following the process in the graphic below:

RFC Handling Process
Figure 5.1. RFC Handling Process

43. The RFC contains all information required for the NISP management by IP CaT; The detailed information about standard or profile is handed over as attachments to this form. A notional RFC form with example information is presented below:

RFC Notional Form
Figure 5.2. RFC Notional Form

44. The primary point of contact for RFC submission is the IP CaT. RFCs may be submitted to the IP CaT via the Change web site or via email to herve.radiguet@act.nato.int with attachments.

45. Review of RFCs will be coordinated with the responsible C3 Board substructure organizations where appropriate.

46. The IP CaT reviews the submissions in dialog with national and international bodies. Based on that review, the RFC will be formally processed into the next version of the NISP; or returned to the originator for further details; or rejected. The IP CaT will attempt to address all RFCs submitted by 1 September into the next NISP release. RFCs submitted after this date may be considered for inclusion at the discretion of the IP CaT, or will be processed for the following NISP release.

5.1. NISP Update Process

47. The new NISP version is submitted to the C3 Board by end of the year after internal review by the IP CaT. The version under review is a snapshot in time of the status of standards and profiles.

48. The database of standards and profiles maintained by the IP CaT is the definitive source of the current status of standards and profiles.

5.1.1. Criteria for listing Standards and Profiles

49. Standards and profiles listed in Volume 2 of the NISP shall:

  1. have an assigned responsible party that can provide relevant subject matter expertise, if no responsible party exists the IP CaT will create a temporary assignment,

  2. be available in one of the NATO official languages,

  3. support C3 Interoperability (incl. people, processes and technology) and related NATO common funded Communication and Information Systems (CIS) including their development and operations, and

  4. enable the NATO Enterprise, NATO Nations and partner nations to develop interoperable capabilities that support NATO's missions (ie. NATO led operations, projects, programs, contracts and other related tasks).

50. In addition standards shall be approved already by a NATO Standardization Tasking Authority or another non-NATO standards development organization (e.g. ISO, ANSI, ETSI, IEEE, IETF, W3C).

51. Deviations from the rules listed above can be recommended by the IP CaT and approved by the C3B.

52. Given the rate of innovation in Information and Communication Technology (ICT), it is unsurprising that, NATO standards must be reviewed and updated regularly to keep pace with the state of the art and other international standards. The following criteria should be considered by responsible parties during their annual review of NATO Standards:

  • Are all stakeholders’ views are reflected in the Standardization Working Group?

    • End Users/ Operational Users

    • Implementers/Vendors

    • Technical Solutions Experts/Testers

    • Standards Experts

  • Are all referenced basic standards and documents still valid?

  • Are key terms consistent with agreed NATO Terminology?

  • Does the standard contain conformance criteria?

  • Were any issues with the standard identified during test events (e.g. CWIX, CIAV)?

  • Are reference implementations[4] of the Standard available to vendors?

53. Some key criteria for inclusion of non-NATO standards into Volume 2 are

  • Availability of implementations from a cross-section of vendors;

  • Compatibility with other standards;

  • Completeness. Does the standard meet the functional requirements?

  • Extensibility. Can the standard easily add new technologies when they become available?;

  • Stability/maturity. Is the standard based on well understood technology, and has it matured enough to ensure no major changes will occur through further refinements?

  • Non-discriminatory. Was the standard developed in a consensus-based way?

  • Testability. Conformance metrics. Can the standard be tested to prove compliance?

  • Legitimacy. Freedom from legal issues.

54. Similar criteria are also applied for inclusion of Profiles into Volume 2. Profiles should follow the Profile Guidance in Volume 1, Appendix A, and the IPCaT reserves the right to adjust the data structure of a profile to align with the data model of the NISP.

55. Standards and profiles listed in Volume 3 are not subject to the above criteria as they are not (yet) mandatory.

5.1.2. Updating listed Standards and Profiles

  • process RFCs together with related responsible parties,

  • check if newer versions of

    • listed standards are published by the NATO Standardization Tasking Authority or another non-NATO standards development organization,

    • listed profiles are published by the respective development organization,

    • contact all responsible parties to assess if there is a continued need to keep standards and profiles within Volume 2.


[4] To facilitate interoperability and adoption in general the production of reference implementations and similar tools that vendors can use to bootstrap and test development efforts is critical. These reference tools help clarify the expected behavior described by the standard. If these tools are released under appropriate licenses, the tools themselves or components thereof can be directly integrated into vendor products, reducing the investment cost, and therefore the risk, of adoption and accelerating adoption efforts. For standards that rely on multiple parties, such as communications protocols between two different roles, having a reference implementation for both communicants can be a big help to implementers by giving them a correspondent against which to test their own implementation. As such, simple implementation efforts can have a significant role in encouraging interoperability and adoption.