============================================================= NETCONF Data Modeling Language WG (netmod) 10th YANG 1.1 Virtual Interim Wednesday, December 17, 2014, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants JS = Juergen Schoenwaelder LL = Lada Lhotka MB = Martin Bjorklund AB = Andy Bierman DR = David Reid JT = Jason Sterne BC = Benoit Clais BL = Balazs Lengyel KW = Kent Watsen DR = Dan Romascanu * Status Check - Y09 introduce optional keys Need to validate adoption of Y09-03 on the mailing list. - Y16 module advertisement optimization Need to validate adoption of Y16-03 on the mailing list. - Y18 fix "when" expression context problem Pending action MB => action to be completed - Y59 restrict use of 64-bit numbers in XPath expressions Moved to open, perhaps discuss resolution? - Y25 make enum numbering purely informative and optional JS to start a thread on the mailing list. There once was rough consensus for Y25-01 - we need to check what happens on the list. - Y26 allow mandatory nodes in augment Pending action LL => action done - Y58 associate an actions with a data node Pending action JS (check with NETCONF chairs concerning NACM update). - Y34 remove/deprecate/replace the 'anyxml' statement Need to verify Y34-04 on the mailing list and that it can handle all existing meaningful uses of anyxml. - Y49 clarify nested submodule behavior Need to validate adoption of Y49-04 on the mailing list. - Y57 non-unique leaf-list There was an action item for BL on 2014-10-15 => action to be completed - Y45 better conformance mechanism How to resolve this? Do we need to collect the requirements a solution must satisfy? It sometimes feels like going in circles on this. * Y45 better conformance mechanism JS: We seem to go in circles, can we collect use cases to verify solution proposals against? MB: Yes, we seem to go in circles. AB: Using import-by-revision everywhere is one solution, but it has a cost. AB: I wanted to move conformance out of the YANG module, conformance is specified separate from the objects. BL: Simplifying assumptions may be needed (only one version per module) AB: Do we agree on one module per server? MB: Only one module where you implement data nodes. KW: Import by revision resolves which version of a type has been used. MB: This may lead to massive updates if a type module changes. JS: Lets distinguish between (a) a modular server implementing multiple versions within a module and (b) different modules importing from different versions of some other module. MB: Import by revision does not solve the problem. MB: The problem is two augmenting modules importing the augmented module at different revision numbers. KW: RFC6020 says must statement can be relaxed, it is silent about when statements, perhaps an errata? AB: Phil said that if B augments A, then a server needs to implement A KW: If you have a module A that imports only groupings from B, then the server does not need to claim implementing B BL: We use a lot of imports without import-by-revision. MB: This may be a maintenance issue. AB: There is already some confusion about what needs to be announced. KW: You can add a must statement to a new node, but you can't add a stricter statement to an existing node. BL: But you can break the rules by side effects. BL: I like to know which version of a typedef module is actually being used. MB: The requirement is that the client can understand which version of a typedef module is actually used by a module. AB: Perhaps keep it simple - if you change a grouping, you have to give it a new name. KW: Lets collect statements (axioms) we agree on (or not). A0. Claiming conformance means that the server implements all protocol-accessible nodes, rpcs, notifications (modulo supported features). It does not include aspects that are not directly accessible, including typedefs, identities, and groupings. A1. A server can only claim conformance (i.e., implement the data-nodes, rpcs, notifications) to one revision of a specific module at a time. A2. A server does not need to claim conformance to a module that was only imported by other modules for purposes other than augment. A3. A server must claim conformance to a module if it is imported by another module for the purpose of an augment statement by another module the server claims conformance to. A4. The version of all imported items including typedefs, groupings, etc. must be visible to the client. BL: We need to maintain backwards compatibility since management systems are very hard to update. LL: But backwards compatibility rules hard coded in the language limit flexibility where needed. AB: I agree with BL, we need to be most concerned about software updates. AB: The cost of being wrong can be high, so try to check the modules well before publishing them. KW: I believe vendors will implement functionally overlapping modules. MB: What is in that case the response to a get-config? KW: Without a namespace, you get the default module set, otherwise the namespace defines what is returned to a client. KW: The developers of submodules may use imports at different revision levels. BL: This may be fine for the developers, but how does an operator deal with this? KW: I assume the operator's code is data model driven. The import-by-revision will tell them which imported definition was used. AB: In a module, you can't import a module multiple times. But this happens with submodules if they import at different revisions. BL: I do not like to allow importing different revisions of A in different submodules. MB: But it depends on the solution. We need to work out the use cases and evaluate the solution against use cases. BL: RFC 6020 says multiple revisions imported in a module is not supported. It is not clear whether this applies to modules and/or submodules. AB: You can only have conformance to things that are protocol accessible. LL: A server advertises the identities it implements by advertising the module where the identity is defined. JS: I do not think this is valid for say iana-interface-types. AB: The set of identity values that can be used is a runtime issue. KW: Is this not similar to groupings? MB: No, because the value is used (or not) at runtime. MB: Use an RPC to discover possible values at runtime. LL: The problem is the IANA interface type list, the identities should be defined in type specific modules. BL: Even with specialized modules, we will see the problem again. At the end, every identity ends up in a separate module. AB: Line cards often have specific constraints and we need to be able to deal with this. BL: There are also license restrictions that apply. AB: The problem is when import-by-revision is mixed with import without revision. KW: We need to distinguish the different types of imports (import for just groupings/typdefs/etc vs import for augment). Actions: - MB volunteers to kick of the process of collecting use-cases and solutions.