Re: [Netmod-ver-dt] Version selection

["Reshad Rahman (rrahman)" <[e-mail]>]

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]>
Date: Wednesday, October 23, 2019 at 9:13 AM
To: "Reshad Rahman (rrahman)" <[e-mail]>, "[e-mail]" <[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.
<RR> So basically what default-schema-set does (but probably with something else than schema-sets)? I agree.
<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.
<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?

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?

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?

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” , and the operational state datastore uses “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.

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?


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:

  1.  Define “datastore superset schema” as the schema that is a superset of all datastore schema (yes, we may need better names here).
  2.  Define “datastore superset package” as the associated YANG package that defines the “datastore superset schema”.
  3.  Perhaps rename schema-sets (or at least the per datastore parts of them) (see below)
  4.  Update the ietf-schema-version-selection YANG model:
     *   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.
     *   Keep the configurable “default-schema-set” leaf, but perhaps rename it.

<RR> Let’s discuss in the meeting.

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]> On Behalf Of Reshad Rahman (rrahman)
Sent: 22 October 2019 19:47
To: [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,