Promote disk.io.direction, network.io.direction and system.paging.fault.type attributes to RC

[osullivandonal]

Changes

Promoting the Process metrics to RC is blocked because they reference disk.io.direction, network.io.direction, and system.paging.fault.type attributes, which are still in development.

See Process metrics promotion to RC PR here.

A metric can't be more stable than the attributes it references. This PR promotes those three attributes to RC so the Process metric promotion can follow in the subsequent PR here.

Important

Pull request acceptance is subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above may be automatically rejected and closed.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Links to prototypes or existing instrumentations (when adding or changing conventions)
• Disclose AI usage, see OTel GenAI policy:
  • no AI used
  • AI-assisted
  • bulk AI-generated
• I have the experience and knowledge necessary to understand, review, and validate all content in this PR.¹

Footnotes

1. Yes, I can answer maintainer questions about the content of this PR without using AI. ↩

[braydonk]

We discussed this in the previous System Semantic Conventions meeting June 11, 2026. We are reasonably certain these attributes will not change; all three are strict binary options ("direction" is in or out, there isn't another option) and we're pretty confident no one is going to invent a new type of page fault that isn't "major" or "minor".

[mx-psi]

I do not see an issue with system.paging.fault.type and otherwise based on the discussion from the last System Semconv SIG where we checked the usages of these attributes I think stabilizing these is fine

[joaopgrassi]

@braydonk giving the spark of the network SIG, would it make sense to run these network attributes by the folks that showed interest, just to make sure we don't have problems later on?

[Dipanshusinghh]

Looks like model/system/registry.yaml still has leftover stability: development lines alongside the new rc ones — worth a quick cleanup before merge.

[braydonk]

I have let the current volunteers of the mostly-official Network Semconv SIG know in our CNCF Slack channel.

[osullivandonal]

Looks like model/system/registry.yaml still has leftover stability: development lines alongside the new rc ones — worth a quick cleanup before merge.

Please read the PR description.

This PR only promotes system.paging.fault.type, disk.io.direction, and network.io.direction to release candidate (RC). As these attributes are required to promote Process metrics to RC, see PR here. The other attributes in system/registry.yaml are not related to promoting Process metrics to RC.

[osullivandonal]

@open-telemetry/specs-semconv-maintainers all feedback addressed, could we get this one merged?

[SylvainJuge]

The network.io.direction is currently being used in Java JMX metrics, for example with Tomcat to qualify the in/out network IO on an application server.

From what I understand the definition clarification is meant to exclude usages that would not fit this send/receive dichotomy we have on the interface level, so the current usage in JMX metrics should not be affected even if it's on application/logical level.

Is my understanding correct here ?

[braydonk]

so the current usage in JMX metrics should not be affected even if it's on application/logical level.

This seems fine to me, based on what I can understand of what exactly that metric is supposed to be (I'm Java-illiterate so I may not be 100% getting it). I'm assuming this is the overall send/receive bytes for the application (or whatever a "tomcat processor" is), and not for a specific persistent network connection or anything? Provided that is the case it still seems appropriate. Perhaps we need to loosen the definition slightly to allow for these other appropriate usecases; I know we're trying to keep the attribute out of usage for more complex protocols like netflow that will have specific attributes and measurement guidance that isn't as simple as generic send/receive. But it sounds like we have other appropriate usecases than specifically network interfaces on an Operating System level.

@SylvainJuge Would you be willing to open an issue with a suggestion for how we might be able to reword this description to appropriately cover the usecase JMX has?

[SylvainJuge]

@braydonk

I don't have a better wording to suggest here, so we can leave it as-is. I think that the example values with transmit / receive make it quite clear that in the context of an application it's either receiving or sending data from a logical connection. Maybe the current wording seems directed towards other types of network communication that isn't on this common pattern.