============================================================= NETCONF Data Modeling Language WG (netmod) 8th YANG 1.1 Virtual Interim Wednesday, November 19, 2014, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - KW = Kent Watsen - LL = Lada Lhotka - MB = Martin Bjorklund - BL = Bing Lu - PS = Phil Shafer - GZ = Guangying Zheng - IB = Ignas Bagdonas - YY = Yangyang * 64-bit numbers in xpath expressions LL: I think this is a bug-fix issue to track. MB: Is this a real problem? Action: LL to write-up a new issue and to send it to the mailing list. * Y05 unprefixed path in top-level typedef MB: I proposed some text to resolve this in Y05-01 PS: I prefer consistency with groupings. LL: I think additional text should be added for derived typedefs. LL: Perhaps we need some usage guidelines, e.g. warnings about not using namespaces. Proposal: Adopt Y05-01. * Y09 introduce optional keys PS: I pointed out that not() can't be used that easily. PS: Many database technologies require keys. LL: I believe this is related to non-unique leaf lists (Y57), positional addressing could be used here as well. KW: Is the example in Y09-02 incomplete or a default lacking? LL: A default is not necessary. JS: Does this allow to add an optional leaf? JS: I believe we concluded that adding optional leafs can't be supported. PS: Adding an optional key breaks the initial contract. JS: If we can use optional keys only at initial module design time, how useful is this then? MB: This might still be useful, for example, if you define a new list derived from an old list. PS: I prefer to keep things simple. MB: Optional keys are valuable in cases such as supporting VRFs. KW: Perhaps we should only allow optional keys if there is a default? JS: This would be another solution, lets say Y09-03. JS: The type of the optional leaf key would have to allow for the special value and we would essentially document the usage of the special value in a machine readable way. PS: I think Y09-03 is a good compromise. MB: I prefer Y09-02 without the update for section 10. JS: How does this interact with the different default handling modes? PS: The server still needs to track internally whether a value was explicitly assigned or not. MB: I prefer Y09-02 since you do not need to invent a special value. MB: But Y09-03 is still better than nothing. MB: Y09-03 resolves the issue with the not() function since there is always a value for each key leaf. Action: MB to write-up Y09-03 as discussed above. Proposal: Adopt Y09-03. * Y16 module advertisement optimization MB: This issue has evolved since we have a separate conformance document now and the ietf-yang-library model has been proposed to be moved from RESTCONF to NETMOD PS: What is the reason to factor out conformance into a separate document? MB: Primarily document modularity. MB: Y54 suggests a complete removal of conformance announcements which I do not agree with. We should send a hash of the module capabilities so that a cache can quickly be verified. PS: Why do we not do the same for protocol capabilities? MB: We can only modify things defined in RFC 6020. Protocol capabilities are defined in RFC 6241. MB: I would like to move the NETCONF specific text into a separate document and this document would have to explain how advertisement works. PS: How do you get rid of the edit-config rules? MB: The idea is to move the rules, not to get rid of them. PS: What about the examples? Consider insertions into a list. LL: I like the proposal to move protocol specific text into a separate document KW: This is what we already do with RESTCONF. PS: YANG is a data modeling for NETCONF and I prefer to have it stay this way. PS: I do not mind YANG to be reused. I am concerned if NETCONF becomes a distant cousin instead the technology it came from. LL: But with RESTCONF things are already done differently. PS: It would be bad to have data models that are specific for NETCONF or RESTCONF MB: I agree that should be avoided. MB: Document size may be an issue - RFC 6020 is already fairly long. LL: People using RESTCONF do not benefit from the NETCONF specific content in RFC 6020. JS: The devil may be in the details. It may require to try out splitting the document in order to find out whether a split is workable. MB: I am willing to try but not if it is already clear from the beginning that this won't be accepted. JS: Please bring the discussion of the document structure to the mailing list so that people can comment. Based on the feedback, people can decide whether they are willing to prototype such a document split. MB: For the hashing, we would have a separate capability. Action: MB to add a new solution (Y16-03) that is covering the hash idea and the usage of ietf-yang-library. Proposal: Declare Y54 DEAD with a pointer that Y54 got subsumed by Y16. * Y18 fix "when" expression context problem LL: I added an example to Y18-01 and he believes this is problematic. MB: The example is just fine since the description does not talk about the order in which when expressions are evaluated. MB: The only problem are loops. LL: The xpath expressions cannot be evaluated in isolation anymore; the problem is that we are not evaluating against a fixed document but instead against something where nodes are added during the evaluation PS: So the question is how do you describe the context in which the expression for A is evaluated. KW: Is the example not missing mandatory true for leaf B? PS: No, B is not mandatory - it has a default and a when statement. PS: It is easy to say that the context includes objects that have a default value. But there is definitely an order going on, how do you describe it? MB: It is mostly recursive. KW: Call it the evaluation order. PS: How do we describe this order? LL: It is a dependency order of things appearing in when expressions. PS: Any nodes appearing in when expressions must be first evaluated before the current expression is evaluated. PS: For ../B to make sense, you first have create A. PS: If we define the context correctly, perhaps even circular issues go away. KW: A circular reference cannot be used to a fake context node, it has to be to a real one. MB: Still, is ../* circular or are fake nodes not considered in that case? MB: It seems we need to define the evaluation order somehow along the lines PS suggested. MB: We need to explain how the rest of the context is constructed. LL: This problem would not exist if when would only be allowed for augments. MB: The ordering issue would still have to be spelled out but the context node issue goes away. LL: Change the issue name by removing 'node'. Action: MB to draft some text concerning the order of when expression evaluations.