19. Each profile shall list the Capabilities supported by the profile. The intention of this section is to trace NATO capabilities to the applicable element(s) in the NATO capability taxonomy/database and NNEC Maturity Level (NML), as well as any relevant authoritative capabilities operational reference documents (e.g., Overarching Architecture, EXTAC reference, etc.). Identification of applicable functional attributes is desired to link capability requirements to objective or subjective interoperability performance objectives.

20. Each profile should list the Functional Attributes supported by the profile. The intention of this section is to identify what functional attributes are desired and thus link capability requirements to interoperability performance thresholds and objectives. For example, a typical threshold for satisfactory equipment performance may be maintaining 99% operational availability (Ao) (exclusive of scheduled maintenance) as calculated in accordance with the U.S. DOD Guide for Achieving Reliability, Availability, and Maintainability or the IEC 60300 (Series) standards.

21. Each profile should document the relationship between Capabilities and Operational Activities supported by the specific interoperability profile. The intention of this section is to map capabilities to operational activities thereby providing implementation authorities with vital understanding as to what actors will be establishing what NML is being sought at specific Service Interoperability Points (SIOPS). Identification of entities may be generic, specific, or a combination of generic and specific entities. For example, it may be unrealistic and inappropriate to identify specific operational units, deployable headquarters, and/or non-NATO actors for a reference-architecture (high-level) profile. However, specific identification of operational activities may be totally appropriate for developing a target-level profile associated with promoting interoperability for a specific discrete event or set of events in theatre.

22. Each profile shall document the standards required to support this or other associated profiles and any implementation specific options. The intention of this section is to provide an archive that shows the linkage between evolving sets of standards and specific profile revisions.

23. Each profile should document other key related system or service profiles in a cross reference table. The intention of this section is to promote smart configuration management by including elements from other profiles rather than duplicating them in part or in whole within this profile. Related profiles would likely be referenced in another section of the profile.

29. Each profile should list relevant agreed operational definitions within the scope of the profile. The intention of this section is to promote a common understanding of the operational terms used across interfaces among different entities (i.e., semantic interoperability). For example, for an MSA profile, one may provide a specific definition for the term 'vessel of interest' in order that the term may be properly understood and/or translated across the interface.

30. Each profile should list the operational concepts within the scope of the profile. The intention of this section is to identify operational concepts that provide relevant context for implementation authorities to understand how interoperability will enable and support achieving mission success. DOTMLPFI categories consider interoperability within the context of delivering comprehensive capabilities to operational users. Some of these categories may not be applicable. The use of the term DOTMLPFI is not intended to be exhaustive or exclusive. Thus, other capability categories such as policy and legal may be added as deemed appropriate.

31. Each profile should provide a diagram of the operational nodes connectivity supported by this profile. The intention of this section is to identify operational nodes to provide implementation authorities with a more detailed description of the required/desired interoperability end state (i.e., goal baseline) connectivity. Identification of operational nodes may be generic, specific, or a combination of generic and specific elements. The figure below from the NATO Architecture Framework version 3 illustrates a typical NOV-2 diagram used for this purpose.

Figure 1.2. Notional Node Connectivity Diagram

32. Each profile should describe the contribution and connectivity of each operational node supported by the profile. The intention of this section is to support the development or use of NOV-2 or NOV-2-like architecture view(s).

33. Each profile should list the relevant operational information requirements (preferably described using APP-15) within the scope of the profile. This section is intended to promote the NNEC need to share information in a Service Oriented Architecture by documenting Information Requirements associated with this profile to support the NATO Data Strategy making data visible, accessible and understandable. If such information is maintained in an external document, reference to such documentation is preferred - including the most recent revision associated with this particular profile baseline.

34. Each profile should list relevant key conformance criteria of operational interest. The intention of this section is to document criteria such as alerts, thresholds or other parameters that may be important to understanding and employing information shared across an interface. This list of key criteria is not intended to be exhaustive. Additionally, if such criteria are described in a separate document referencing the document is appropriate. For the sake of brevity, it is highly encouraged to reference (not duplicate) other documents when completing this section.

35. Each profile should describe the capability baseline that the profile supports. The intention of this section is to identify "as is" capability baselines that have used this profile. Since profiles tend to evolve, the specific profile revision used to achieve interoperability is also noted.

36. Each profile shall include a description of the organizational interfaces supported by the profile. The intention of this section is to promote visibility and interactions among stakeholders. Note that the intention of this section is very different than the aim of the Operational Node Connectivity Description. This section is intended to be more administrative in nature and identify stakeholders and contributors to the profile. Generic organizational billets and/or specific points of contact may be identified in this section as desired.

37. Each profile should list the system functions that the profile supports. The intention of this section is to provide a basic understanding of the system functional decomposition on the profile implementation authority's side of the SIOP. The intent of this section is to make the profile less abstract and more concrete for the implementation authorities on both sides of the SIOP as they work to achieve interoperability. There is no intention of renaming functions on the other side of the SIOP, but rather to provide insight regarding what functions will be supported by information crossing the SIOP interface(s). Detailed system functional descriptions should be cited as references, not duplicated.

38. Each profile should document the current and emerging technologies required to support this profile and any implementation specific options. The intention of this section to identify current and emerging technologies associated with promoting interoperability as an aid to stakeholder organization program managers as they consider (with interoperability in mind) their own mid-term (2-6 years) and long term (>6 years) investment plans in relevant technologies.