Minutes for NETMOD at interim-2014-netmod-9
minutes-interim-2014-netmod-9-1

=============================================================
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
      {<uri>}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.