Add support for a human‑readable name in Dedicated Network instances

[sergiobrisio]

Problem description
During alignment in the Dedicated Network working group (Camara), it was highlighted that the introduction of the new endpoint dedicated-network-areas solves the circular reference issue created by the original serviceArea object in the Dedicated Network API.

However, the removal of the free‑text serviceArea field unintentionally eliminates the only available place for API Consumers to store a human‑readable name associated with a created Dedicated Network instance.
This creates a functional gap:

API Providers and Consumers need a user‑friendly identifier for a dedicated network instance (e.g., “FactoryFloorAreaNetwork”, "DNNforLaptops"etc.).

The exposure of profileId / networkProfileId / qosProfileName / serviceAreaId in uuid format is insufficient for readability and for operational UIs.
Today there is no field where such a name can be stored.

Possible evolution
Introduce a new (optional?) attribute:

name:
  type: string
  description: Human‑readable name of the dedicated network instance.

The field should be added in NetworkInfo, as this object represents the instantiated network and already groups dynamic attributes such as state, start/end time, and identifiers.

---

Requested Change
Add name to NetworkInfo schema:

NetworkInfo:
  description: Current dedicated network information
  type: object
  properties:
    name:
      type: string
      description: A human-readable name for the dedicated network instance.

Alternative solution
Alternatively, if the group prefers, it may be added in BaseNetworkInfo, but attaching it to NetworkInfo seems more coherent, since the name applies to the created resource rather than the generic creation request.

Additional context
Once approved, I will open a PR adding the field to the dedicated-network YAML file and updating documentation accordingly.

[hubertp-ericsson]

I think it is a good suggestion to add a human readable name to the network resource. The use case in my mind is that the creator of the network would gain the ability to name its network. Therefore, I'd rather include it as an optional property in BaseNetworkInfo since that is what is used in CreateNetwork.

[tlohmar]

Interesting. some thinking:

• human readable name: This is one usage example. However, it is not a requirement, that the string has a human-understandable meaning.
• API customer selected name: This is certainly a good idea to allow API customers to use self-selected names for the reserved network resources. The API customer may add semantics like "FactoryFloorAreaNetwork" or embed other information.

Once approved, I will open a PR adding the field to the dedicated-network YAML file and updating documentation accordingly.

@sergiobrisio there is no approval procedure for issue. Thus, please go ahead and create the PR.