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
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
