Re: [Netmod-ver-dt] Version selection

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

Hi Reshad,

Hum, it seems that my comments may have caused some confusion …

Please see inline …

From: Reshad Rahman (rrahman) <[e-mail]>
Sent: 23 October 2019 23:25
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Subject: Re: Version selection

Hi Rob,

Thanks for the detailed response, inline. Looks like we’ll be discussing these points during the meeting.

From: "Rob Wilton (rwilton)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, October 23, 2019 at 9:13 AM
To: "Reshad Rahman (rrahman)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: Version selection

Hi Reshad, all,

Personally, I think that the number one requirement here is allow a device to be configured such that the entire device uses a particular schema family at a particular version.
[RW]
Note, I’m not saying that the current model doesn’t already cover this, only trying to emphasize that this is the requirement that I think is most important, most likely to be used, and hence want to ensure that the solution covers this in an easy way.

<RR> So basically what default-schema-set does (but probably with something else than schema-sets)? I agree.
[RW]
Yes, I agree that this is something like “default-schema-set”.


<RR> One schema family at a particular version or multiple schema families each at their version? E.g. let’s say we have  2 schema families (vendor and IETF), so  e.g. top-level schemas are example-ietf-routing-top and example-vendor-xxx-top, are you suggesting we need to select one schema family or the other but not both? Some implementations may support 1 schema family at a time, others may concurrently support multiple schema families.
[RW]
I think that the ideal goal is that clients will use one version of one schema family to configure their device.

Pragmatically, it is plausible that some features may only exist in some schema, so in the short/medium term I think that there is a need to allow multiple schema families to be used in the same session (and probably also during boot).

However, I don’t think that we need to allow clients to support multiple versions of a schema family in a particular session.

Also, even if a device supports multiple schema families for configuration, it is plausible that a client might want to restrict


<RR> Also, when you say “configured”,  so we have config for default schema/version(s) and that can be overridden per “session” via the NETCONF/RESTCONF mechanisms? This is the equivalent of default-schema-set then?
[RW]
Yes.


Ideally, I would like the selection of this schema be written into configuration, and to be able to boot from this configuration (which may mean that I want the schema selection YANG module to be able to exist in all schema families).
<RR> If this config is for default behaviour, I agree.
<RR> I had thought about the schema selection YANG module needing to be in all schema families, that could be problematic. Instead of that, can we have a schema-family just for YANG version selection?
[RW]
Yes, having a separate schema family might be a good solution here.  Effectively it is a bit like meta configuration anyway.


Regarding schema-sets, the issue that this was trying to solve is that a device may use slightly different schema for different datastores (e.g., perhaps most plausibly, the schema for <operational> may have deviations that don’t apply to the conventional configuration datastores), but the server may require clients to always use consistent schema for the configuration vs operational datastores.

However, RFC 8342 has this text:

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores,
   except that configuration data nodes supported in a configuration
   datastore MAY be omitted from <operational> if a server is not able
   to accurately report them.

I think that this effectively means that a device must have a single logical schema that is superset of all datastore schema.  Datastore schema are effectively allowed to choose subsets of that schema.
<RR> Is the superset schema the combination of all schema families or 1 superset schema per schema family? If it’s the latter (which seems to be the case from your example below), how does the superset package differ from top-level package for a schema family? Or is it the same thing?
[RW]
I think that it is latter, i.e. one superset schema per schema family.

I think that a superset schema probably ends up being the same as a top-level package.

Packages just define a schema.  That schema might only apply to a particular datastore, or that schema might apply to the device, effectively constraining what the per-datastore schema can look like.

Normally, I think that a client wants to choose a package that applies to all datastores, and hence they want to choose a superset schema package.  Of course, it could also be the case that all datastores use the same schema.

Maybe we also want to allow a client to specify a schema only for one datastore, in which case I think that they would be wanting to choose a package that relates to a datastore schema rather than a device schema.  (E.g. a client might want to read a subset of the operational data using an OpenConfig schema.  Whether this makes and sense, and whether this is feasible is unclear to me).  Potentially, we should defer this consideration at this time, and just focus on choosing superset schema.


