[Netmod-ver-dt] Proposed updated to Schema-selection draft

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

Sorry, for this being a bit late.

Here are my rough proposed notes on how to update the schema selection draft.  Perhaps we can discuss/refine these today, and hopefully split the work updating the document.

(1) Suggest rename draft to "Model and protocol operations for YANG schema selection"
- The crux of the solution is about selecting schema-sets, which can be version selection, but can cover other stuff as well, e.g. schema families, that are already covered by the draft.

(2) Definitions:
- Should define "schema family", or possibly better in the packages draft?

(3) Update the solution overview:
- Considerable flexibility given to servers on what they can allow clients to select (i.e. primary schema, secondary schema, custom schema)
- Schema-sets are constructed from the union of YANG packages (which must have no conflicting modules/deviations/versions).
   - The schema associated with a particular datastore is the union of the common YANG packages and the per datastore YANG packages.  E.g. a per datatstore YANG package could contain a list of deviations of nodes not supported in that datastore, or it might enable features only in some datastores.
- Schema-sets are advertised as operational data, including whether they can be used as primary or secondary schema, and what compatibility they have with other schema.
- Primary schema: Default schema for the device, schema used to persist configuration, schema chosen if no schema selection is performed.  Primary schema can only be changed for a YANG RPC operation, that can provide an alternative configuration in the new schema.
   - Explain that a configuration in the new schema can be provided, or otherwise the existing configuraiton converted into the new schema (is this best effort, or does it fail if it cannot be converted?)
- Secondary schema: Additional schema that are used in addition to the primary schema.  Secondary schema are selected via capabilities (NETCONF), or path (RESTCONF).  Servers can either automatically support.
  - Possibly the desription of the NETCONF and RESTCONF behaviour should be documented under secondary schema?
- Custom schema:
   - Configured by the client, but once configured also appears in the operational schema-set list alongside server provided schema-sets.
   - Serve two purposes:
     - Allows a client to give schema custom names (i.e. that would be used in secondary schema selection)
     - Allows a client to combine compatible schema together (as a union).  E.g., selecting particular features that need to be supported, or perhaps combining two schema families.

(4) Update NETCONF section (to cover secondary schema selection):
  - Effectively try and make behaviour as close as possible to RESTCONF
  - Server doesn't advertise schema-sets in capabilities (information is available as operational data, but also expected to be known ahead of time).
  - If client wishes to use a secondary schema, then it specifies the schema-sets that it will use.  Connection is closed if the server does not support that schema-set as a primary or secondary schema.

(5) Update RESTCONF section:
  - Primarily only cover secondary schema selection, but client could use schema-set name of the primary-schema which is equivalent to binding to the normal per datastore paths.
  - Uses path based on schema-set name.
  - Add a note tha the schema-set name needs to be encoded (e.g. if it happens to contains the @ symbol).

(6) Update to the new YANG module (obviously)
- Need to decide if the "read-only" flag should be reverse sense (i.e. "writable").

(7) Add and refine the 4 examples that I provided in the appendix.  E.g. for one they are missing XML namespaces, but Bo indicates that it would probably use if the schema family selection example included some actual concrete modules in the different schema families (at least for IETF and OpenConfig)

(8) Add text to an appendix about implementation notes:
- Reiterate that there is considerable freedom on what servers choose to support, i.e. any combination or primary and secondary schemas, and custom schema.
- Talk about filtered schema vs translation (which is requried if the versions are different).

Thanks,
Rob