Minutes for NETMOD at interim-2015-netmod-4
||Minutes for NETMOD at interim-2015-netmod-4
NETCONF Data Modeling Language WG (netmod)
13th YANG 1.1 Virtual Interim
Wednesday, February 18th, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
AB = Andy Bierman
BL = Balasz Lengyel
DR = Dan Romascanu
IB = Ignas Bagdonas
JS = Juergen Schoenwaelder
KW = Kent Watsen
MB = Martin Bjorklund
* YANG 1.1 Conformance
AB: Concerning A1, notifications are not required to implement if
the server does not implement notifications in general.
JS: Some wordsmithing of A1 might make this clearer.
MB: A2 should be more precise that implements means implementing
data nodes, rpcs, and notifications.
AB: I am not sure about C1, if you need only a subset of a module
and there is no handy feature for excluding the rest, there is a
MB: I believe C1 summarizes how things work today.
AB: Are we trying to come up with tighter rules for humans or for
tools to take advantage of the tighter rules?
AB: I am not sure YANG 1.0 specifies C1 explicitly somewhere.
JS: Does A3 not follow from A2?
KW: A3 is more a corollary of A2.
AB: The high-level problem is how to create and maintain the
information needed to achieve A4. If it is too difficult to
maintain and manage this information, things will not work in
AB: A4 is not the problem statement because we need to capture the
AB: Sometimes a robust solution is more verbose. Auto-numbering is an
example where a fancy mechanisms makes things harder to use.
MB: Perhaps we should not allow extensions of value spaces of
typedefs (except identities that are extensible).
MB: P1 is typedef-drift.
JS: P1a-01 has the scope problem - if you want a new revision of a
typedef, you have to implement the new revision everywhere.
Similarly, if you need one updated type of inet-types, you have
potentially to implement N other updates that come along with
the new revision.
MB: Question: If value space extension are problematic for typedefs,
is it still OK to extend the value space of a leaf? I would say yes.
JS: You might still break must constraints in other modules in this
way. And for config false, things are very different.
KW: In the netconf server configuration data model, almost
everything is defined via groupings. If I can't extend them,
things become problematic.
AB: You can copy the groupings, may not look as nice.
AB: Groupings are often written with a certain context in mind but
then they can be used in very different contexts.
MB: Another solution would be P1b-03 - typedefs never change.
MB: P2 is showing that import-by-revision can lead to unresolvable
conflicts requiring import updates (revision update ripple problem)
AB: I think we should try to find a solution that avoids import-by-revision.
MB: I agree.
MB: Import by min revision does resolve this issue, but then it
becomes unclear again which version of a typedef was used.
JS: Import by min revision resolves P2, but then P1 is a problem
again. To fix P1, you want import by exact revision, which then
breaks P2 again.
KW: Yes, and I can't cherry pick a single updated typedef from a
module with N typedefs.
MB: P3 is primarily about deprecated definitions, which then are
optional to implement.
JS: Interesting discussion what deprecated and obsolete means.
BL: I think deprecated should mean "must still be implemented".
KW: I think obsolete should mean "must not be implemented".
KW: It would be nice if there would be an expire time associated
JS: But you can already create warnings as soon as something is
deprecated. Why do you need an expire time?
KW: Other application maintainers may need to know that in order to
plan they software update process.
MB: I think we are talking about an automatic obsolete, i.e., if the
timer expires, the definition moves from deprecated to obsolete.
MB: P5 is about missing feature modularity
BL: Perhaps the guideline here must be that you should not augment
into something if that something is not essential to have; keep
the tree flat.
AB: I think we worked out that isolated problems can be solved, but
the solutions do not work together.
AB: Grouping drift is a major problem where I do not know how solve
this (other than not allowing grouping changes)
AB: We need to think about runtime solutions for certain things like
AB: I do not think that an implementation has to implement all
identities derived from a common base.
MB: I agree.
AB: The runtime discoverable restrictions may also need to cover leafrefs.
BL: But there are other restrictions that you can't describe. If I
do not support 42 for uint8, then an attempt to configure 42 may
simple fail with a runtime error.
AB: We are at a situation where none of the solutions we have that
would work do not look very appealing.
MB: It seems import by revision does not help.
MB: One option might be request via the guidelines that value set
changes of typedefs or additions to groupings should not be done
in the IETF.