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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Reshad,

My instinct is that clients will mostly want to interact with a network device just using a single package version.  Hence really the version selection is about choosing which schema family (native, ietf, openconfig) to use and also which particular version of the schema to use.  Once a schema has been chosen then I expect it to be available on the standard port/path (which I think raises the question that if you change the default schema to something else, then how do you change it again, or reset it back to the default.  This probably needs a RPC to be defined).

It is also possible that clients may want to configure some classes of features on devices using a particular schema (e.g. perhaps using a native schema if there is no support in OpenConfig/IETF).  If the draft supports anything like this then it might also need to provide some guidance about how configuration is combined, how it is validated, particularly if it conflicts.

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).

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.


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.

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.

Thanks,
Rob


From: Netmod-ver-dt <[e-mail]> On Behalf Of Reshad Rahman (rrahman)
Sent: 06 September 2019 21:47
To: [e-mail]
Subject: [Netmod-ver-dt] Client version selection draft

Hi all,

The draft<https://datatracker.ietf.org/doc/draft-wilton-netmod-yang-ver-selection/> has 2 schemes for clients to select version:

  *   Via port number (port maps to schema-set). This works for both NETCONF and RESTCONF

  *   Via root-path (root-path maps to schema-set). This works for RESTCONF only.

Would like to hear from the DT on  this, more specifically:

  1.  Any other directions we should investigate as a solution for this? E.g. new NETCONF RPC (or updating capability exchange somehow)?
  2.  How important is it to have the same scheme work for both NETCONF & RESTCONF?
  3.  Any concerns if we have more than 1 solution per protocol? The WG will have a big say in this obviously.

Regards,
Reshad.