============================================================= NETCONF Data Modeling Language WG (netmod) 9th YANG 1.1 Virtual Interim Wednesday, December 03, 2014, 16:00-18:00 CET Minutes Juergen Schoenwaelder ============================================================= * Participants - AB = Andy Bierman - BL = Balazs Lengyel - DR = David Reid - IB = Ignas Bagdonas - JS = Juergen Schoenwaelder - LL = Lada Lhotka - RP = Reinaldo Penno * Y09 introduce optional keys Martin did writeup Y09-03. On 2014-11-19, we agreed to Y09-03. This should be a quick check that we are still in sync on this. There was quite some mailing list discussion as well. It seems this boils down to the question whether expanding the syntax of instance identifiers falls into the scope of YANG 1.1. - LL: The not() assumption was false. - BL: I prefer the solution which requires default values. - JS: I have concerns about solutions that require to change the instance identifier syntax - this may be outside the scope of YANG 1.1. Proposal: Adopt Y09-03 and we will see whether this validates on the mailing list. * Y16 module advertisement optimization Martin has done his action item and we should try to decide between Y16-01, Y16-02, and Y16-03. - BL: I am happy with Y16-03. - LL: A YANG 1.0 implementation won't understand this advertisement. - AB: A YANG 1.1 client won't look at a YANG 1.1 module. - JS: The "MUST either advertise them as before, or advertise something like" text is confusing, it seems the advertisement should be mandatory for 1.1. - AB: YANG 1.0 modules will continue to be advertised as before. - BL: Does this require an update of RFC 6244? - JS: The sentence in section 2.1 of RFC 6244 should be OK. Proposal: Adopt Y16-03 (replace the word 'hash' with module set identifier) and move this issue to VRFY. * Y18 fix "when" expression context problem Did Martin complete the action item? If so, can we wrap this up? - JS: Pending action, skipped discussion of this issue. * Y59 restrict use of 64-bit numbers in XPath expressions New issue, no reaction on the mailing list so far. Should we propose adoption as a bug fix / clarification issue? - JS: Is the proposal to declare expressions with these types illegal? - LL: Not, it should be more a warning about possible consequences. - LL: May even belong to the security considerations section. - AB: My code does not always convert to doubles but I need to check. - AB: It is hard to make this an error. - JS: Probably we need to warn that in general numbers are converted to doubles and thus rounding errors may also cause issues in other contexts. Proposal: Move this to open. LL to propose new text. * Y25 make enum numbering purely informative and optional Last time we discussed this we reached rough consensus for Y25-01. Shall we try to resolve this on the list? If so, JS to create a thread, e.g., to VRFY adoption of and then we will see. - AB: There is a new xpath function proposed to return the number. - AB: I am not happy with this auto-numbering feature, we need to support it but it is not used in NETCONF or RESTCONF. - AB: However, one use case may be the COMI draft. Action: JS to start a thread on the mailing list and then we will see whether there is consensus. * Y26 allow mandatory nodes in augment Discussion on the list went into philosophical aspects. The question is whether someone can write down rules in which conditions adding mandatory nodes in an augment is OK. Volunteers for a homework? - LL: I think it is difficult to write this text. - LL: An indentityref may point to an for the client unknown identity. - BL: This is similar to expanding value ranges. - LL: I suggest to simple remove this constraint and to trust module authors that they are not going to break things. - LL: I propose to add text to the usage guidelines to tell people to not break modules. - AB: We need to maintain contract rules. - AB: Mandatory nodes can not be required for anything an old client is doing. - AB: The template with the client provided discriminator works, not sure how to put this into text. - LL: But I can also break rules with must statements. - AB: Yes, there are other ways to break things. That is why this needs to be conditional. - JS: Having tools to flag things that potentially break things is a good thing. Action: LL to draft some text and then we can work on it. * Y58 associate an actions with a data node Verification failed since there is no NACM support for actions nor are actions part of the NETCONF architecture (Andy). Phil questions the need for actions since everything can be done with RPCs. Changed back to OPEN. Need to decide how to proceed with this one. - LL: Is this possible to do in RESTCONF? - AB: We would use a RESTCONF post to an /operations resource. Action: JS to talk to the NETCONF chairs whether such a NACM update can be chartered if NETMOD has otherwise agreement to support actions. * Y34 remove/deprecate/replace the 'anyxml' statement Quite some debate on the mailing list. Apparently some think anydata means 'any data in the encoding used' while others think 'anydata is data that can be modeled in YANG'. Andy suggested to restrict what can be in anyxml. We also see differences in opinion what the function of an encoding really is. Another obstacle are the lexical representation rules for instance-identifier (9.13.3 of RFC 6020). - LL: I think anydata is any data conforming to the underlying encoding. - JS: I think this is interesting but problematic. What is the value of an object that contains XML or JSON or CBOR or ...? - BL: Back in a day, we wanted to allow config modeled in XML. - AB: In YANG 1.0, we tried to treat anyxml as if it would be a leaf. I do not think tail-f supports it at all. - JS: MB proposed to have anydata that is always bound to the rules of things expressable in YANG. - AB: We produce a hierarchy of nodes in JSON for anyxml, everything is a container or a string and we have no problem with round trip conversions. - LL: In XML you can have attributes, PIs etc. - AB: I believe the useful uses of anyxml are actually not a type but a statement to declare a root of a subtree. Proposal: Go with Y34-04, need to check whether this causes issues to any of the current usages of anyxml. - AB: We only allow usage of root only in notifications / RPCs, not in datastores. - AB: It may be OK to use anyxml within extensions (e.g. the mount use case). * Y49 clarify nested submodule behavior Need to discuss Martin's solution proposal Y49-03. - LL: I added Y49-04. - AB: MB said that submodules can be compiled on their own. - AB: I prefer to make things simpler. - BL: I believe with LL and data hiding between submodules is something we do not need. - AB: There should only be a single namespace. Adopt solution proposal Y49-04? Need to check with MB.