Change system process args from leaf-list to leaf value

[earies]

• (M) release/models/system/openconfig-procmon.yang
  • Type change for process args from leaf-list to leaf
  • Backwards incompatible minor version update to 0.5.0

Change Scope

During analysis of /system/processes/process/state/args it was observed that
implementation behaviors may not correspond to the definition of this leaf.

In the current published 0.4.0 version of openconfig-procmon.yang, args
is a leaf-list calling for implementations to parse the command line arguments
for every running process and pack each into precise elements of the leaf-list.
While this is entirely possible, there is the additional overhead associated
with parsing every PID and the overall usage of such data that should be
considered.

This proposal is for flattening the complexity and returning process cmdline
args as a single string as would be retreived by procfs (for Linux-based
systems)

NOTE: This change is backwards incompatible per YANG specifications however
this is about current shipping implemention behaviors and the usage around this
data

Platform Implementations

• JUNOS/EVO: Currently deviated not-supported
• Arista EOS: Returns single element of leaf-list unparsed as full string
• Nokia SRL: Not deviated, observation is not supported on SRL 25.7.2
• Nokia SROS: Deviated not-supported
• Cisco IOS-XR: Not deviated, unknown runtime behavior
• Cisco IOS-XE: Deviated not-supported

[earies]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

[earies]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

And to kick start some discussion on this

• If process args are encoded as a leaf-list, what use-cases and storage assumptions are there around the receiver side? Will these args merely be concatenated back to a single string? How does a leaf-list benefit in this case?
• For Linux based systems, this data is likely to come from /proc/pid/cmdline ref: https://man7.org/linux/man-pages/man5/proc_pid_cmdline.5.html. In any case, null byte handling is necessary.

Prior art reference from SYSAPPL-MIB:

   sysApplElmtRunParameters OBJECT-TYPE
       SYNTAX      Utf8String          
       MAX-ACCESS  read-only           
       STATUS      current
       DESCRIPTION
           "The starting parameters for the process."
   ::= { sysApplElmtRunEntry 8 }

[romeyod]

@hellt @rgwilton @romeyod @jsterne for comment/review on their respective implementations

And to kick start some discussion on this

• If process args are encoded as a leaf-list, what use-cases and storage assumptions are there around the receiver side? Will these args merely be concatenated back to a single string? How does a leaf-list benefit in this case?

I am not aware of use-case and storage assumptions from the receiver side.

Since Arista EOS returns single element of leaf-list unparsed as full string, it safe to assume some operator might be using this. From a backward compatibility perspective, can we make args a union though?

[earies]

I am not aware of use-case and storage assumptions from the receiver side.

Since Arista EOS returns single element of leaf-list unparsed as full string, it safe to assume some operator might be using this. From a backward compatibility perspective, can we make args a union though?

Well to be fair, you are complying to the data type, just not the description as it is defined today.

I don't think we need the complexity of a union at all here - esp. for a piece of data that is imo mostly going to take up resources w/ potentially not much usage.

If we update the description to comply to EOS current behavior, it negates the necessity of a leaf-list.

If we change this to a singleton leaf, it would be backwards incompatible but EOS could marshal the same as the leaf-list element today.

I'd be curious if there are any other current implementations out there and current behavior.

And is arg parsing really necessary here to be the responsibility of the element publishing the data?

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 4c888d1

[dplore]

Discussed in Feb 3, 2026 OC operators meeting.

I do see that the current leaf-list is supported by multiple implementations. I'm not sure if they are all compliant with the description. We won't make a breaking change for this, but we could deprecate the path and add a new leaf for a single string of the process arguments.

@earies would you like to change this proposal to adding a new leaf?

[earies]

I do see that the current leaf-list is supported by multiple implementations. I'm not sure if they are all compliant with the description. We won't make a breaking change for this, but we could deprecate the path and add a new leaf for a single string of the process arguments.

Do we have any implementations which correctly conform to the leaf-list today? If not then it's not really a breaking change but rather non-conformance and we have 2 options:

1. Implementations fix behavior and conform
2. We change the modeling then conform

I haven't heard of a operational use-case that warrants this should be a leaf-list. If there is, then we stick w/ (1), otherwise (2) sounds like a valid exception to the backwards compatibility rules but could always tag args as deprecated and introduce arguments which is likely confusing to anyone w/o context.

[rgwilton]

@earies, so I have checked XR and we do implement this as a leaf-list today, returning a separate leaf-list entry for each arg. Splitting these to separate leaf-list entries seems reasonable to me, since logically it is a list of arguments and hence a leaf-list represents that quite cleanly.

[earies]

@earies, so I have checked XR and we do implement this as a leaf-list today, returning a separate leaf-list entry for each arg. Splitting these to separate leaf-list entries seems reasonable to me, since logically it is a list of arguments and hence a leaf-list represents that quite cleanly.

Thx @rgwilton. That would be at least 1 justification for us to keep this leaf-list as-is and rather for where folks have not deviated, should fix conformance.

Agreed - the more structured data the better but I'd really like to understand motivations/use-cases for the consumption of this data in the first place (as use-cases are what drive OC modeling efforts) - often this just adds more and more data that will not be used most of the time though higher level subscription paths will reap and cause unnecessary load/processing... essentially an increasing data explosion problem before better formal filtering/targeting methods are in place.

Though this is on the lower end of processing compared to many other scenarios, it is still processing that needs to be done post internal reap of something like /proc/.../cmdline vs. more straightforward marshaling into a single leaf. Every such case should be thought through as it compounds over time (esp. in lists that have potential for high scale).