Hello OpenConfig Team,
I am seeking clarification on the intended behavior of the asterisk (*) wildcard as it pertains to the gNMI specification and the Path Strings convention (gnmi-path-strings.md).
While the 2018 path-string documentation establishes the grammar for paths, there is significant divergence in how vendors implement wildcards across different RPCs. I would like to clarify the following:
-
Wildcard Scope in Read Operations (Get/Subscribe):
Is the * strictly defined as a single-level wildcard (matching one PathElem name or one key value), or is there a scenario where it should be interpreted as a literal instance name? Currently, most implementations treat /interfaces/interface[name=*] as a request for "all instances," but some users find the lack of explicit mention in early documentation confusing.
-
Wildcard Semantics in Write Operations (Set):
The specification is largely silent on the use of wildcards within a SetRequest.
The Problem: Many vendors (e.g., Cisco, Arista) reject * in a Set operation, requiring a fully-qualified path to a specific instance. Conversely, some interpret the "all instances" logic to be theoretically applicable but technically restricted for safety/atomicity reasons.
The Question: Does the gNMI spec forbid wildcards in Set operations to ensure determinism, or is it a matter of implementation preference? Furthermore, is there any case where * should be treated as a single literal instance (i.e., looking for an interface actually named "*"), or is * always a reserved token for a wildcard match?
- Ambiguity in "All" vs. "Single" Instance:
If a client provides a path like /interfaces/interface[name=*], should the target:
A) Return/Modify all instances (Wildcard expansion)?
B) Treat it as a single instance lookup for a key named *?
C) If its need to be treated as single instance, then how a client can query for all instances of interfaces/interface
Clarification on these points would help align client-side tool development (like gnmic) with server-side expectations across diverse network operating systems.
Thanks,
Deepak
Hello OpenConfig Team,
I am seeking clarification on the intended behavior of the asterisk (*) wildcard as it pertains to the gNMI specification and the Path Strings convention (gnmi-path-strings.md).
While the 2018 path-string documentation establishes the grammar for paths, there is significant divergence in how vendors implement wildcards across different RPCs. I would like to clarify the following:
Wildcard Scope in Read Operations (Get/Subscribe):
Is the * strictly defined as a single-level wildcard (matching one PathElem name or one key value), or is there a scenario where it should be interpreted as a literal instance name? Currently, most implementations treat /interfaces/interface[name=*] as a request for "all instances," but some users find the lack of explicit mention in early documentation confusing.
Wildcard Semantics in Write Operations (Set):
The specification is largely silent on the use of wildcards within a SetRequest.
The Problem: Many vendors (e.g., Cisco, Arista) reject * in a Set operation, requiring a fully-qualified path to a specific instance. Conversely, some interpret the "all instances" logic to be theoretically applicable but technically restricted for safety/atomicity reasons.
The Question: Does the gNMI spec forbid wildcards in Set operations to ensure determinism, or is it a matter of implementation preference? Furthermore, is there any case where * should be treated as a single literal instance (i.e., looking for an interface actually named "*"), or is * always a reserved token for a wildcard match?
If a client provides a path like /interfaces/interface[name=*], should the target:
A) Return/Modify all instances (Wildcard expansion)?
B) Treat it as a single instance lookup for a key named *?
C) If its need to be treated as single instance, then how a client can query for all instances of interfaces/interface
Clarification on these points would help align client-side tool development (like gnmic) with server-side expectations across diverse network operating systems.
Thanks,
Deepak