============================================================= NETCONF Data Modeling Language WG (netmod) 11th YANG 1.1 Virtual Interim Wednesday, January 21, 2015, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants AB = Andy Bierman IB = Ignas Bagdonas JS = Juergen Schoenwaelder KW = Kent Watsen LL = Lada Lhotka MB = Martin Bjoerklund PO = Peyman Owladi * Agenda Items - VRFY Y09 (no consensus) - VRFY Y16 (netconf-capability-change notification) - VRFY Y34 (difference between Y34-02 and Y34-04) - OPEN Y18 (MB action done) - OPEN Y57 - OPEN Y58 (move to EDIT once NETCONF signals OK for NACM update?) - OPEN Y45 (factor conformance and update rules out of 6020bis?) - OPEN Y26 (can we assign someone to this?) * Y09 introduce optional keys MB: I do not understand how default values solve a problem, are defaults always included in the instance identifier? AB: Yes, every key has to have value in an instance identifier. AB: You may leave out key values in a create request. AB: Y09-03 is a way of documenting that a certain value acts as a special value. KW: How does this map to SQL? PO: In SQL, the compound key must be unique. MB: Y09-03 requires you to invent this special value, just to indicate that no value is there. AB: We have done this for years in SMIv2. AB: I think this change falls out of the scope of the 1.1 update. PO: Default values are a way to not expose the special NULL value used by implementations. AB: Changing the instance-identifier type has ripple effects. JS: We have three choices: declare Y09 dead or find agreement on either Y09-02 or Y09-03 (with a default to declare this dead if we do not find agreement) PO: What is the value of Y09-03 despite that you can leave out a key in a create message? PO: Can I leave out default key values or does an instance identifier always contain all key components? PO: How does with work with filtering? LL: If you leave out a key in a subtree filter, you will get all not just the default. MB: How will Y09-03 interact with defaults basic mode? It works fine with explicit mode, but will it work with report-all or trim mode? JS: I am concerned about changing the value set of a base type. I do not see consensus developing for Y09-02. So we either see whether we can find consensus on Y09-03 or if do not see the value of it, we simply declare Y09 dead. PO: I do not see the value in Y09-03, but it does not seem to hurt either. MB: Note that NACM does not use instance-identifier literally. MB: Is this not the same as extending the range? AB: But this is a base type. PO: Can you go from an int32 to an int64? MB: No, you can not. KW: Is it worth solving this problem at all? LL: This is really important for routing modules since we may resort to artificial keys. Proposal: Declare Y09 dead since the goal (optional keys) results in changes that reach beyond the scope of the YANG 1.1 effort. * Y60 yang 1.1 upgrade and YANG 1.0 coexistence KW: What happens if you load a YANG 1.1 module into a server? MB: We need to have text concerning coexistence, should we track this as a separate issue? JS: The interesting case might be a NETCONF server supporting YANG 1.1 hitting a NETCONF 1.0-only client. But ideally, clients upgrade quickly and this is a corner case in practice. KW: We may also have to talk about module update rules. Proposal: Create a new issue Y60 in order to track this. * Y16 module advertisement optimization JS: We have three options: 1) add a more specific notification 2) augment a module-set-id into the existing netconf-capability-change notification 3) simply give advice that once a client receives a netconf-capability-change notification, it should retrieve and check the module-set-id AB: Why would a client treat a module change different than any other capability change? AB: Are we only suppressing module advertisements in the hello? MB: Yes, we are only caching module advertisements. Proposal: Augment module-set-id into the existing notification. * Y34 remove/deprecate/replace the 'anyxml' statement AB: The main difference is that root is restricted to top-level data nodes while anydata is not. MB: The non-restricted version is needed for YANG patch. AB: There are three cases: 1) fixed top-level data nodes, 2) fixed arbitrary data nodes, 3) compile-time decided data nodes (this is what YANG patch uses). JS: What is the benefit of restricting this to the root node? MB: It makes it easier to parse the XML since the server knows that it is a root node. AB: We only allow ncx:root in RPCs, not in datastores. MB: I am not sure which problem Y34-04 solves. AB: I could also live with dropping Y34. MB: In practice, you often use anydata when you write anyxml. AB: YANG patch will continue to use anyxml. MB: How does that work with JSON encoding? AB: Dynamic type conversion as needed. MB: If we use anyxml in YANG patch, is the result interoperable over JSON? MB: The current JSON mapping is silent how anyxml is encoded. MB: We could use anyxml in YANG patch and then detail there how this is encoded using JSON. JS: This may be fine until we hit the usage of this kind and several anyxml usage today are already anydata. We did run out of time, hopefully we can discuss this further on the mailing list and resolve it before the next meeting (so we can get back to OPEN issues.)