============================================================= NETCONF Data Modeling Language WG (netmod) 3rd YANG 1.1 Virtual Interim Wednesday, July 2nd, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AB = Andy Bierman - LL = Ladislav Lhotka - MB = Martin Bjorklund - BC = Benoit Claise - PO = Peyman Owladi - PH = Peter van Horne * Summary During the meeting, the issues Y07, Y09, Y10, Y11, Y12, Y13, Y14, Y16, and Y18 were discussed. For each issue, either a strawman proposal has been found or concrete action items have been assigned. We will continue with two more virtual interim meetings before the face-to-face meeting in Toronto. * Y07: do not allow when or if-feature on keys AB: Says the solution is wrong, if-feature / when should not be more specific than the parent. AB: Is there not text somewhere else in RFC 6020? PO: The leafs condition should at least be as restrictive as the parent context. PO: A statement that says something about the parent is irritating. AB: What if I put if-feature bar on the parent? MB: That is OK. LL: What must be avoided are lists where keys are (partially) undefined. MB: Make them illegal if the condition is different from the parent. Proposal: Adopt Y07-01 with a clarification about the condition. * Y09: introduce optional keys Action: MB will write up a solution proposal. * Y10: allow restrictions on enumerations MB: I think we should do what SMIv2 allows. AB: What prevents the second typedef from redefining enum a? MB: Redefining the value would not be legal. LL: What about having a different statement to define the set of allowed enums to prevent overwrite issues? MB: Not sure this helps since you can do pretty much all of this with strings and pattern, see the first example. AB: What happens if foo has a default b? MB: That would be illegal. LL: I prefer a different syntax. Action: LL to write down another syntax proposal and MB to expand Y10-01. PO: What about restrictions on unions? MB: Currently not allowed, should they be allowed? JS: Unclear whether common programming languages allow something like this. MB: An implementation issue. JS: But people might simply not expect this to be available. MB: Lets discuss this later, this is a separate issue. * Y11: allow if-feature on enums MB: This avoid having choices with an empty container. AB: This is somewhat different since this usage of if-feature is not related to data tree nodes directly but instead applies to the value space of types. PO: If you have if-feature for enumerations, would you also want to have them for identities? MB: Likely yes. AB: I like this since it allows an NMS to restrict values shown to a user based on the announced features. Proposal: Adopt Y11-01 with the extension to allow if-feature also for bits and identities. * Y12: initialized-by system JS: Does initialized-by system mean may be initialized-by system? And initialized-by user means must be initialized-by user? MB: No, it is more boolean. MB: This is not a default, the server generates a suitable value. PO: What about ports that change the MTU when sub-interfaces are configured? MB: YANG does not support dynamic defaults in that way. AB: What about processing an edit-config with multiple list entries, some with explicit values, some without? MB: The server would have to figure this out. JS: The server can be smart to figure out suitable values for a given commit or be dumb and return an error (similar to an edit-config with conflicting uids). LL: Should probably have a different syntax, initialized-by user is misleading, perhaps system-initialized true|false. It is really system-initialized-if-missing. LL: Only valid for leaf? MB: I think also leaf-list, for consistency. PO: May be a bit related to mandatory, default is likely illegal with initialized-by system, need to write more complete text. Proposal: Adopt Y12-01 but think about a better syntax. Applies to leaf and leaf-lists. MB to create concrete text. * Y13: allow multiple inheritance for identities AB: I am not see the example - the example only defines two regular identities. LL: Not sure I wrote the example. AB: What do I get by having multiple bases to an identity? PO: Interfaces are good examples. LL: It is good to use identityref with multiple bases. JS: How do you maintain the identity derivation graph if things are added over time? LL: This is only useful if we have suitable xpath functions. JS: Can someone write a complete example that shows how this solves interface type issues? Action: LL to write a more complete example. * Y14: clarify the string value for identities when used in must/when MB: I think Y14-01 is already used in the routing model. LL: Need for this drops once we have xpath functions. MB: We still need to define this. Proposal: Adopt Y14-01. * Y16: module advertisement optimization AB: Not sure this is a YANG issue alone. MB: YANG module advertisement is defined in RFC 6020. AB: This does not work because there is no version number. If the client could say here is what I have cached, then this could be made to work. MB: If we only suppress YANG 1.1 modules? JS: Is the info in RFC 6022 (Y16-02) complete? MB: Not sure, we implement /netconf-state/capabilities as what was in the hello. PO: I am leaning towards Y16-02. MB: RFC 6022 talks about NETCONF capabilities. Does it also contain the data models? AB: Right now, the hello contains all modules. But this should actually be subject to access control. AB: I am in favor of Y16-02 since it allows to hide loaded modules. JS: How does this work in RESTCONF? Action: MB to look at the details whether Y16-02 can be made to work. * Y18: fix "when" expression context node problem LL: I do not like the solution proposal. The result may depends on the order. LL: My proposal would be to treat when equivalent to must. MB: But this is backwards incompatible. MB: I do not understand the problem you see. LL: You need to at least specify what happens if there are circular dependencies. MB: Seems like a theoretical corner case. PO: Perhaps even leaving this implementation specific? AB: There are other when issues, e.g. the order in which expressions are evaluated and it gets work if when expressions interact. MB: How likely is this going to be a problem? Action: LL to write up an example in which situations Y18-01 is problematic.