# Annex X (informative): Standard development notes
This document is not perfect.
## Notes on 4.1.4 ICT device management
ICT device management use-case highlights how there are multiple controlling entities involved in a device manamagement.
The ownership of those changes is partial and the product usability and the experience what the user ends up having, is sum of all parts.
Analogy could be made to game modding, or software plugin development.
The core is stable, but the extension crashes the system.
This document lacks a clear ownership separation and expectation setting how NMS should aknowledge the existense of other controllers.
Ownership transfer is undefined.
Stacking multiple controlling entities into a device is an operative environment design choice, but does this make the device issuing enterprise the integrator?
How much of the original manufacturer responsibility of providing updates is inherited?
How this settles in with the expected use of the product?
In the greater scheme of device management, the following work could be a direction worth exploring:
* The Open Mobile Alliance (OMA) Device Management protocol [OMADM] and LightweightM2M architecture [LWM2M]
* BroadBand Forum (BBF) CPE WAN Management protocol [TR-069] developed extensive specifications to facilitate Device Management over wireless and wireline telecommunication network respectively
* The Globalplatform Remote File Management and Remote Application Management specifications over HTTP [RAMh] and CoAP [RAMc] targeting secure elements such as SIM cards, as well as the Secure Element Management Service for eSIM [SEM] also fall in this category.
References:
* [OMADM] Open Mobile Alliance™: "OMA Device Management Protocol", Version 2.0.
* [LWM2M] Open Mobile Alliance™: "LightweightM2M Architecture", Version 1.0.
* [TR-069] BBF TR-069: "CPE WAN Management Protocol" Issue 1 Amendment 5, November 2013.
* [RAMh] GlobalPlatform Card Specification v2.2 - Amendment B v1.0.1: RAM over HTTP
* [RAMc] GlobalPlatform Card Specification v2.3 – Amendment M v1.0: RAM over CoAP
* [SEM] GlobalPaltform Card Specification v2.3 – Amendment I v1.2: Secure Element Management Service
## Notes on removed section 5.2.5 Software Bill of Materials
Early versions of this document had a section about SBOM requirements.
### The requirements
Removed requirements:
The requirements in 5.2.5 apply to all NMS products and are not subject to low-, medium-, or high-tier differentiation, because the SBOM is a baseline transparency and dependency-management artifact needed to support vulnerability handling, update management, and product assessment across all deployment contexts.
-**[REQ-SBOM-0]:** Operating system dependencies and application dependencies shall be clearly separated in the provided SBOM.
-**[REQ-SBOM-1a]:** Unique, unambiguous, and machine-readable identification of all components and dependencies shall be provided in the SBOM.
-**[REQ-SBOM-1b]:** The SBOM shall use unique, unambiguous, and machine-readable component identifiers based on recognized public formats that support correlation with vulnerability information sources.
-**[REQ-SBOM-2]:** The SBOM shall be consistent with [5.3.4 Secure updates] practices.
It has been also suggested, that:
The Software Bill of Material delivered with each software update in one of two
standard formats:
*[SPDX](https://spdx.dev/use/spdx-tools/)
*[Cyclone DX](https://cyclonedx.org/)
### Removal reason
There are no clear instructions or interfaces available.
The SBOM format and generation is not a concern that is unique for the products in this category.
