Partial edits to use case revisions for clarity and grammar

1.  Establishes and maintains a trust-based relation between itself and the devices.

To initialize a trust-based relationship between this type of network managment system and connected devices, both store credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers. These credentials are used during initialisation to create the trusted relationship between the NMS, the devices and, if present, with the IoT device business logic. Credential or key initialisation, and key enrollement or establishment limit the NMS's ability to establish a trusted relationship to the intended devices, an ability further limnited as these methods require physical access or close proximity to the IoT device. For example, an IoT devicve user can pair the IoT device and establish a trust-based relationship with the NMS through Bluetooth (tm) mechanisms or with a physical cable connection.

To initialize a trust-based relationship between this type of network managment system and connected devices, both of which store credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers. These credentials are used during initialisation to create the trusted relationship between the NMS, the devices and, if present, with the IoT device business logic. Credential or key initialisation, and key enrollement or establishment limit the NMS's ability to establish a trusted relationship to the intended devices, an ability further limited as these methods require physical access or close proximity to the IoT device. For example, an IoT devicve user can pair the IoT device and establish a trust-based relationship with the NMS through Bluetooth (tm) mechanisms or with a physical cable connection.

Once the trust-based relationship has been established, the NMS can provide cryptographically protected configuration and update services to the devices at runtime. Depending on the initial NMS and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device. The trust-based relation can also provide for secured identification, authentication, and communication with other applications on a device.

Once the trust-based relationship has been established, the NMS can provide cryptographically protected configuration and update services to the devices at runtime. Depending on the initial NMS and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device. The trust-based relationship can also provide for secured identification, authentication, and communication with other applications on a device.

The IoT network NMS collects the meta traffic data and management related data from networked devices, or forwards it to other systems for data collection and storage. All data transmitted from the devices to the NMS and all data transmitted from the NMS to the devices is cryptographically protected with authentication of the endpoints, and with integrity and confidentiality protection. Independent of any of the host system's capabilities, the NMS can also be remotely accessible.

**Figure 4.4.1.2-1: Home network deployment**

In this use case, the network manangement system controls the user's home network of devices and often acts as a gateway or an access point providing connectivity for the user's home to outside networks, usually public.  Access points are devices such as a router, switch, modem, or other wireless or wired device controlled and governed by the NMS and physically deployed to the service requesting users home.

The device can also make the upstream connection technology transparent to the user.

Depending on the available infrastructure in the deployment location, the connectivity can be through a mobile network or through a figer optics network to name a few alternatives.

The device can also make the upstream connection technology transparent to the user. Depending on the available infrastructure in the deployment location, connectivity can be through a variety of alternatives, including a mobile network or fiber optics network.

The NMS in this use case is most often locally installed on the device but may be running on a different device within the same network, or as a remote service, a RDPS.

Whyile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users. A contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services. IdP's may be part of an NMS or seperate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS. In all varieties the nature of the IdP deplyed to the netowrk is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration methods or IdP technique.

The increasement in the importance of the operational context is linear with the accuracy how identity is managed.

A larger enterprise has more staff, roles, job and responsibility rotation, required services, data classes, levels of classified information, and working sites.

These factors contribute to the multiple different risks that require more elaborate management structures.

A small business could handle the credential cleanup of an old employee by hand, but a large enterprise might see value in admin credential management services.

As the importaqace of the operational context rises, so does the level of accuracy needed to securely manage identity.

A larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.

The increase in size and complexity contribute to increasing multiple risks that requires more elaborate management structures.

While many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.

The describe enterprise within this context can be a medical facility, which handles patient records or a bank, that upholds the nations finances.

It is not for the NMS to care what the Service Requesting User does with the network, but to ensure, that the system has enough features that matches the operational needs.

Additionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data. The type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS must ensure that the system has the features, hardware, and security to match operational needs. 

#### 4.4.2.2 Telecom network

#### 4.4.3 Alternative deployments

As the rise in popularity to utilise hyperscalers and software defined everything in networking services, how we understand network structures depends on how we model the connectivity.

The used protocols largely remains the same.

TCP and UDP dominates the network and trasport layers in the OSI-model.

DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pool builds the trust on top of DNS being correct.

Encryption can be applied to transport layer, but is rarely seen due to computational requirements and higher cost and more complex management reasons.

Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout the private intranet sold for the service requesting users.

As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity. The following use cases consider such deployment and other complex deployments primarily by focusing on two factors. These complex networks can be modeled by examining [how much RDPS](#4432-physical-network-deployment-with-rdps) is involved in the design or how the functions are [implemented in local software](#4431-logical-network-deployment).

If the application needs assurance on integrity, it needs to be responsible on encrypting its own traffic.

If somebody else's provided locks and keys are used to protect the house, there can be no certainty who can open up the door.

Yet, the protocols used for all network deployments remain consistent. TCP and UDP dominate the network and trasport layers in the OSI-model. DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pools builds trust beyond that provided by the DNS.

Complex networks can be implemented and modeled through [how much RDPS](#4432-physical-network-deployment-with-rdps) is involved in the whole design or how everything can be [implemented in software](#4431-logical-network-deployment). These approaches are explained in the following use-cases.

Encryption can be applied to the transport layer, but is rarely seen as it imposes increased computational requirements, higher cost, and more complex management. Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout a private intranet. Only in networks that need greater intergrity assurance, does the network need to be responsible for encrypting its own traffic. 

#### 4.4.3.1 Logical network deployment

Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts.

A SDN needed a IP subnetwork definition in order to hand out IP addresses with a DHCP from a switch.

The Virtual Machines uses Virtual Ethernet interface (veth) to transfer information like it would do with a physical card.

The veth is connected to virtual switch, that handles ARP protocol duties, and relies the DHCP queries to the control layer.

Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts. Such SDNs needed an IP subnetwork definition to provide IP addresses with a DHCP from a switch. 

The Virtual Machines uses Virtual Ethernet interface (veth) to transfer information in the same way that other networks would with a physical card. The veth is connected to virtual switch, that handles ARP protocol duties, and relies the DHCP queries to the control layer.

**NOTE: AB EDITS END HERE**

The subnet virtual switch is connected to a virtual router acting as a gateway, enabling the virtual machine to communicate with rest of the connected infrastructure.

All of these virtual devices can be independent instances of virtual machines running OS with a linux kernel.