@@ -498,24 +498,24 @@ A managed device can have a configuration port, a management API, a firmware upd
#### 4.2.x.1 Inventory management
The secondary function of an IoT network NMS can be to generate, keep, and maintain the inventory of the network.
This inventory holds information about the connectivity capabilities for each networked device.
The a function of a NMS can be to generate, keep, and maintain the inventory of the network.
This inventory holds information about the connectivity, capabilities, and some form of mutual authentication for each networked device.
When new devices are added and a trust is established, the new device extends the network and the inventory is amended.
Managing an accurate inventory is not always needed.
Depending on the business logic, and the purpose of the network, the inventory can be a rolling list of devices the network has communicated with during a 24 hour window.
Depending on the business logic, and the purpose of the network, the inventory can be a rolling list of devices the network has communicated during a 24 hour window for example.
Even such a simple list requires that the NMS exercise care when devices are removed from the network.
When a rogue device is identified, it is important to be able to isolate the device, and mitigate the potential impact of its actions.
#### 4.2.x.2 Device management
The IoT device design can be very simplistic, where the device relies on the system the push for configurations and even update the device firmware.
In the other end of the spectrum, the device can be designed to operate as autonomous agent that requires little or no input from the NMS to manage its functions and run software.
Contemporary advancements in microcontroller features and adjacent platforms used to build IoT devices blur the distinction between a simple device and a complex computation node, often reducing the description of a device as "IoT" to a branding decission from the manufacturer.
The connected device design can be very simplistic, where the device relies on the system the push for configurations and even update the device firmware.
In the other end of the spectrum, the device can be designed to operate as autonomous agent that requires little or no input from the NMS to manage its functions to run the workload.
This distintion or lack of distinction, makes determining the role of the NMS in the IoT network important to understand as it determines when the device needs to be managed.
IoT devices themeselves are outside the scope of this document, but how a device's API's are designed, and how the trust is established in the connected network needs to be evaluated as a function of its NMS and within limits of this document.
NMS is defined through the need need to manage the device.
The devices themeselves are outside the scope of this document when the device facing API's are not.
How the trust is established in the connected network operative security can be evaluated with the product is core components of this document.
## 4.3 Operational Environment
@@ -701,6 +701,8 @@ One example of this type of aggregate product design would an implementation whe
**Figure 4.6.1.1-1: IoT network with monitoring data collection**
Contemporary advancements in microcontroller features and related platforms used to build IoT devices blur the distinction between a simple device and a complex computation node, often reducing the description of a device as "IoT" to a branding decission from the manufacturer.
An IoT network is a network of devices, each of which almost always has limited computational capabilities and consumes a low amount of power.
The exact purpose of these device varies, but they are all connected to an NMS, and often to each other and to an IoT business logic, which may be a RDPS.
The main focus of an IoT network is almost always data collection, and the NMS in this use case usually visualises the collected data metrics and provides them to the end-user.
