Re: [Netmod-ver-dt] Today's Ver DT meeting

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

A slightly more complex example is attached.

Thanks,
Rob


From: Netmod-ver-dt <[e-mail]> On Behalf Of Rob Wilton (rwilton)
Sent: 09 January 2020 14:11
To: [e-mail]
Subject: [Netmod-ver-dt] Today's Ver DT meeting

Happy New Year!

From the last meeting I did say that I would work on producing some concrete examples of version selection 😊

I’ve started working on this, but more work is required.  I have attached one example that we can discuss in the meeting, more may be forthcoming before the meeting.

As part of that work, I’ve been thinking more about the default/secondary schema.

As a recap, I think that this is roughly where I am at:


  1.  The default schema:

     *   is the schema that is used if a client doesn’t specify a secondary schema during their connection (i.e. NETCONF capabilities negotiation, or RESTCONF path).
     *   is also the schema used for the persistent configuration (and the <startup> datastore). [I think that this is probably right, but might need further thought/discussion]


  1.  Secondary schema:

     *   are additional schema that clients can choose to use, and are specified during their session (i.e. NETCONF capabilities negotiation, or RESTCONF path).
     *   can probably take several forms:

        *   A filtered view on the default schema (e.g. if the default schema supported vendor native + IETF + OC schema) then a filtered schema view might just be the OC subset.  This should be simple to support since it broadly equivalent to a subtree filter on any get operations.
        *   A translated view on the default schema (e.g. perhaps a different version of a schema),  All reads/writes to a translated schema are converted to/from the default schema.  The configuration is persisted in the “default schema”.

     *   It might be useful if some of the secondary schema could be labelled as read-only views on the data.  E.g. it might be reasonable to see the configuration using a secondary schema non native version, but not allow it to be modified.

Attached example:

Example 1, a simple example of a server supporting two schema versions, and the client can choose between which version is used for the primary schema.

  *   One question related to this example is what happens to the current configuration if a client changes the default schema to a different version.  Does that configuration also automatically get translated as well?  What happens if that translation fails?
  *   Do we need a simpler way to reporting the per datastore schema?  E.g. should we have a special value to identify all datastores, or all conventional datastores?

Thanks,
Rob