Subject: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 24 Feb 2020 16:46:27 +0000

Hi,

I would like to get an updated version of the schema selection draft posted by Friday if possible.

These are the areas that we should fix before we publish:

  1.  Sec 5: Expand RESTCONF description (5.4.2).  E.g. define the path that is used.
  2.  Sec 6: Fix description of RPC operation:
     *   Also resolve the definition of the RPC in the YANG module (as per Jason's comments).  Perhaps remove the choice & translate leaf, and just have an optional replacement-config?
  3.  Sec 10: Fixup text in front of YANG module (e.g. it still uses primary/secondary)
  4.  Prune references
  5.  Clean up example text.

Does anyone else have any other areas that they think we need to fix?  I've noticed a few other typos that could do with fixing, but will just update these.

Nice to have (which I propose deferring):

  *   Perhaps define "Package schema" instead of redefining YANG schema for RFC 7950.
  *   Also define "Partial datastore schema"

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 25 Feb 2020 13:42:13 +0000

Hi Rob,

  1.  I think it’d be good if we removed all TODOs and track them with issues.
  2.  Regarding “YANG schema” v/s “package schema”, when you say deferred I’m assuming you mean post adoption call?
  3.  Does section 5.4.1 (NETCONF) need to be updated too or are we keeping the capability as currently defined? I forgot whether we discussed this.
  4.  Regarding schema-set version, is it supposed to be included in the name?
  5.  Why do we need to specify “old” in the RPC? Is the server supposed to validate that input?

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]> on behalf of "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Date: Monday, February 24, 2020 at 11:46 AM
To: "[email-masked]" <[email-masked]>
Subject: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi,

     *   Also resolve the definition of the RPC in the YANG module (as per Jason’s comments).  Perhaps remove the choice & translate leaf, and just have an optional replacement-config?

Does anyone else have any other areas that they think we need to fix?  I’ve noticed a few other typos that could do with fixing, but will just update these.

  *   Perhaps define “Package schema” instead of redefining YANG schema for RFC 7950.
  *   Also define “Partial datastore schema”

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 25 Feb 2020 13:52:34 +0000

Comments on schema selection.  We should probably focus on E & F. The main big open point IMO is around the RPC(s).

(A)
We should probably put a more specific reference to a document (and version) for this statement in the abstract:
   This draft provides a solution to YANG versioning requirements 3.1
   and 3.2.

(B)
Section 1.  Is this correct where we say "one" for each DS?
   o  schema-set: A set of related versioned YANG schema, one for each datastore that is supported.
That is probably reasonable but it doesn't really match the YANG model where a "schema-set [name]" is comprised of multiple datastores and the packages for each of those datastores.
When a client selects a schema-set I think they are really selecting schemas for all datastores (and I don't think we should get into allowing any selection of the schema or schema-set for one DS at a time).
Section 5.2 bullet #2 describes schema-sets in a better way IMO.

(C)
Section 4, replace "replacing the devices default" with "replacing the device's default"

(D)
Section 5 bullet 3 replace "used by clients do" with "used by clients that do"

(E)
Section 5 bullet 6, and other places -> I'd propose we replace the change-selectable-schema RPC with this RPC:
- change-default-schema (with an option to provide new replacement config)
If a session wants to change the schema *they* are using, then they must reconnect and negotiate a new schema during capability exchange.  They could then download a full config if they wanted (in the new schema).
We don't need special RPCs to allow clients to change the 'selectable' list. Changing that list doesn't affect the actual schema in use by any sessions.

(F)
Section 6 - I think we need to rework this a fair bit.
Do we really want to allow a session to change its schema in the middle of the session? Or will we force it to reconnect?
We have a mix of 'select-schema-set' and 'change-selectable-schema' in the draft.
Do we actually want to allow selection of multiple schema-sets? That seems to go against our definition of a schema-set being all the schemas for all datastores.  And is against what is described in section 8  "...is to one particular schema-set"
Does changing the default schema (e.g. via RPC or via normal config) change the schema in use for active NETCONF sessions? I assume not but then must a server continue to service those old sessions?  Maybe it is allowed to disconnect them?

(G)
Section 7 mentions stateful mappings. I agree. Do we leave persistence to vendor implementation?

Jason

From: Netmod-ver-dt <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: Monday, February 24, 2020 11:46 AM
To: [email-masked]
Subject: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi,

  1.  Sec 10: Fixup text in front of YANG module (e.g. it still uses primary/secondary)
  2.  Prune references
  3.  Clean up example text.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 25 Feb 2020 22:52:46 +0000

Hi all,

Regarding d) below, let’s say we I have an “ietf” schema-set which consists  of packages “ietf-infra”, “ietf-l2” and “ietf-l3”. Each of these packages can be referenced by version. But how do we distinguish IETF schema-set which uses v2 of each package compared to IETF schema-set which uses v1 of each package? Are we expected to include the version in the name e.g. IETF@V1 and IETF@V2? Why not add a version to the schema-set? I have no recollection of discussions on this.

