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

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 6 Sep 2019 20:46:34 +0000

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.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 6 Sep 2019 20:53:13 +0000

On Sep 6, 2019, at 16:46, Reshad Rahman (rrahman) <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

One solution that _could_ work for both protocols is username indexing.  That is, you pick a character to delimit the username from the package version.  For example:

jclarke%1.3.1

This has the obvious advantages that you don’t burn TCP port numbers for NETCONF and it would work for both protocols.  A big disadvantage is usernames cannot contain the delimiter otherwise (well, they could if you have rules like if the second portion is not a known version pattern, it treats the whole string as the username).

I don’t know if the WG would accept this, though.

A modified approach do this is to use a different SSH subsystem for NETCONF (e.g., netconf%1.3.1).  This only works for NETCONF, but it doesn’t burn TCP ports.

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Sep 2019 10:06:19 +0000

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 <[email-masked]> On Behalf Of Reshad Rahman (rrahman)
Sent: 06 September 2019 21:47
To: [email-masked]
Subject: [Netmod-ver-dt] Client version selection draft

Hi all,

Regards,
Reshad.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 9 Sep 2019 18:18:47 +0000

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Monday, September 9, 2019 at 6:06 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Client version selection draft

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.
<RR> I agree.

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).
<RR> This requires some thought/discussions.

<RR> Definitely.

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.

Regards,
Reshad.

Thanks,
Rob

Hi all,

Regards,
Reshad.

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 9 Sep 2019 18:30:26 +0000

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.

+1

Joe