============================================================= NETCONF Data Modeling Language WG (netmod) 14th YANG 1.1 Virtual Interim Wednesday, March 4th, 2015, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants: JS = Juergen Schoenwaelder MB = Martin Bjorklund KW = Kent Watsen AB = Andy Bierman DR = Dan Romascanu LL = Lada Lhotka * Y45 better conformance mechanism JS provided a solution proposal that was discussed and a bit fine tuned during the discussion. This will be added to the issue list as solution Y45-02. Scope of the work: - A conformance framework for defining conformance that can cut through sets of modules (and their features) may be needed at some point in time but it seems that this can be done later once there is more experience and such a conformance framework is not required to solve in YANG 1.1. Simple solution: - Typedefs must not change their value space or semantics. If this is needed, a new typedef needs to be created. This does not affect the ability to make bug fixes. - Groupings must not change their structure or semantics. If this is needed, a new grouping needs to be created. This does not affect the ability to make bug fixes. - Leafs can have their value space extended but this is not automatic. - The definition of 'deprecated' and 'obsolete' may need some clarification, the wording borrowed from SMIv2 may not be precise enough for configuration management. - We can consider to define RPCs that allow to retrieve possible value sets for certain types (or leafs?). But this does not have to be part of the YANG 1.1 specification; this could also be part of the YANG library (and such RPCs might even be an optional feature). Discussion AB: This could lead to corner cases for enums that get updated regularly. MB: But in such cases, identities might be a better option. MB: Can we allow to add enums if they are scoped by a new feature? KW: This seems to be OK. AB: But the client has no control if the feature is enabled, so this can't be done. MB: Does this imply that import-by-revision is not needed anymore? JS: Probably simplest to leave import-by-revision as is. It likely won't be used anymore since importing a specific revision does not add value (the latest revision always works). It merely documents which revision was used when a module was published. AB: What about include-by-revision? MB: This may still be useful. I usually use include-by-revision but never import-by-revision. AB: What about augment drift? MB: I believe an import-by-revision in this case means import-by-min-revision. AB: I may have must statements in my augmenting module that make assumptions about the value space of the leafs being augmented. AB: There probably should be guidelines how to write must statements that are update friendly. MB: Instead "if module implemented it needs to be advertised" write "if module advertised it has been implemented" to allow in the future to add other ways to define and communicate conformance. MB: If I have a new conformance mechanism and I only implement a module partially, do I still advertise the module? JS: No, you do not implement the module so you do not advertise it. You likely advertise the new future conformance statement instead. MB: Any NETCONF specific text needs to be clearly marked since protocols may differ how announcements are implemented. AB: On constrained devices, the YANG library may not be local to the device. Everybody seemed to be OK with Y45-02. JS to add it to the issues list and to start a verification on the list. * Y34 remove/deprecate/replace the 'anyxml' statement AB: anyxml is terminal, there is no schema data within anyxml, except when we use it that way since we have no other choice. AB: I think my current thinking aligns with what the proposal is. KW: The logical extension of anyxml would be anyblob. JS: But this should be avoided since the goal is interoperability. LL: I like anyblob, anyxml was just a misnomer. MB: But in YANG patch, we do not want anyblob - we want YANG data. AB: I need the server to be encoding independent and I do not want encoding specific information in the schema. AB: Inside the server, there is no encoding. Encoding is something that happens when data is serialized. MB: LL, can you live with the current proposal? LL: Yes. But even with anydata we might not have a complete solution. MB: It is important to define how anydata is encoded in the various encodings, it is not an issue if the encoding of anyxml is not well defined in all encodings. Everybody seemed to be OK with Y34-05. JS to try another consensus call on the mailing list. * Y18 fix "when" expression context problem MB: Shall we verify Y18-01 on the mailing list? LL: I think I made some comments on the mailing list. I think your proposal is to introduce a temporary context node. MB: When would there be multiple instances? I guess leaf-lists. This may be a corner case. LL: I think the text should deal with the situation if there are multiple context nodes. MB: Your proposed text says if there is one, use it. If not, create a temporary one. Does it matter if there are multiple candidates? LL: I think we should say something, even if it is pick one of the many. MB: I will update the issue with this input. AB: If the particular node has instances, then the instances are evaluated. Like last time, we tasked MB and LL to work out a new proposal that covers the corner cases. * Y25 make enum numbering purely informative and optional LL: OK with declaring this dead if protocols start using the numeric value. MB should update the text that other encodings may use the numeric values. MB: Perhaps remove all encoding specific discussion and statements that the numeric value is not used. Everybody seems to be happy with Y25-02.