[API Proposal] Network Contract Lifecycle Management (N‑CLM)

[abd-abhisek]

What type of PR is this?

Add one of the following kinds:

• documentation

What this PR does / why we need it:

Adds md file, pptx

Which issue(s) this PR fixes:

Fixes # #299

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[albertoramosmonagas]

Please rename the proposal file from N-CLM.md to a self-explanatory name. Using only the abbreviation makes it difficult for participants to understand the proposal from the repository view.

Suggested file name: network-contract-lifecycle-management.md

In addition, please avoid using N-CLM as the primary term throughout the document. The full name should be used first, with the abbreviation only introduced afterwards.

Separately, if this proposal progresses to repository/API naming, we should revisit the final API/repository name. Network Contract Lifecycle Management is quite long, and the word contract may suggest BSS/Operate scope. A shorter name such as network-sla-management or sla-policy-managementmay better reflect the intended scope, but this should be decided after the functional boundaries are clarified.

[albertoramosmonagas]

Some points:

1. The current proposal document is still too high level. Most of the useful clarification is currently in the supporting deck, but the PR document itself should contain the essential information needed for Backlog review. Please enrich the proposal document with:

• the scope clarification currently described in the deck;
• the intended resource model and lifecycle;
• the dependency/boundary with CQM, QoD and Dedicated Networks;
• the main user stories;
• the answer to the previous Backlog concerns about assurance, telemetry and overlap.

2. The proposal is now more concrete, but I still think we need to close the scope and overlap discussion before considering it ready for Backlog validation. The proposal says that the API binds SLA policies to existing CAMARA service instances, continuously evaluates metrics, and sends breach notifications. This is very close to assurance unless the boundaries are made explicit. Please clarify:

• whether this API only stores/evaluates SLA policies, or whether it also defines the compliance evaluation logic;
• which concrete CAMARA service instances it can bind to, e.g. QoD session, Dedicated Network reservation, etc.;
• which concrete API/source provides the metrics consumed by the policy evaluator;
• whether the proposal is intended as a new independent API, a new API within CQM, or an extension to existing CQM / Dedicated Networks work.

Given the dependency on CQM telemetry and the binding to QoD/Dedicated Networks, I think this should be reviewed with the relevant CQM maintainers before moving it forward.

3. There are a few inconsistencies in the validation/support section. The proposal currently says “Validated with operators? YES / IN PROGRESS”. Please make this unambiguous:

• if validation is still ongoing, mark it as NO / IN PROGRESS;
• if it is already validated, specify how many operators reviewed or validated it and what exactly was validated.