Editorial clean-up

The cluster the product is hosted at is often composed out of multiple nodes and scaled to fit into the operator’s operational environment.

The number of nodes and the composition of the hardware is designed to handle the expected load from the management function the product is performing.

**Table 4.8.x-1: Logical separation of duties adjacent to RFC1122**

| Layer                     | Responsibility       | Observability                                           |

| :------------------------ | :------------------- | :------------------------------------------------------ |

| Application               | Development          | Quality provided for the customer                       |

| Capacity                  | HW engineers         | Application requests towards HW                         |

| Networking and facilities | Site manager         | Is it on? Can I walk into the premises?                 |

**Table 4.3.2-1: Logical separation of duties adjacent to RFC1122**

The product requirement can be defined with the abstraction layers as given in the table above, but the product is required to support the architectural design and conditions of the concrete operational environment.

There is a variety of structures and responsibility separations supporting the actual use case possible.

Also the product’s shipment and delivery procedures usually follow the system users’s needs and may also need to be conformant with critical infrastructure rules and requirements.

> Example: SIEM system operation requires access grants from the product Application-layer to be able to collect information from devices in the Networking and facilities-layer.

**Table 4.8.x-2: Responsibility separation example in a larger scale deployments**

| Layer                     | In-house             | Hyperscaler      | On-site as a service |

| :------------------------ | :------------------- | :--------------- | :------------------- |

| Application               | Product customer     | Product customer | Service provider     |

| Capacity                  | HW engineers         | Hyperscaler      | Product customer     |

| Networking and facilities | Site manager         | Hyperscaler      | Product customer     |

**Table 4.3.2-2: Responsibility separation example in a larger scale deployments**

While it is possible to stay in a higher abstraction level of above layering while defining the product requirements, the provided product needs to acknowledge what designs are supported.

There are different benefits in different responsibility separation structures.

Often the selection of delivery style is guided by customer needs, where critical infrastructure requirements have to to be matched in the product.

### 4.3.3 Logical/Software environment

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.

These complex networks can be modeled by how the functions are virtualised in the network [4.4.3.1 Logical network deployment](#4431-logical-network-deployment) or examining how much RDPS is involved in the design [4.4.3.2 Physical network deployment with RDPS](#4432-physical-network-deployment-with-rdps).

These complex networks can be modeled by how the functions are virtualised in the network like [Logical network deployment without physical hardware](#4641-uc-4-sdn-logical-network-deployment-without-physical-hardware) or examining how much RDPS is involved in the design from [Physical network deployment with RDPS](#4642-uc-5-hybrid-physical-network-deployment-with-rdps).

Yet, the protocols used for all network deployments remain consistent.

TCP and UDP dominate the network and transport layers in the OSI-model.

## 4.6 Use Cases

<mark>Editor's Note: The use cases shall be defined as a combination of the product context elements described in clauses 4.1 to 4.5, clearly indicating:<br>

    - Title the title of the use case, following a consistent naming/ID scheme (e.g., UC-3 Internet Connection)<br>

    - Goal the goal of the use case (e.g., connect to the Internet)<br>

    - Description via subclauses or bullet points which elements from each apply (i.e., product type: ..., function: ..., users: ..., architecture: ..., operational environment: ...)

</mark>

This list of use cases is a resource for manufacturers to simplify the selection of a set of cybersecurity requirements.

Manufacturer's technical documentation may benefit from including or referring to these use cases.