Also regarding schema-set definition, does that mean 1 versioned schema (e.g. YANG package) per DS? Or am I misunderstanding this.

Regards,
Reshad.

   o  versioned schema: A YANG schema with an associated YANG semantic
      version number, e.g., as might be described by a YANG
      package[I-D.rwilton-netmod-yang-packages].

   o  schema-set: A set of related versioned YANG schema, one for each
      datastore that is supported.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]
           |  +--ro name         ds:datastore-ref
           |  +--ro read-only?   empty
           |  +--ro package* [name version]
           |     +--ro name        -> /pkgs:packages/package/name
           |     +--ro version     leafref
           |     +--ro checksum?   leafref

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tuesday, February 25, 2020 at 8:42 AM
To: "Rob Wilton (rwilton)" <rwilton=[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Rob,

Regards,
Reshad.

Hi,

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 25 Feb 2020 23:07:40 +0000

Some further misc. comments on the draft:

################
(O.1)
- in section 4, replace this bullet:

   o  To closely align with existing NETCONF/RESTCONF protocol
      semantics.  I.e., with the exception of the new mechanisms
     required to select the schema-set at the beginning of NETCONF
      session or RESTCONF request, protocol interactions between client
      and server are the same as when schema selection is not being
      used.

with this:

   o  To closely align with existing NETCONF/RESTCONF protocol
      semantics.  I.e., with the exception of the optional new mechanism
     that allows selection of the schema-set at the beginning of a NETCONF
      session or RESTCONF request, protocol interactions between client
      and server are the same as when schema selection is not being
      used.

################
(O.2)
- in section 5, list item 3, remove the comma between "schema-set" and "used"  in "...the default schema-set, used by..."

################
(O.3)
- in section 5, remove list item 6

################
(O.4)
- I think perhaps the "leaf-list combinable" should be removed. A schema-set describes all datastores and their schemas. I'm not sure what it then means to combine schema-sets. Is this left over from when we thought schema selection could select multiple schemas in parallel (e.g. the old "select-schema-sets" in section 6.1) ?
But this also calls into question the "included-schema" leaf-list in "list custom". It allows multiple schema-sets (each of which could be selected on their own by a client).

################
(O.5)
- I don't think this is correct in A.1:

   Modifying the devices default
   schema means that this will be the schema version that all clients
   see, is the schema version used for persisted configuration (e.g.,
   written to the startup datastore), and will be used for the datastore
   schema reported in YANG library.

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, February 25, 2020 8:53 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]>; [email-masked]
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

(A)

(B)

(C)

(D)

(E)

(F)

(G)

Jason

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Wilton (rwilton)
Sent: Monday, February 24, 2020 11:46 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi,

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 11:09:31 +0000

Hi Reshad,

I was assuming that the version would be held in the name, i.e. the name of your ietf package would actually be [email-masked]<mailto:[email-masked]> or perhaps “ietf-v1”.  Probably if we do stick with a name combined with the version then perhaps some guidance on suitable name strings might be helpful.  As I see it:

Potential benefits of having a separate version:

  *   Clean split between name and version.
  *   Matches packages.

Potential cons of having a separate version:

  *   For custom schema is forces clients to also specify a version, even when it might not be meaningful.
  *   It makes the selectable list and the default reference to schema-sets a bit more awkward rather than a simple leaf-list and leaf.
  *   It potentially forces a more awkward encoding for the schema name in RESTCONF paths, since ‘@’ would always be there and not removable (e.g. by a custom schema-set) – I’m not sure this really matters.
  *   If the schema selection is between different schema families (e.g. native vs ietf vs open-config) then a name may be sufficient, depending on whether the schema-sets are published as offline definitions or not.

