openconfig
Clarify `counter64` reset zero value.
* (M) types/openconfig-yang-types.go
- `counter64` defined a reset behaviour that is not common to
all usages of the type. Remove the definition so that each
leaf describes its behaviour for resets if required.
YANG change only -- for counters in the interfaces model, behaviours are defined in the leaf defintions. Other counters do not have this behaviour.
No major YANG version changes in commit 84221841fd6643962fe1cdf7e0a26a03d59c8976
Context: Some users were asking if OC counters are expected to be reset to zero when, for example, a CLI command is issued to reset the counter. This is to clarify that there are no expectations in OpenConfig that a counter value will be reset like this. The only expectation is that the counter will "wrap" back to zero when exceeding the max value.
We welcome any comments on this.
I set last call to 4 weeks from now to give a bit of time for feedback from the community.
Context: Some users were asking if OC counters are expected to be reset to zero when, for example, a CLI command is issued to reset the counter. This is to clarify that there are no expectations in OpenConfig that a counter value will be reset like this. The only expectation is that the counter will "wrap" back to zero when exceeding the max value.
We welcome any comments on this.
LGTM - the typedef should not carry any behavior description of counter resets - the intended behavior is best served in whatever is triggering the reset (e.g. RPC)
Probably want to reset the commit message on merge as well
* (M) types/openconfig-yang-types.go
s/go/yang/
There are a few scenarios where the counter64 can be reset to zero:
- counter wrap.
- direct user action (e.g. clear cli cmd).
- indirect user action (e.g. reboot or restart of a hw/sw component).
- an event that leads to a reboot or restart (hw failures, power failures, sw crash/restart, etc) without user involvement.
In my view, the spirit of the definition is that the values are not expected to be decremented/reset in normal conditions and without a user action to do so.
And one can argue that the current text places points 2-4 into the letter of the definition as well. The text allows the existence of methods to implement point#2, but it does not require and does not mandate it. I don't have a strong opinion on whether this belongs to the typedef definition, but even if it's not mentioned, points 3 and 4 will be applicable.
Also, to respond to the Darren's comment:
Context: Some users were asking if OC counters are expected to be reset to zero when, for example, a CLI command is issued to reset the counter. This is to clarify that there are no expectations in OpenConfig that a counter value will be reset like this. The only expectation is that the counter will "wrap" back to zero when exceeding the max value.
I don't think this should be covered by OpenConfig models in general. If an operator uses OC models and OC-defined protocols (e.g., gNMI/gNOI/...), then there is no such cli for them.
And if they're using a vendor-proprietary cmd to do something, then it is up to the user and the vendor to define the behavior.
But as I already indicated in the comment above, my interpretation is that the current text allows this behavior, but does not require it.
Also, to respond to the Darren's comment:
Context: Some users were asking if OC counters are expected to be reset to zero when, for example, a CLI command is issued to reset the counter. This is to clarify that there are no expectations in OpenConfig that a counter value will be reset like this. The only expectation is that the counter will "wrap" back to zero when exceeding the max value.
I don't think this should be covered by OpenConfig models in general. If an operator uses OC models and OC-defined protocols (e.g., gNMI/gNOI/...), then there is no such cli for them. And if they're using a vendor-proprietary cmd to do something, then it is up to the user and the vendor to define the behavior.
But as I already indicated in the comment above, my interpretation is that the current text allows this behavior, but does not require it.
The new, proposed text is ambiguous if there are any other reasons the counter might reset. It only specifies the rollover condition. My interpretation is that if the description doesn't permit a behavior, then it is not allowed.
However, leafs which use this type (as pointed out in other comments in this PR) may impose additional conditions such as https://github.com/openconfig/public/blob/72d3b679c5081340da079af4db87643a55a16ebd/release/models/interfaces/openconfig-interfaces.yang#L747-L761 which explicitly says the counter may be reset for 'various' reasons and has an accommodation for last-clear as Ebben pointed out. (I am dating myself by saying this, but in SNMP the equivalent is ifCounterDiscontinuityTime).
@dplore @robshakir ,
Just going back over this one I think that there are two changes that should probably be made before the final call merge:
(1) As per Ebben's comment, aligning the language between the 32 and 64 bit versions of the counter makes sense (i.e., loop vs reset). (2) As per my comment on Aug 7, add a suggestion to the description (or just as a comment in the YANG file) indicating that data nodes using these counter types should specify what discontinuities may occur, and how they are reported (if at all).
I'm not sure this should be in the last-call, it appears there are a few different takes on the new text.
Darren states that
My interpretation is that if the description doesn't permit a behavior, then it is not allowed.
If that's the purpose of the change, I wouldn't support this due to reasons I mentioned in the comment https://github.com/openconfig/public/pull/1154#issuecomment-2253332908
Additionally, Rob wanted to make a change based on the comment from Robert https://github.com/openconfig/public/pull/1154#discussion_r1707097126 (with a different interpretation of the proposal), which didn't happen yet.