Release Review: DedicatedNetworks r2.2 (rc Sync26)

[camara-release-automation]

Release Review: r2.2 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
dedicated-network-accesses	0.2.0-rc.1	rc	0.1.0
dedicated-network-profiles	0.2.0-rc.1	rc	0.1.0
dedicated-network	0.2.0-rc.1	rc	0.1.0
dedicated-network-areas	0.1.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: r2.2-6771f7f

[camara-validation]

CAMARA Validation — PASS

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

View full results

[tlohmar]

All steps completed from our side

[hdamker]

Not an approval and not a changes-requested review – attaching background information on this snapshot ahead of the Release Management review, so the pattern across review rounds is visible in one place (CHANGELOG entries against the 0.1.0 comparison target, test-case coverage relative to the readiness checklist, and an issue-by-issue rundown of how the last three review rounds landed).

Findings in details:
dedicatednetworks-r22-release-review-2026-09-01.md

One thing worth calling out here on its own, since it doesn't attach to any single issue: several of this round's Accesses fixes are correct on their own terms, but sit on top of the same three things underneath. An admitted device still has no resource identity of its own – no per-device read, no way to reference "that admission" in a later call. recentAccessDevices is still the only feedback channel for an admission, and it's still capped at 100 entries with no ordering or timestamp. createAccess (and its siblings addDevicesToAccess/removeDevicesFromAccess) still doesn't separate a single-device operation from a batch operation – one call does both, which is why one status code ends up having to report two different outcomes at once (access created vs. devices admitted). Each issue closed this round is real progress; it tends to be progress on a symptom of one of these three rather than on the shape producing them.

Separately: dedicated-network-accesses.yaml's own Authorization and Authentication text (:16-29) states that three-legged access tokens are mandatory whenever personal data is processed and users can exercise opt-in/opt-out rights, then goes on to exclude three-legged tokens entirely and restrict the device object to phoneNumber only. Those restrictions run counter to the intent of that same text and of the Design Guide's Appendix A pattern for device identification. #130 and #139 already track this.

[hdamker]

FYI: I have updated my restructuring proposal in #168 (comment) to include the accessGroup resource as container for device accesses, including the update of #169.

That is still only a proposal showing how the open topics can be addressed, it does not say if and how it should land.

One thing I would definitely not do: redefining the "access" resource from 0.1.0 into an access container for multiple device without choosing a new name for the newly introduced resource type. "accessGroup" is my proposal in #168, other names would work as well, just not "access" itself.

[tlohmar]

Thanks for the very detailed review.

Reading through the comments, I have two questions for clarification:

An admitted device still has no resource identity of its own – no per-device read, no way to reference "that admission" in a later call.

The current API design uses the device object for identifying the devices (in context of the access resource), i.e. (1) when adding a device to an access, (2) for monitoring states and (3) for removing the device from an access. We currently require, that the phoneNumber is present.

Note, this restriction is because of the current use-cases in focus. Technically, using IP addresses could work similarly, with the restriction that the same IP address information as used during the initial add device operation (1) must also used during (2) and (3) step.

Question: Currently, there are multiple CAMARA APIs, which use the device object for referring to a device. Does your comment mean, that the device object shall not be used for that?

...three-legged access tokens are mandatory whenever personal data is processed and users can exercise opt-in/opt-out rights...

We are currently focusing on B2B use-cases, where the device (incl its subscription) is owned by the same organization, who is acting as API consumer on the accesses API. Our plan is to address B2B2C use-cases in the next release, since we first want to first look deeper into the workflow. It was earlier communicated that it is possible for an API to only support 2-legged AT.

Question: Does your comment mean that a sandbox API like DedicatedNetworks have to fully support 3-legged in its API specification to comply with Design Guide's Appendix A?

[hdamker]

@tlohmar

Question: Currently, there are multiple CAMARA APIs, which use the device object for referring to a device. Does your comment mean, that the device object shall not be used for that?

I'm not aware of any API using the device object as a reference to a resource create for a device.

