Release Review: NetworkAccessManagement r3.1 (rc Sync26)

[camara-release-automation]

Release Review: r3.1 rc

This PR finalizes the reviewable release content for the active snapshot.

Edit and review this PR before merging it into the release snapshot. After Codeowner and Release Management approval, merging this PR creates the draft release.

Release contents

API	Version	Status	Comparison target
network-access-devices	0.3.0-rc.1	rc	N/A
network-access-domains	0.3.0-rc.1	rc	N/A

Dependencies: Commonalities r4.3, ICM r4.2

Codeowner Actions

Tick each box once done. Ticking the last box — "The release is ready for Release Management review" — starts the Release Management review.

• Update the CHANGELOG

  What to do:

  • Copy all API-consumer-relevant changes from the provided list into the appropriate Breaking changes / Added / Changed / Fixed / Removed sections for each API. List breaking changes both in Breaking changes and in their normal change category.
  • Do not copy administrative, tooling-only, or internal maintenance changes unless they affect API consumers.
  • For each API, fill the CHANGELOG against the stated comparison target, following the release-type rules at the top of the CHANGELOG.

• Document deferred validation warnings (and hints)

  What to do:

  • Check the CAMARA Validation comment on this PR for warnings and hints.
  • For each warning you do not fix, document it in an issue: include a copy of the validation summary line(s) and the reason the fix is deferred.
  • Document in the same way any validation hint that is applicable to the API and needs to be fixed later.
  • You may group several findings into one issue or split them across issues — either is fine.
  • List the documenting issue(s) in a comment on this PR.
  • Note: documenting deferred warnings is optional but recommended for alpha pre-releases, and mandatory for rc pre-releases and public releases.

• The release is ready for Release Management review

  Check that:

  • All mandatory release assets for the declared status(es) are present (see the table below "Required release assets per API status" by expanding the arrow);
  • API documentation and test cases are adequate for the target status.

  Tick this box to confirm readiness and to start the Release Management review.

Release Management Actions

The following actions and checks are done by a Release Management reviewer before approving the PR:

• Assign the Release Management reviewer(s) as assignee(s) of this PR
• CHANGELOG follows the release documentation rules
• Breaking changes are documented and version updates follow SemVer rules
• Mandatory release assets are present for each API according to its status
• All remaining validation warnings are documented in issues and the reasons for deferral are defensible

Required release assets per API status

Nr	Asset	alpha	rc	initial public	stable public
1	Release Plan	M	M	M	M
2	API Definition(s)	M	M	M	M
3	Commonalities compliance	O	M	M	M
4	API Documentation	M	M	M	M
5	User Stories	O	O	O	M
6	Test Cases (basic)	O	M	M	M
7	Test Cases (enhanced)	O	O	O	M
8	API Description	O	O	M	M

M = Mandatory, O = Optional — Full documentation

Valid next actions for codeowners

• Merge this PR when all Codeowner Actions and Release Management Actions are complete and the required approvals are present — creates the draft release
• Use /discard-snapshot <reason> in the Release Issue to discard this snapshot, return to planned, and update content on main

---

Snapshot: r3.1-d1b328d

[camara-validation]

CAMARA Validation — PASS

0 errors, 0 warnings, 61 hints | Profile: standard

View full results

[higherorderfunctor]

LGTM

[clundie-CL]

LGTM

[clundie-CL]

@tanjadegroot As recommended in PR #164, that PR was discarded, issue #165 was fixed and merged. This PR is the follow-on snapshot.

[tanjadegroot]

Hi team,

please see comments on teh changelog and readme that can be fixed on this PR. *

After that you should be fine for release.

[tanjadegroot]

The introduction of the new error code 409 INCOMPATIBLE STATE in the OAS is listed as a breaking change and should be documented in the changelog both in the "Breaking changes" and in the "Added" sections. Same for documenting the removal of the 409 CONFLICT in "Breaking changes" and 'Removed" sections.

There are a few "feat:" changes listed in the candidate changes section that you may want to copy to the changelog "Added" section.

Similarly, some of the "fix:" ones could be copied to the "Fixed" section if useful for the API consumers.

[tanjadegroot]

You may want to slightly extend the scope section of the README to reflect the functionality of the 2 APIs.

[clundie-CL]

Thanks @tanjadegroot — I've updated the CHANGELOG on this PR to address the review:

• 409 error code — now documented as a breaking change under Breaking changes, with the replacement codes 409 ALREADY_EXISTS / 409 INCOMPATIBLE_STATE under Added and the deprecated 409 CONFLICT under Removed, in both API sections (fix: replace deprecated 409 CONFLICT error code (#165) #166).
• Candidate feat: changes — pulled the consumer-facing one into Added: the Network Access Device deviceStatus field (feat: adds deviceStatus field to Device model #56). (The Thread-provisioning feat: (feat: adds the ability to provision a Thread network #64) was already covered by the Wi-Fi/Thread access-types entry.)
• Candidate fix: changes — I reviewed these and deliberately left Fixed = N/A. The remaining fix: entries are either repository/tooling/CI changes (validation-caller pins, linting cleanups, file moves) that aren't API-consumer-facing, or pre-alpha error-model adjustments already baked into the API surface — i.e., not deltas between the r2.1 alpha and this RC. The one genuine error-model change since the alpha is the 409, now captured under Breaking/Added/Removed above. Happy to add any specific fix: you consider consumer-relevant.
• README — extended the Scope section to describe the functionality of both APIs (Network Access Domains and Network Access Devices).

[tanjadegroot]

Thanks @tanjadegroot — I've updated the CHANGELOG on this PR to address the review:

@clundie-CL Hi Cody, it looks great now. Many thanks for the updates. I will approve the PR.

[tanjadegroot]

All good - thanks !

/LGTM

[clundie-CL]

LGTM

[caubut-charter]

LGTM

[clundie-CL]

@tanjadegroot I noticed that this is not part of the post-release sync to main PR #170. Is that expected or a release automation gap?

Not a major issue, can always manually reconcile what was added to the release tag back onto main, but my reaction at a glance is that if a README is adjusted on a release PR to the snapshot branch, that this would also sync back to main.

[tanjadegroot]

Hmm, good catch, you are probably right on that one. Will check with @hdamker what should be done here. Either only automated changes to the README in the Release Review PR and manual updates to README on main only, or synch back to main if updates are allowed. It could be my bad on the recommendation to change it in the release review PR (in which case my apologies).