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

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 4 Feb 2020 17:15:09 +0000

Slightly late minutes from the meeting on Thursday.

We spent most of the session discussing some of the points raised by Jason.  I think that we mostly found agreement except on the last point (the RPC).

I've included [RW] comments inline below, that I hope reflects the conclusion of what was discussed, and in some cases agree, in the meeting:

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Sent: 30 January 2020 14:50
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: RE: What does it look like to treat the primary and secondary schema the same

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 ?).
[RW]
NMDA architecture means that this is okay, the selectable schema are from what is represented in the "selectable" list in the operational datastore:

This was discussion, but no clear conclusion on how explicitly configured and system defined selectable schema-set lists are merged together, the two choices appear to be:

  1.  The list of configured selectable schema-sets replace the list of system created selectable schema-sets.
  2.  The list of configured selectable schema-sets is merged with the list of system created selectable schema-sets.

This behaviour could be left undefined, and hence up to the implementor, or it could be defined in the specification.
The conclusion was to open an issue for this (https://github.com/netmod-wg/yang-ver-dt/issues/36)

[RW]
As for the default selectable schema-set.  If the version selection YANG model is supported, then the selectable list in operational MUST contain the default schema.

(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...
[RW]

  *   This would be question for Martin/WG?

But a subsequent email from Reshad seems to indicate that this is allowed (because require-instance is false).

(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.
[RW]
Should add some text to explain why the datastore association is here and not in the packages draft.  Only servers can choose which datastores support (hence should be here and cannot/should not be in the packages draft).  The schema selection draft should also be usable off the box, making use of the YANG instance data draft.

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)
[RW]
There was a discussion about how to best model the fact that different datastores can have different schema.

Choices seem to be:
1. Don't have common, each datastore defines it schema, more repetition.
2. Keep as is (i.e. have a common + per datastore additions), but this forces more verbosity if one datastore doesn't use the common modules (e.g. like a custom dynamic datastore)
3. Add exception flag.  I.e. the list of schema-sets for the datastore doesn't include the common schema-sets.
4. Have multiple top level lists of "common" and "per datastores", e.g. allowing the common sets for datastores to be extracted out, but still retains the flexibility.

Current proposal was to track as an issue, but leave this as is for WG adoption. (https://github.com/netmod-wg/yang-ver-dt/issues/37)

(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?
[RW]
Fix the name of the RPC ("change-selectable").

We didn't reach consensus on why this RPC is necessary, and further discussion is required.

Thanks,
Rob

Jason

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Wilton (rwilton)
Sent: Monday, January 27, 2020 11:43 AM
To: [email-masked]<mailto:[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
- 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.

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