Hi all,
I took a look at section "3.1.2 Backwards-compatibility rules for config false
and output data" of
https://tools.ietf.org/html/draft-ietf-netmod-yang-module-versioning-02.
Here are some suggestions (mostly just editorial - I agree with the general
spirit of what's in here).
(A) Valuespace
Valuespace is defined in module versioning 02:
o Valuespace: The valuespace of a leaf or leaf-list is the set of
values that the schema node may have according to the type and
constraint statements of the YANG model.
It seems to be a more complete definition than "value space" in RFC7950 (which
doesn't seem to take into account "range", "pattern", etc statements):
o value space: For a data type; the set of values permitted by the
data type. For a leaf or leaf-list instance; the value space of
its data type.
Should we mention that this definition replaces/supercedes that of 7950 (at
least for the scope of the module versioning doc) ?
I'd also recommend we call it "value space" rather than "valuespace".
(B)
replace "an additional state leaf can easily be discarded" with "the presence
of an unexpected state leaf is not typically a problem for a client and can be
ignored"
(C)
replace "config=false data" in the 1st paragraph with the following (and keep
the quotes - that is how RFC8342 presents it):
"config false" data
(D)
replace this:
o A client SHOULD be able to handle data that is outside the
valuespace defined, as long as it is of the same basic type.
with this:
o A client SHOULD be able to handle instance data that is outside the
defined
value space of a schema node, as long as the data matches the base type
of the schema node.
(E)
I don't think we should try to exhaustively list (and limit) all the factors
that can change the value space of a schema node. So instead of this:
o Expanding the valuespace of a leaf or leaf-list is BC. Change of
the valuespace may be the result of a change to a range, length,
pattern, base, enum, bit, require-instance or must statements.
how about this:
o Expanding the value space of a leaf or leaf-list schema node is BC (for
example, a change, addition or removal of a range or length statement).
(F)
replace this:
o Changing min-elements to a lower value is NBC (it is like removing
mandatory)
with this:
o Decreasing min-elements is NBC (it is similar to removing a mandatory
statement)
(G)
There isn't really a "catch all" rule for everything else that isn't mentioned
in section 3.1.2. Should we have some sort of statement that state rules are
the same as config rules (section 3.1.1) except where explicitly updated by
this section 3.1.2 ?
Jason
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
