============================================================= NETCONF Data Modeling Language WG (netmod) 4th YANG 1.1 Virtual Interim Wednesday, September 3rd, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - MB = Martin Bjorklund - PO = Peyman Owladi - DR = David Reid - BC = Benoit Claise - AB = Andy Bierman - LL = Ladislav Lhotka - MJ = Mahesh Jethanandani * Y09 introduce optional keys PO: Why is at least one key element required? PO: What if in an xpath expression suddenly evaluates to a node set rather than a single node? MB: We need to extend the instance-identifier syntax to be able to express that a certain key element is absent. PO: Right now, an instance-identifier is valid xpath, we should not diverge from it. JS: If you allow to add an optional key while revising a YANG module, does this not potentially affect other modules? Does this at the end require import by revision everywhere? JS: The concern is breaking the contract when adding an optional key, but this is likely the most interesting use case. MB: Yes, this may be problematic. Perhaps we should not allow to change the key statement, i.e., optional keys can't be added later on. JS: You can have optional keys today by designing special 'null' values for optional key elements. MB: The primary use case is not necessarily YANG module updates. The workarounds you mention as possible today but they are clumsy. AB: Does this proposal affect error-path? MB: No, error-path is already an xpath expression. As long as instance-identifier remain a subset of xpath, this will work. Proposal: adopt Y09-02 but do not allow leafs to be added to a key in a module update and the instance-identifier syntax needs to be extended to express that certain key elements have no value. * Y34 remove/deprecate/replace the 'anyxml' statement LL: Why do we need anydata at all? MB: There are use cases for anyxml although rare. JS: Example: Kent's configlets. MB: Example: Definition of edit-config. AB: I have something we call a docroot, something that holds a top-level YANG node. JS: What is the difference between docroot and the proposed anydata? AB: The docroot is anydata restricted to top-level YANG nodes. MB: Since NETCONF is defined using anyxml, changing anyxml is changing the protocol. LL: Leave anyxml as it is. LL: But this is hard for JSON. MB: That is the reason why I propose to add anydata, which may be easier to deal with. AB: The reason implementations do not support mixed mode or PIs is to avoid passing raw data to callbacks and hence everything is restricted to a few types in the implementations I am familiar with. AB: I support anyxml but make it clear that it is non-interoperable. LL: Yes, and I propose to leave it completely open how anyxml is represented in JSON. MB: If we keep anyxml and mark it as should not be used, do we even have to translate anyxml into JSON? MB: If we have anydata, why can't you follow the usual JSON rules? AB: It seems to work for us, except every value is JSON encoded as a string. LL: You need to know the difference between a list and a container. AB: My implementation hands the tree to the application. AB: We only use docroot in RPC definitions and everything else is theoretical and of no practical use. MB: There is one other use case: A list say containing the last N notifications. It is still not anyxml but anydata. LL: We could have simpler rules for anydata that work like generic XML to JSON translators. MB: What about namespaces? I think we need them. LL: I am not sure we need them. AB: So how do the many online XML to JSON translators work? LL: They use arbitrary solutions for things like namespaces. MB: The translator needs all the data models. I personally think this is fine. JS: For ncclient, the interface to the lower layer is typeless and it is a significant change to make it type aware etc. AB: Our server will convert things as needed and basically ignore the JSON type. LL: I started with what is the most natural representation. Otherwise, what is the value of JSON? AB: For me, the value is that JSON is more compact data encoding. I do not care about having type information in the encoding. Our code has no interest to reject data just because the JSON type was wrong. Making JSON types authoritative seems backwards. LL: What about making it legal to allow sending integers as strings? JS: If I am allowed to send strings, the world changes for me. MB: This also solves the problem of dealing with numbers in unions. MB: In edit-config, it is not just XML elements but also attributes. JS: So we have to keep anyxml for these rare corner cases (typically the definition of RPCs). But we should have big warnings about the usage of anyxml in data models and instead introduce anydata. MB: Even if we allow encoding of values as strings and require that the receiver be able to translate to the proper YANG type, we still have the namespace problem. LL: What is the problem with normal data? MB: You need the mapping URI to YANG module name. JS: A URI is not something ugly. In fact, you use the YANG namespace statement to define the namespace. LL: URIs tend to be longer than module names and they can contain more 'interesting' characters. JS: But the URI character set is restricted. LL: A URI can contain colons so the separate colon cannot be used. JS: Yes, we need to pick a different delimiter. Some use {}name. I do not care much which character is used. JS: I am concerned that using two different identifiers to identify what is essentially the same namespace adds complexity for no real value. Even operationally, when people are confronted with JSON and XML snippets, they are exposed to different identifiers for the same thing. I do not see how that makes things simpler. Proposal: Keep anyxml and add text that usage of anyxml in regular data models is generally not interoperable and that anyxml should only be used in certain special cases (e.g., the definition of NETCONF RPCs). Add an anydata statement that is restricted to data that can be defined using YANG. For the JSON mapping, allow string encoding and require the receivers are expected to do type conversions in case the JSON type does not match the YANG type instead of treating a JSON type mismatch as an error. For anydata, the JSON encoding should be well defined. No agreement has been reached yet on the handling of namespaces, that is whether module names or URIs should be used.