[Netmod-ver-dt] comments on yang-module-versioning (June 10 version)

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Hi guys,

A few comments on draft-verdt-netmod-yang-module-versioning.txt (June 10th version).

(A) instance data
Section 6 (instance data) mentions that instance data specifies the content-schema. And then says that the schema should make use of versioning.

But don't we need the instance data file to specify which version of the content-schema the data-set is associated with?

For example: imagine we have a bgp module with versions 1,2 and 3.  An instance data file will indicate that the data is associated with the bgp module. But must it not also say that the data is associated with version 2 of the bgp module?

(B)
Add 's' to the end of 'modification' here:
This document updates [RFC7950]. Section 3 describes modification to

(C)
Replace this:
    This document updates [RFC8407]. Section 7 provides guidelines on

    managing the lifecycle of YANG modules once non-backwards-compatible
   changes and a branched revision history are allowed.
with this:
       This document updates [RFC8407].  Section 7 provides guidelines on managing the lifecycle of YANG modules that may contain non-backwards-compatible changes and a branched revision history.
(i.e. get rid of "allowed")

(D)
Get rid of uses of BC and NBC before they are introduced in section 2.  *or* introduce the acronym somewhere above my putting it in brackets after the full term e.g.   non-backwards-compatible (NBC)

(E)
In section 3 we say "if a module includes submodule then it MUST specify the exact revision-date, or revision-label, of the included submodules".  I'm doubtful we should put this as a MUST.  I believe we said that *if* submodules have a label, then it must be the same as the module's revision-label (note - I don't think we can/should mandate that for revision, i.e. the current YANG 1.1 date based 'revision').  But I'm not sure why we'd require an exact revision-label (and definitely not revision-date) for includes of submodules. That would be problematic for Nokia if it applied to the current date based revision (currently YANG allows different revision dates on submodules and we have different dev teams working on different submodules with their own dates).

(F)
This is too strong on the use of "allow" IMO:

[RFC7950] chapter 11 requires that all updates to a YANG module are
   BC to the previous revision of the module.  This document allows for
   more flexible evolution of YANG modules: NBC changes between module
   revisions are allowed and are documented using a new "nbc-changes"
   extension statement in the module revision history.

How about this?

[RFC7950] chapter 11 requires that all updates to a YANG module are BC to the previous revision of the module and there is no ability to indicate when an NBC change has occurred. This document provides a method for documenting NBC changes between module revisions using a new "nbc-changes" extension statement in the module revision history.

(G)
Section 3.1.1.  Drop the word 'allowable' from this sentence:
The following statements update [RFC7950] chapter 11 to define what
   constitutes an allowable backwards-compatible change to a YANG
module:

(H)
Section 3.3 says that a submodule must have the same date & label *if* a label is used. I'm wondering if we should remove the part about date.
In any case, we should allow a submodule that does *not* have labels, to continue to use different dates than the module (as is allowed today).

(I)
section 4.1.  Do we really want to repeat the same figure here again?  Maybe just ref back?

(J)
section 4.1.  I got confused between the text and the examples (which text applies to which examples). Can we put them each into a subsection?

(K)
remove the comma between 'set' and 'may' here:
In this way, the versioning of a content-schema associated with an instance data set, may help a client

Jason