Subject: Re: [Netmod-ver-dt] What does it look like to treat the primary and secondary schema the same

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 30 Jan 2020 14:15:47 +0000

Thx Rob.
Please see below re the bullets in the email.
Jason

From: Netmod-ver-dt <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: Monday, January 27, 2020 11:43 AM
To: [email-masked]
Subject: [Netmod-ver-dt] What does it look like to treat the primary and secondary schema the same

I've updated the model and examples if the primary and secondary schema are logically the same, other than how they are selected (i.e. explicitly chosen by the client or implicit default).  I.e. this is what Jason was suggesting on Thursday's meeting.

- I've updated the schema-selection YANG module to reflect what this might look like.
- I renamed "primary" schema back to "default"
- The default schema can also be explicitly chosen by name[>>JTS: ] That's not new is it? Wasn't the default (previously 'primary') schema-set always in the ro schema-set list?
- I've added a flag to indicate that a schema is "partial", i.e. it does not represent a full configurable schema of the device.  I think that this information is important if we lose the split between primary and secondary schema.[>>JTS: ] I'm not sure I understand this point. Or how a "full configurable schema" is defined (e.g. what about custom dynamic datastores?).
- We should add an explicit statement that writing configuration in any selected schema-set MUST follow standard NETCONF/RESTCONF protocol configuration mechanisms?[>>JTS: ] Why would we need to clarify that? What non-standard behaviour might come out of our work?
- Writing configuration in one selected schema-set MAY modify configuration in a different schema-set (e.g. if two versions of a schema are being used)?[>>JTS: ] Sure - and let's stick with the "two versions" example and not use an OpenConfig example IMO.
- Selectable schema-sets (including the default) may be explicitly configured, or set via the change-schema-set RPC that allows the selectable schema-sets to changed at the same time as providing configuration in the new schema.[>>JTS: ] We should add text to say what happens if the default is changed via config and other config is provided at the same time
  - Servers MUST reject changes to the selectable schema-sets if it would cause non schema-set configuration to change on the device.  However, the change-schema-set RPC can be used to both change a schema-set and update the configuration of the device at the same time.[>>JTS: ] Would like to explore this point more on the call

Stuff that is outside the scope of the specification:
- How configuration is persisted.[>>JTS: ] agree
- What happens if the software on the device is upgraded.

Basically, I think that this could work.  I'm not sure whether this ends up being better or simpler than the previous model + examples.  Thoughts welcome.

See attached for update examples, YANG model and YANG model tree output.

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 30 Jan 2020 14:49:57 +0000

Some comments on the enclosed files...

(A)
The schema selection model is a possibly a bit ambiguous in which list will be available for clients to select from:
i) the rw 'selectable' list, or
ii) the ro schema-set list
I *think* the intention is (i) but that means no schemas are available for selection on a device until the operator configures them into the selectable list. I wonder if we could somehow let a server decide which schemas to make available for selection by default (i.e. define that if the 'selectable' list is empty, the server decides which schemas are selectable ?).

We should define what happens (or what the server is allowed to do) if nothing is configured in this model.

(B)
Are we OK having a config list leafref a ro list? We need to ensure it is impossible that saved configuration suddenly becomes invalid. The "require-instance false" does solve that aspect although can lead to misconfiguration (slightly misspelling the name of a schema-set). I don't have a better suggestion though...

(C)
schema-set, datastore and package associations
Looks like it will work. We may want to explore a few other cases.  One example:
- A common case may be that the conventional DSes + the operational DS support the same package(s) A B C, and then a custom dynamic DS supports a unique package X (which may also be supported in operational). I think that would mean no common-package.
I'm starting to wonder if we really want servers to describe model<->DS associations here in our selection module.  YANG library already describes that association (per module)

(D)
The change-schema-set RPC implies that selecting a set changes the default. But isn't it just selecting the view this particular clients wants to use?  Why would translation be triggered when this selection is made?

Jason

- I've updated the schema-selection YANG module to reflect what this might look like.
- I renamed "primary" schema back to "default"
- The default schema can also be explicitly chosen by name
- I've added a flag to indicate that a schema is "partial", i.e. it does not represent a full configurable schema of the device.  I think that this information is important if we lose the split between primary and secondary schema.
- We should add an explicit statement that writing configuration in any selected schema-set MUST follow standard NETCONF/RESTCONF protocol configuration mechanisms?
- Writing configuration in one selected schema-set MAY modify configuration in a different schema-set (e.g. if two versions of a schema are being used)?
- Selectable schema-sets (including the default) may be explicitly configured, or set via the change-schema-set RPC that allows the selectable schema-sets to changed at the same time as providing configuration in the new schema.
  - Servers MUST reject changes to the selectable schema-sets if it would cause non schema-set configuration to change on the device.  However, the change-schema-set RPC can be used to both change a schema-set and update the configuration of the device at the same time.

Stuff that is outside the scope of the specification:
- How configuration is persisted.
- What happens if the software on the device is upgraded.

Thanks,
Rob