[netmod] kw review of draft-verdt-netmod-yang-semver-00

[Kent Watsen <[e-mail]>]

I understand that this draft is shaking fundamentals that is making
some folks nervous.  The concern is appreciated, but I also understand
well issues vendors are facing and don't believe that maintaining
status quo is realistic.

The requirements are, for the most part, correct (IMO), especially
regarding support for NBCs.  At least, the way I see it, that is the
reality of native models for products that have multiple simultaneous
release trains.

Maybe deviations could be used but 1) it's kind of strange for a vendor
to deviate from its own native model and 2) it seems complicated to swap
the compiled native model with a standard native model + some dynamically
generated deviations, using some TBD tooling.  To be clear, my assumption
is that the underlying NC/RC interface is unchanged, only the modules the
server reports would vary.  But why haven't vendors done this already?

I don't yet see a downside to embracing the sem-ver proposal, while
OpenConfig alignment seems like goodness.  We should analyse the tradeoffs
more.

For the following review, I assume that Sem-Ver is good, and the added 'M'
and 'm' suffixes are useful.  Whether these things pan out in time is TBD.

==

Beginning of Section 1.2:
     OLD: This section is to aid the WG understand how the full set
     NEW: This section is to aid the WG understanding in how the full set

End of Section 2.1
     OLD: and those changes do not follow the rules
     NEW: and at least one change does not follow the rules

Just before Section 2.2.1:
     OLD: There MUST NOT be multiple versions of a YANG module
     NEW: There MUST NOT be multiple published versions of a YANG module

     Actually, it might be more helpful to have a clarification note 
near the top
     that the draft only regards published modules and specifically does not
     apply to the various revisions of a draft.

In Section 2.2.1:
      The line “0.2.0 - second beta module version (with NBC changes)” 
SHOULD
    point to rule 4 in Section 2.3

In Section 2.3:
     For rule 4, why not peg the semver to “0.0.0” for beta modules? 
  Already the
     Interpretation is off, so no semantic meaning comes through.  Going 
back to
     my earlier comment about having general statement regarding 
unpublished
     modules, it seems that “beta” modules fall into this category and 
hence okay
     to reuse the same semver value.

In Section 3:
    There are two numbered lists in this section, each containing three 
entries: 1,
    2, and 3.   First, please change one of the lists to a different 
format (e.g., i, I, iii).
    Next, it would be helpful to explain which parts belong to which. 
  E.g., 1–>i, 2–>ii,
    3 —> ii and iii.

Section 3.1:
     OLD: that is hypothetically available in the following versions:
     NEW: that is published in the following versions:

Section 4.2:
     OLD: The document update these rules
     NEW: This document updates these rules

     Also: s/chanage/change/

Section 5.2:
     OLD: but one of more modules
NEW: but one or more modules

Section 5.3:

     The augmentation in the YANG module indicates the intention is to 
enable a
     server to express its conformance at the “server” level, but it 
seems that it
     should be at the module-level.  As support across modules may vary.

     Also, this section has a nice wrap up paragraph where it states
     “implementations <snip> MUST set the 'deprecated-nodes-implemented' 
leaf,
     But it fails to say anything about the obsolete-nodes-absent leaf? 
  It seems that
     It should be required as well but, if not, then the text should 
state why not.

Section 6:

     Says “this extension can contain freeform text”, but it seems that 
a node that
     tools could act on would be better.  Is it we think that the 
deprecation warning
     message should be sufficient to guide the developer to look at the 
description?

Section 7:

     Not specific to this draft, but is it an omission in 
yang-instance-file-format
doesn’t specify schema compatibility for instance data?


Kent // contributor