Re: [Netmod-ver-dt] Client version selection draft

["Joe Clarke (jclarke)" <[e-mail]>]

The third scenario, that I can envisage for devices, is the case where some monitoring software might want to use a different schema across multiple vendors.  Long term, I would hope that this monitoring data would be telemetry/push based.  I think that means that whatever solution we come up with for version selection also needs to work in YANG push (dynamic and static subscriptions).
<RR> Definitely.

These types of flows will be interesting to discuss.  One reason I like the RPC option for NETCONF is it will work with call home.


The other scenario to consider would be a config controller or orchestrator.  I can see that such a device might well want to offer different schemas and schema versions at the north bound APIs, and expect to interact with south bound devices supporting different schema and schema versions.
<RR> We haven’t discussed this in the past but yes the schema selection should apply to any kind of device.

Regarding differences between NETCONF and RESTCONF, I think that is OK, and is aiming to play to both of their strengths.  I.e. for RESTCONF, a path based solution seems like a naturally good fit.  For NETCONF, I’m less sure what is the best approach.
<RR> The path solution for RESTCONF is pretty neat, the only drawback is it requires updating RFC8040, so we should discuss with Andy.

I’m also not sure whether having more than one solution per protocol is good idea.  My hunch is that initially we should try and come up with a single solution per protocol.
<RR> I’d rather not have multiple solutions either. If we do go with multiple solutions, we have to pick 1 mandatory one per protocol.

+1

Joe