Regarding the schema-set definition, you are allowed to have multiple YANG packages per DS.  The datastore schema is the union of the YANG packages, and the packages must be compatible without conflicts.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]> On Behalf Of Reshad Rahman (rrahman)
Sent: 25 February 2020 22:53
To: Rob Wilton (rwilton) <rwilton=[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi all,

Regards,
Reshad.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]

From: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 25, 2020 at 8:42 AM
To: "Rob Wilton (rwilton)" <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Rob,

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> on behalf of "Rob Wilton (rwilton)" <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>
Date: Monday, February 24, 2020 at 11:46 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi,

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 11:52:37 +0000

Hi Jason,

Please see inline [RW] …

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Sent: 25 February 2020 23:08
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

################
(O.1)

with this:

[RW]
Added, although I’ve also removed the word new.

I.e.
        <t>To closely align with existing NETCONF/RESTCONF protocol semantics.  I.e., with the
        exception of the optional mechanism that allows selection of the schema-set at the beginning
        of a NETCONF session or RESTCONF request, protocol interactions between client and server
        are the same as when schema selection is not being used.</t>

################
(O.2)
- in section 5, list item 3, remove the comma between "schema-set" and "used"  in "…the default schema-set, used by…"

[RW]
Ack.

################
(O.3)

[RW]
Ack.

################
(O.4)
- I think perhaps the "leaf-list combinable" should be removed. A schema-set describes all datastores and their schemas. I'm not sure what it then means to combine schema-sets. Is this left over from when we thought schema selection could select multiple schemas in parallel (e.g. the old "select-schema-sets" in section 6.1) ?
[RW]
The combinable leaf is for custom schema-sets, and indicates which schema-sets can be combined to form a new schema-set.  E.g. a device might offer up different schema for different capabilities (e.g. Basic routing, SR, L2VPN, L3VPN, MPLS, timing, etc)  and then allow clients to choose which ones to enable in the external management interface.

But this also calls into question the "included-schema" leaf-list in "list custom". It allows multiple schema-sets (each of which could be selected on their own by a client).
[RW]
Yes, the intention of the custom schema sets is really to allow compatible schema-sets to be combined into a new named schema-set that can then be selected.

My preference is to leave this in for the moment.  Potentially we could offer it up as something to remove if there are complaints that the solution is too complex ;-)

################
(O.5)

[RW]
I agree, but will defer this one for the moment, until we have reviewed Bo’s updated appendix 1.

Thanks,
Rob

From: Sterne, Jason (Nokia - CA/Ottawa)
Sent: Tuesday, February 25, 2020 8:53 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

(A)

(B)

(C)

(D)

(E)

(F)
Do we actually want to allow selection of multiple schema-sets? That seems to go against our definition of a schema-set being all the schemas for all datastores.  And is against what is described in section 8  "…is to one particular schema-set"

(G)

Jason

Hi,

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 26 Feb 2020 16:53:06 +0000

OK thx. I'm fine with just leaving the "combinable" aspect.  But then we probably do need to clarify that while a schema-set does describe schema in all datastores, they can be combined with other compatible schema-sets.  i.e. they may not be complete on their own.  (you probably already do mention that, but I know we're in the process of churning some of these definitions and descriptions).

From: Rob Wilton (rwilton) <[email-masked]>
Sent: Wednesday, February 26, 2020 6:53 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]; Wubo (lana) <[email-masked]>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Jason,

Please see inline [RW] …

From: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>
Sent: 25 February 2020 23:08
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

################
(O.1)

with this:

[RW]

I.e.

################
(O.2)

[RW]
Ack.

################
(O.3)

[RW]
Ack.

################
(O.4)

################
(O.5)

[RW]

Thanks,
Rob

(A)

(B)

(C)

(D)

(E)

(F)

(G)

Jason

Hi,

Thanks,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 26 Feb 2020 16:56:12 +0000

I'm ok with version being encoded in the name for this (at least for now). Maybe raise an Issue for it and track those pros & cons in there in case we get asked about this by the WG later?

