You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The gNMI Specification section 3.3 (Retrieving Snapshots of State Information) specifies that the client MAY use wildcards in the Path. Section 3.4 (Modifying State) does not mention wildcards in the Path at all. Shall this be interpreted as no support of wildcards in SetRequests?
Example:
Imagine a gNMI client sending an OpenConfig-Interfaces update set operation with the request path /interfaces/interface[name=*]/subinterfaces[index=10]/enabled:false. Should this request be interpreted as disabling the subinterface with index 10 in all the interfaces in the device or should it trigger an error?
The text was updated successfully, but these errors were encountered:
Today, we don't explicitly require that paths in a SetRequest are fully resolved -- indeed, we allow them specifically for delete cases. There's clearly some complexity with handling this case though - and I'm not quite sure that its utility is worth incurring that complexity.
Do you envisage that this is a common operation that you expect users to need to support? @aashaikh@gcsl - do you have thoughts on whether this is something that we should clarify?
The gNMI Specification section 3.3 (Retrieving Snapshots of State Information) specifies that the client MAY use wildcards in the Path. Section 3.4 (Modifying State) does not mention wildcards in the Path at all. Shall this be interpreted as no support of wildcards in SetRequests?
Example:
Imagine a gNMI client sending an OpenConfig-Interfaces update set operation with the request path
/interfaces/interface[name=*]/subinterfaces[index=10]/enabled:false
. Should this request be interpreted as disabling the subinterface with index 10 in all the interfaces in the device or should it trigger an error?The text was updated successfully, but these errors were encountered: