YANG Atomic extensions and behavioral expectations

[earies]

While there is still unmerged work and discussion surrounding YANG atomic extensions here: #1330

As well as prior discussion on the relationship between the YANG atomic extension and gNMI atomic field here: openconfig/gnmi#180

If we use the OC AFT modeling as an example of atomic datasets

• There is 0 mention of atomic behavior expectations from a gNMI specification perspective
• These datasets are not marked as oc-ext:telemetry-on-change (Similar to what is described in Tighten up YANG node and ON_CHANGE expectation relationships #1375)
• There is no description of expectations should one choose to query/subscribe to a subset of data under an atomic marked container/list

The intention of this issue is to spark discussion to come to consensus on expectations when

• Subscriptions target subsets of data under atomic flagged content (deliver subset, error, or entire atomic flagged content)
• YANG containers/lists are marked as atomic, agreement that this corresponds to a case when gNMI marks atomic = true

[ncorran]

Cisco-XR has implemented OC-AFT on-change, with support for 'atomic' (in at least some of the meanings of atomic and ignoring the telemetry-on-chage gap, as per comments on the linked PR).

I'll cross-check our interpretations and see how that fits with this and linked discussions and update back here.

[dplore]

Related PR for gnmi specification update: openconfig/reference#229

[romeyod]

My 2 cents on Subscriptions target subsets of data under atomic flagged content (deliver subset, error, or entire atomic flagged content):
Delivering a subset opens us to various other scenarios. For example: Suppose client subscribes with on-change stream mode to a subset of atomic container, what happens when another leaf in the atomic parent container changes: do we stream the target subsets of data again or not? Is the atomic nature of atomic flagged parent container applicable to subsets in this case? Are the subset to be marked as atomic in the notification?

IMO returning an error will make this use case less over engineered (simple) and deterministic.

[ElodinLaarz]

Discussed at OC Operators Meeting on Feb 24, 2026:

We should add some documentation to address the specific bullets given here, as well as turning the points laid out in the PR description into some proper documentation.

I can set aside some time next week to write something up. If I don't, someone can ping me :)

[ElodinLaarz]

openconfig/reference#237

Proposed some documentation changes to discuss.