From: Netmod-ver-dt <[email-masked]> On Behalf Of Rob Wilton (rwilton)
Sent: Wednesday, February 26, 2020 6:10 AM
To: Reshad Rahman (rrahman) <rrahman=[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Reshad,

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Reshad Rahman (rrahman)
Sent: 25 February 2020 22:53
To: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi all,

Regards,
Reshad.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]

Hi Rob,

Regards,
Reshad.

Hi,

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 17:17:13 +0000

Sounds good to me if Reshad is okay with this as an outcome.

From: Netmod-ver-dt <[email-masked]> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: 26 February 2020 16:56
To: Rob Wilton (rwilton) <rwilton=[email-masked]>; Reshad Rahman (rrahman) <rrahman=[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Rob Wilton (rwilton)
Sent: Wednesday, February 26, 2020 6:10 AM
To: Reshad Rahman (rrahman) <rrahman=[email-masked]<mailto:rrahman=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Reshad,

Thanks,
Rob

Hi all,

Regards,
Reshad.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]

Hi Rob,

Regards,
Reshad.

Hi,

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 26 Feb 2020 17:30:33 +0000

I think that the custom schema-sets probably still need more discussion/work … but I don’t think that we should worry about that too much.

For the moment, even with custom schema-sets, the expectation is that the schema that they combine are selectable on their own, and hence must logically hold complete datastore schema.

FWIW, the current text of custom schema sets is this:

5.5.  Custom schema-sets

   Custom schema-sets, if supported by the server, allow clients to:

   o  Configure client meaningful names for selectable schema-sets.

   o  Combine compatible schema-sets together into a combined named
      schema-set that is then selectable by clients.  E.g. a client
      might want to use a combination of standard configuration models
      along with vendor configuration models to manage functionality not
      covered by the standard models.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: 26 February 2020 16:53
To: Rob Wilton (rwilton) <[email-masked]>; [email-masked]; Wubo (lana) <[email-masked]>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

From: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, February 26, 2020 6:53 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Wubo (lana) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Jason,

Please see inline [RW] …

################
(O.1)

with this:

[RW]

I.e.

################
(O.2)

[RW]
Ack.

################
(O.3)

[RW]
Ack.

################
(O.4)

################
(O.5)

[RW]

Thanks,
Rob

(A)

(B)

(C)

(D)

(E)

(F)

(G)

Jason

Hi,

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 26 Feb 2020 21:44:48 +0000

I’m ok with tracking this as an issue. The main reason I prefer having a separate version field is consistency. If you look at latest example from Bo we have yang-library package with name=vendor-schema and version=3.0.0 but schema-set name=[email-masked]<mailto:name=[email-masked]>. But I do see the cons that Rob mentioned below, I won’t pretend they’re easy to fix…

Regards,
Reshad.

From: "Rob Wilton (rwilton)" <rwilton=[email-masked]>
Date: Wednesday, February 26, 2020 at 12:29 PM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>, "Rob Wilton (rwilton)" <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Reshad,

Thanks,
Rob

Hi all,

Regards,
Reshad.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]

Hi Rob,

Regards,
Reshad.

Hi,

Thanks,
Rob

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 27 Feb 2020 13:32:17 +0000

I tried previously to align this the other way, i.e. change the package name to <pkg-name@version> but this ended up being messy in YANG packages instance data definitions, and so I backtracked from that approach.

Anyway, I have raised this issue to track this:
https://github.com/netmod-wg/yang-ver-dt/issues/41

Thanks,
Rob

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: 26 February 2020 21:45
To: Rob Wilton (rwilton) <rwilton=[email-masked]>; Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Regards,
Reshad.

From: "Rob Wilton (rwilton)" <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>
Date: Wednesday, February 26, 2020 at 12:29 PM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]<mailto:[email-masked]>>, "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>, "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: 26 February 2020 16:56
To: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:rwilton=[email-masked]>>; Reshad Rahman (rrahman) <rrahman=[email-masked]<mailto:rrahman=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] Getting versioning draft ready to publish for WG adoption call

Hi Reshad,

Thanks,
Rob

Hi all,

Regards,
Reshad.

        +--ro schema-set* [name]
           +--ro name                 string
           +--ro partial?             empty
           +--ro datastore* [name]

Hi Rob,

Regards,
Reshad.

Hi,

Thanks,
Rob