gnmi on-change clarification

[osquitun]

Provide clarification to On Change for STREAM Subscription in section 3.5.1.5.2 to exclude rapidly changing counter types and only stream updates on the initial subscription and at the heartbeat interval if it has been specified.

[LimeHat]

Could you elaborate on the reasoning for this change?

It seems that the scenario you have in mind is already covered by the target defined mode:

reference/rpc/gnmi/gnmi-specification.md

Lines 1634 to 1640 in 95392c1

	- **Target Defined `(TARGET_DEFINED)`** - when a client creates a subscription
	specifying the target defined mode, the target MUST determine the best type
	of subscription to be created on a per-leaf basis. That is to say, if the
	path specified within the message refers to some leaves which are event
	driven (e.g., the changing of state of an entity based on an external
	trigger) then an `ON_CHANGE` subscription may be created, whereas if other
	data represents counter values, a `SAMPLE` subscription may be created.

I don't agree that this can be considered "a clarification". This is a significant change in the behavior.

with the exception of rapidly changing counter types. Counter type values SHOULD be transmitted upon the initial subscription update and at each heartbeat_interval if one is specified.

What's the definition of a "rapidly changing counter type"? How can it be distinguished from other counter types?

[osquitun]

The reasoning is that TARGET_DEFINED is left to the vendor to determine the best type of subscription. Comparison of vendor implementations have shown a difference in view of which type of subscription should be used. The use of ON_CHANGE avoids the ambiguity and vendor implementation for type of subscription.

The current ON_CHANGE description does not indicated the behavior if there is a mix between leaves suitable for event based update and counters. For example an ON_CHANGE subscription to /interfaces/interface/state would include the counter container within the hierarchy. The counter performance leaves are only desired on SAMPLE basis. This is an obvious scenario, but in some cases there is no counter container and some mix of event leaf and counter items are present within the same container.

Some vendors already behave as described while others do not provide ability to subscribe with ON_CHANGE as a result and have create issues with their choice of implementation of type of subscription with TARGET_DEFINED.

Changing in wording to remove rapidly is fine to cover any counter that should be sample based.

[LimeHat]

The current ON_CHANGE description does not indicated the behavior if there is a mix between leaves suitable for event based update and counters.

What do you mean by that? IMO, the current definition of on_change is straightforward and unambiguous: there are no cases where an implementation can switch to another mode implicitly.

The counter performance leaves are only desired on SAMPLE basis.

In many cases, yes, This is when you should use SAMPLE or TARGET_DEFINED to subscribe :-)

but in some cases there is no counter container and some mix of event leaf and counter items are present within the same container.

And in that case target_defined works well, if one has a good implementation.
If target_defined implementation of a vendor is not sufficient, you can use selective subscriptions to specific leafs with different modes. You can even combine them in a single SubscriptionList.

Changing in wording to remove rapidly is fine to cover any counter that should be sample based.

I disagree with that idea as well. Your proposal eliminates the ability to use a true ON_CHANGE mode for counters. There are legitimate use cases for this functionality; even if it might not apply to your use case.

In my view, you should be looking to add a new subscription mode if you want to have this implemented properly and have a solid argument as to why TARGET_DEFINED is not sufficient.
Or you can propose an extension for TARGET_DEFINED mode that will allow you to fine-tune its parameters beyond the current capabilities.

The current proposal is a non-backward compatible change to the definition of the ON_CHANGE, and that's not great.