Given this, it is plausible that we don’t need schema-sets (or at least they can be renamed/repurposed), and instead we can rely on a device defining a package definition for the “superset schema”, which will implicitly select the appropriate package to be used for each datastore schema.  E.g. perhaps the package for the superset schema is example-ietf-routing-pkg@2.1.0<mailto:example-ietf-routing-pkg@2.1.0> and then the conventional configuration datastores use the package “example-ietf-routing-cfg-pkg@2.1.0<mailto:example-ietf-routing-cfg-pkg@2.1.0>” , and the operational state datastore uses “example-ietf-routing-state-pkg@2.1.0<mailto:example-ietf-routing-state-pkg@2.1.0>”.  Only the superset packages are advertised in the capabilities.  For devices that are fully compliant with NMDA, then it is plausible that they will use exactly the same schema (and hence package) for all configuration datastores and operational.
<RR> I agree that only the superset packages (which I understand to be same as top level packages) should be advertised in capabilities, that was the plan.
[RW]
OK.

I think that this will cover the mainline case, where a client only wants to use one schema for all connections, and they just want to be able to choose the family and version of the schema that they are using to control the device.
<RR> So the superset package+version is the default schema/version pair then?
[RW]
Actually, I’m going to row back on this point.  I suspect that it might be one version per supported schema family.  So clients may want to choose which schema families that want to use, and also which versions of those schema families they wish to use.



The second use case, is where a vendor may want to allow different clients to interact with different schema families, or different schema versions at the same time (e.g. on separate connections).  I see that for this mechanism the RPC is probably the best way to go for NETCONF, and the path is the best way to go for RESTCONF.

Based on the text about, my suggestions are:

(i)     Define “datastore superset schema” as the schema that is a superset of all datastore schema (yes, we may need better names here).

(ii)   Define “datastore superset package” as the associated YANG package that defines the “datastore superset schema”.

(iii)  Perhaps rename schema-sets (or at least the per datastore parts of them) (see below)

(iv)  Update the ietf-schema-version-selection YANG model:

o   Perhaps rename “schema-sets” to “schema-superset”:

§  Change to be read-only

§  Do we need to advertise the restconf root path, or can then just be done via using “<package-name>@<version>” in the path?

§  Probably change the list to be keyed by (package name, package version)

·       The package here is both the superset package and also the default package/version used for each datastore unless a more explicit entry is listed in the datastore list.

o   Keep the configurable “default-schema-set” leaf, but perhaps rename it.

<RR> Let’s discuss in the meeting.
[RW]
Ack.

Thanks,
Rob


Regards,
Reshad.


Thoughts?  You may want to discuss some of this first before jumping into making changes?

Thanks,
Rob


From: Netmod-ver-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Reshad Rahman (rrahman)
Sent: 22 October 2019 19:47
To: [e-mail]<mailto:[e-mail]>
Subject: [Netmod-ver-dt] Version selection

Hi all,

Here’s take 1 of the client version selection draft update, I still need to add text, review text etc based on what we agree on. Here are some questions and open items, we need to close on some of those before I send next revision. I’ll track issues in github subsequently.

1.     Use of schema-sets? In the previous version we had config for both NETCONF/RESTCONF using schema-set via port and root-path. We’re now using capability and new RPC/operation for NETCONF, and these work on YANG packages which are in YL (packages draft). I’m proposing that we remove schema-sets for now (for simplification), and have the version selection draft use “top level packages”.

2.     If we keep schema-sets,  the YANG model has been updated to have a schema-set consist of a list of YANG packages. The question then is whether we want schema-sets to be configurable by the user or not.

3.     NETCONF experts please take a look at the NETCONF update.

4.     I’ve used @ as the separator for YANG package and version, e.g. example-ietf-routing@1.3.1<mailto:example-ietf-routing@1.3.1>, this is because @  cannot be in the revision-label and looks like it can’t be in the package-name either (pkg-identifier is of type yang:yang-identifier)

5.     Joe had raised the issue of default package version if none is selected. Any suggestions on how to advertise the default version(s) in capabilities, what about @D after the revision-label e.g. “example-ietf-routing@1.3.1<mailto:example-ietf-routing@1.3.1>@D”? Rob, I don’t think your YL extensions has default for YANG package versions right now?

Regards,
Reshad,