============================================================= 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 ============================================================= * Participants - 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 * Summary 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 uniqueness requirement. 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 keys? 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 solution proposal. * 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 statement. 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 implementations). Proposal: Reject this request for a YANG statement to declare new XPATH functions. * 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 involved. 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 statement? 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 not break. Proposal: Open this issue even though a possible solution remains rather unclear. * 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 misuse it. 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 container. 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 runtime. 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 related issues. 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 related issues.