The device object is a subject identifier to be used to identify a device at resource creation time. It is not suitable to identify the created resource later unambiguous - you mentioned yourself the example with IP addresses which can change over time and not longer allow to identify the same device. Hence the need the created resource need an own resource identifier. Are you aware of any API which is using the device object as address for a created resource? Restricting now to phoneNumber only circumvents some of the problems, but not all (think about that phoneNumber can't be used as a parameter in a GET). But you won't get away from this restriction without a separate resource identifier. Refer to #169 to see how this can work.

Question: Does your comment mean that a sandbox API like DedicatedNetworks have to fully support 3-legged in its API specification to comply with Design Guide's Appendix A?

Yes, as an API is getting this capability for free if following the Design Guide. There is no need to restrict this by design, especially as v0.1.0 has already fulfilled this requirement. Also the introduction of the access(Groups) does not require to drop this requirement, as #169 shows. Refer also to the mandatory " # Authorization and authentication" section within the info.description to get the reason why this is important.

If the capability is utilized in a concrete use case "will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.". The API design must not restrict this agreement without reason.

[tanjadegroot]

The issues #176 and #165 identify that basic test scenarios are missing. Please be aware that main error codes test cases are considered basic (sunny day) scenarios for the API (I agree this is not explicitly documented in Commonalities and should probably be added there.)

The basic testcases should be provided with the release-candidate. I see 2 options:

1. add the missing test case in r2.2 now (this rc.1)
2. add the missing test cases in r2.3 which would be rc.2, and would also include applicable Commonalities r4.4 updates.

A second (very minor) comment is in the changelog file below.

All the rest looks OK.

Please let me know if you want to go for option 1 or 2.

[tanjadegroot]

Creating sub-bullets for the contributor name and issue ref makes the changelog different from all other changelogs, and slightly longer as well.
The request is to use a copy of the relevant provided lines in the working area list above. You can of course add more information in the bullet to help API consumers.
You can update or leave this as-is on this review PR now but I suggest to apply it in future releases.

[tlohmar]

@tanjadegroot , thanks for the feedback.

A PR on the missing error cases (excl Accesses API) (#165) should become available tomorrow. The error cases for the accesses API depend on the yaml corrections, which require a bit more time (thus, a bit later).

A PR on the additional sunny day cases (#176) should also become available soon (also excluding additional Accesses API TCs).

Please advice, whether we should prio creation of an rc.1 pre-release or to prio addressing the issues. Both is fine.

I'll certainly update the CHANGELOG beforehand.

[tanjadegroot]

@tlohmar : I would suggest prioritizing the addition of the above TCs (including the one for Accesses even if a bit later, over publishing the current rc.1. that is more important for the API and fllows the process. Quality over speed :-)

And thanks for adjusting the changelog !
As you will have to do a new snapshot, you can wait with that till then.

[tlohmar]

@hdamker , thanks for the elaborations. See my takes below

Question: Currently, there are multiple CAMARA APIs, which use the device object for referring to a device. Does your comment mean, that the device object shall not be used for that?

I'm not aware of any API using the device object as a reference to a resource create for a device.

The device object is a subject identifier to be used to identify a device at resource creation time. It is not suitable to identify the created resource later unambiguous - you mentioned yourself the example with IP addresses which can change over time and not longer allow to identify the same device. Hence the need the created resource need an own resource identifier. Are you aware of any API which is using the device object as address for a created resource? Restricting now to phoneNumber only circumvents some of the problems, but not all (think about that phoneNumber can't be used as a parameter in a GET). But you won't get away from this restriction without a separate resource identifier. Refer to #169 to see how this can work.

Ok, I understand, that we should / shall not use the Device object as identifier for any remove or get-status operations. Instead, we should create a new ID, which should be used during any subsequent operation. Good clarification.

Question: Does your comment mean that a sandbox API like DedicatedNetworks have to fully support 3-legged in its API specification to comply with Design Guide's Appendix A?

Yes, as an API is getting this capability for free if following the Design Guide. There is no need to restrict this by design, especially as v0.1.0 has already fulfilled this requirement. Also the introduction of the access(Groups) does not require to drop this requirement, as #169 shows. Refer also to the mandatory " # Authorization and authentication" section within the info.description to get the reason why this is important.

If the capability is utilized in a concrete use case "will be agreed upon during the onboarding process, happening between the API consumer and the API provider, taking into account the declared purpose for accessing the API, whilst also being subject to the prevailing legal framework dictated by local legislation.". The API design must not restrict this agreement without reason.

Ok, I understand that we should / shall support for 3-legged ATs (even for sandbox APIs), so that API providers can do a selection based on their needs. We'll prio focusing on use-cases, which require 3-legged ATs (i.e. B2B2C or B2C cases), in order to understand the needed functionality.

[hdamker]

FYI: This snapshot was created before camaraproject/tooling#431 got active with tooling release v0.10.0. #431 moved the automated README Release Information update from the release-review branch onto the snapshot branch. The merge commit above brings this branch in line with that: the README update now lives on the snapshot branch, so this branch differs from it by the CHANGELOG only. No content change.