[Netmod-ver-dt] Meeting minutes [was Today's Ver DT meeting]

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

Points from the meeting what would be good for further discussion.  I think that a lot of these issues are probably still open and require further discussion:


  1.  It is clear that we need to standardize supporting different versions of a schema, but do we also want to support different schema families (e.g. vendor vs IETF vs OC)?
     *    My personal view is that it would be good if the model is general enough that this can be described (and I think that it might be useful if there are some examples given in the appendix).
  2.  For supporting non-native schema, there seem to be two approaches:

                                                    i.     always translate into the native schema, reads from say OC convert back from the native schema

                                                   ii.     store/persist configuration in the external schema (e.g. OC).  E.g. so a get-config on OC would only get back what had been written to the OC schema, not any other schema.

     *   Do we need to describe these two approaches?  For secondary schema does the model need to indicate which method is being performed, or is that purely an implementation detail?
  1.  Can both of the approaches described in (2) above work for different versions of the schema?  Or must these always be handled by dynamic translation.
  2.  What is the schema that the configuration is persisted in?  Should this automatically be tied to the default schema, or should this a separate data node, that could potentially be configurable?
     *   Related to this, how does the system handle changing the default schema?  Can that be done as part of a config request?  Does the connection have to be closed and re-opened?  Or should it be an RPC outside of configuration?
  3.  We need a concise way of describing the relationship between schema and datastores.  The current approach in the model is somewhat verbose, if every datastore needs to be described separately (but is somewhat aligned to YANG library style).
     *   Should we allow schema to only support some datastores (e.g. only operational, or only conventional configuration)?
  4.  Do we need secondary schema to have the ability to be defined or described as only being read-only?
     *   E.g. I can see a requirement to allow a client a configure a device using an older version of the schema.  I can also see a requirement of allowing a client to see what the instance data against a older version of a schema would look like in a more current version.  But I’m less convinced of the need to be able to convert a current configuration back into an older format.

Perhaps we can discuss some of these over email, and try and reach consensus, or otherwise we will pick up discussion in next week’s meeting.

Was there anything else that I missed?

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