Loading decisions/0035-qod-session-service-specification.md +9 −0 Changes for decisions/0035-qod-session-service-specification.md: 9 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -66,6 +66,7 @@ bootstrap that materializes zones, network domains and the `qod_session` capabil | Field | Value | |---|---| | `id` | `7608e902-b927-559f-b448-e7e9061dfa5c` — the well-known default (see below) | | `ref` | `qod-session` | | `version` | `1` | | `app_provider_id` | the platform's own provider identity, not a customer's | Loading @@ -77,6 +78,14 @@ OEG holds the resulting id in configuration as `service_specification_id` on every `command.srm.network.capability.activate` for `capability_type=qod_session`. The value is identical on every session. **Well-known default id.** The id above is a fixed constant, not generated at seed time. SRM's topology bootstrap inserts `service_specification.id` with that value, and OEG falls back to it when `QOD_SETTINGS__SERVICE_SPECIFICATION_ID` is unset — so a deployment that configures nothing still works. It is a **two-sided contract**: changing it on one side only, or seeding a generated id without configuring OEG to match, restores the original defect (a `service_specification_id` referencing no row, and `failed_before_start` on every activate). Operators who want a different id set it in both places. **Profile names remain unvalidated.** `qosProfile` continues to travel as `profile_ref`, a free string the adapter resolves (REQ-SRM-08). The seeded requirement's `policy` is empty, so any profile name and any duration within CAMARA's own `1..86400` bound is accepted. The network Loading Loading
decisions/0035-qod-session-service-specification.md +9 −0 Changes for decisions/0035-qod-session-service-specification.md: 9 added lines, 0 removed lines. Original line number Diff line number Diff line Loading @@ -66,6 +66,7 @@ bootstrap that materializes zones, network domains and the `qod_session` capabil | Field | Value | |---|---| | `id` | `7608e902-b927-559f-b448-e7e9061dfa5c` — the well-known default (see below) | | `ref` | `qod-session` | | `version` | `1` | | `app_provider_id` | the platform's own provider identity, not a customer's | Loading @@ -77,6 +78,14 @@ OEG holds the resulting id in configuration as `service_specification_id` on every `command.srm.network.capability.activate` for `capability_type=qod_session`. The value is identical on every session. **Well-known default id.** The id above is a fixed constant, not generated at seed time. SRM's topology bootstrap inserts `service_specification.id` with that value, and OEG falls back to it when `QOD_SETTINGS__SERVICE_SPECIFICATION_ID` is unset — so a deployment that configures nothing still works. It is a **two-sided contract**: changing it on one side only, or seeding a generated id without configuring OEG to match, restores the original defect (a `service_specification_id` referencing no row, and `failed_before_start` on every activate). Operators who want a different id set it in both places. **Profile names remain unvalidated.** `qosProfile` continues to travel as `profile_ref`, a free string the adapter resolves (REQ-SRM-08). The seeded requirement's `policy` is empty, so any profile name and any duration within CAMARA's own `1..86400` bound is accepted. The network Loading
