Minutes for NETMOD at interim-2014-netmod-1
||Minutes for NETMOD at interim-2014-netmod-1
NETCONF Data Modeling Language WG (netmod)
1st YANG 1.1 Virtual Interim
Wednesday, June 4th, 2014, 16:00-16:00 CEST
Minutes Benoit Claise, Juergen Schoenwaelder
- JS = Juergen Schoenwaelder
- BC = Benoit Claise
- AZ = Alex Zhankin
- AB = Andy Bierman
- BZ = Bernd Zeuner
- DR = Dan Romascanu
- JT = Jason Sterne
- KW = Kent Watsen
- LL = Lada Lotka
- MB = Martin Bjorklund
- PH = Peter van Horne
- XL = Xufeng Liu
- AN = anonymous
The goal of the 1st virtual interim meeting was to decide on the
submitted issues marked NEW and without a strawman position (or a
strawman position that led to discussions) whether they are in scope
(OPEN) of the YANG 1.1 effort or out of scope (REJECT).
* Y31 allow require-instance in leafref
Proposal: Keep Y31 open as already being discussed on the mailing
list. LL, MB, AB, AZ in favor of moving this to open.
* Y09 introduce optional keys
LL thinks a key not present simply does not contribute to the
AB against it since it breaks restconf. Why is this really needed?
LL has no problem with opening the issue and seeing whether a
solution can be found.
AB how does this map to things like SQL? What are the interactions
with optional keys?
AZ we should perhaps abstract from implementation details.
MB volunteers to come up with a concrete proposal and then we can
decide whether the complexity is under control.
KW does not see a simple mapping to SQL. I tend to agree with AB
that this is perhaps complex. Why would you not use artificial keys?
MB says that in some cases the data model would be more natural.
AB says if a leaf is optional, then it is really not part of the key
and you might be picking the wrong thing as a key.
AB asks what happens if there are multiple optional keys? Can they
all be optional?
BC asks whether AB is afraid of the combination of multiple optional
AB responds that the key is crucial for naming.
Proposal: Move this to open for now. Some concerns from KW and
AB. We might revisit this issue later if the complexity/cost of a
solution is too high. Action item for MB to provide a detailed
* Y19 we need a better unique
LL says that nested lists can already be included in XPATH, at least
the DSDL mapping handles this.
MB says we need to make sure that the current unique works
correctly with the DSDL and clarify RFC 6020.
MB is fine with the interpretation of the DSDL draft. But MB also
says that we need to check whether the DSDL mapping solution
achieves the same as the issue writeup.
AB is concerned that this adds complexity.
LL got concerned that if semantics deviate from what the DSDL
mapping currently does, then he is against accepting this.
AB remarks that maybe it is easier to tell people how to use must
statements to achieve similar results.
AB is concerned that we end up with two unique statments and then we
need to tell everybody what the difference is and when to use which;
not convinced that this better unique is needed.
PH this sounds more like an optimization.
PO says it does not break backwards compatibility.
Proposal: Reject this request for a new feature but clarify the
semantics of unique in RFC 6020bis (might require to open a separate
clarification issue). A new and more powerful unique seems more like
a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
this was rough (MB prefers to have this issue opened).
* Y21 statement to define new XPath functions in a module
MB we apparently need a few more XPATH functions. The question is
whether these XPATH functions are hard wired in the language
(requiring a language update for each addition).
LL says that implementations simply can't ignore the XPATH functions
and hence it does not satisfy the requirement of the extension
AB is concerned about interoperability problems.
AZ thinks it is a bad idea to define XPATH function in YANG itself.
MB says that in the IETF, we would need to bump the YANG version
number when we add new XPATH functions.
PO says the alternative today is to implement an extension to
support the same function (which would be ignored by existing
Proposal: Reject this request for a YANG statement to declare new
* Y22 support constraints on unions
AB says it is not clear which problem is being solved. Why does it
need to get exposed which type statement of the union got selected?
PO how is it well defined what the value set is?
AB says that if a value matches any of the types in the union, the
value is valid. The value set hence is really the union of the types
PO says in XML and JSON, you can have the type identified. What YANG
does is sufficient for validation.
LL agrees that this should be rejected.
MB agrees to reject as well.
PO suggests to clarify that this is primarily for validation and not
necessarily for type identification.
LL says there is text that types are tried sequentially.
Proposal: Reject the issue and add a new issue that a clarification
is needed about the nature of unions and that they primarily are
needed for validation.
* Y26 allow mandatory nodes in augment
MB believes the current rules are too strict but removing the rule
would allow things to break easily.
LL says the overarching principle is that published modules are not
allowed to become invalid by augments.
AB sees a problem if an old client implements old module A and later
a new module augmenting module A comes along causing things to stop
working for the old client.
AB says there are ways this can be done if a module has been
designed for such mandatory augmentations.
MB says that in certain cases such a mandatory augmentation is fine;
the problem is defining and writing down the rules.
PO asks whether it is possible to create rules like augmentations
with mandatory is allowed if the augmentation is guarded by a when
MB says it is difficult to write up such rules. Suggests to open
this and reject it later if we can't come up with good rules.
AB says unless we have service level conformance, the mandatory
property is scoped to a module.
PO asks whether we can just restrict it to what has come up in the
interfaces data model?
AB is concerned that it will not be a single case. It is important
that we protect old clients. It will, however, be difficult for a
YANG compiler to validate this.
AZ supports this to be open since we have an actual use case.
JS asks whether it is possible to relax the current rule with lots
of explanatory text, assuming that implementations will generate
warnings based on the current restrictive rule but humans may choose
to ignore them if they checked that indeed old implementations do
Proposal: Open this issue even though a possible solution remains
* Y27 allow mandatory nodes in an updated module
MB says the intention of the text was to protect old clients.
However, different from Y26, the revision number changes here.
MB suggests this to be opened.
AB and LL agree to open this.
Proposal: Open this issue.
* Y33 add 'attribute' statement
LL says if there are only a really small set of attributes that we
need, then he is fine with rejecting it.
AB is OK with a reject since it is likely only a small number of
attributes that we need.
AB believes such an attribute statement will likely cause people to
Proposal: Reject this issue.
* Y36 associate a notification with a data node
MB says that he did not have customers asking for this but Tail-f
has something similar called actions (inlined rpcs). If we do this,
it makes sense to add inline RPCs as well.
AZ sees a use case.
PO sees value in notification source properties attached to leafs.
PO says that this is essentially about associating a notification
with a resource object.
MB says this is a nice to have feature because you can do
without. Sounds more like a YANG 2.0 issue.
AB agrees that this is an optimization, perhaps this can also be
dealt with by certain design patterns.
JS suggests that one could also think about guidelines on how to
structure notifications to make resource identification easier.
Proposal: Reject this issue. May be considered for YANG 2.0.
* Y37 allow notifications to be derived from other notifications
MB says this is an optimization, nice to have, but not critical.
AB says this is convenient and simple to implement.
JS says that for other things we expect designers to explicitly
design reusable things, we do not allow uses on an arbitrary
Proposal: Reject this issue. Reject supported by LL, AB, and MB.
* Y39 define the terms system/user-controlled instances
PO asks how exactly is this envisioned to be used?
MB is concerned that it does not belong in the YANG language
definition since this seems to be more architectural.
LL agrees with MB, perhaps this can go into the architecture
document? Or in a design pattern document.
PO asks whether there are any consequences of not putting this into
the YANG 1.1 specification?
LL answers no, the question is more whether we define this in a
single place instead of multiple places. Right now, this is defined
in those data model documents that require this distinction.
Proposal: Reject since this is an architectural distinction and
should thus should be defined generically elsewhere. It does not
seem to be a YANG 1.1 issue.
* Y50 additional extension grammar validation
MB says this is a nice to heave feature for tool writers, users of
tools likely do not care.
PO says that this makes extensions more readable and well
defined. But yes, this is a nice to have feature.
MB says that Tail-f has an extension for this but it is a nice to
have feature and not essential
AB is concerned that this asks compilers to interpret ABNF at
PO says that their implementation is not more constrained / precise
than the existing YANG grammar.
JS says if this can be done as an extension, why make it part of
YANG 1.1? Simply write an extension YANG module.
Proposal: Reject the issue since it can be done as an extension and
does not need to be part of YANG 1.1.
* Y54 remove the advertisement of conformance information in NETCONF hello message
MB says all conformance issues need to be discussed together and
hence we should keep this open as well.
LL suggests to write a new issue that consolidates all conformance
AB says the way this is written it is not workable.
JS suggests to move Y54 as a solution of Y16.
JS does not like adding new issues, he prefers to cluster
conformance related issues.
Proposal: Open this issue as it is related to the other conformance