o=============================================================
NETCONF Data Modeling Language WG (netmod)
4th YANG 1.1 Virtual Interim
Wednesday, August 27th, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - LL = Lada Lotka
  - PO = Peyman Owladi
  - DR = David Reid
  - KW = Kent Watsen
  - MB = Martin Bjorklund

* Y44: add a mechanism to parameterize error-message

  AB: We really want full blown XPATH in error messages?
  MB: If you already have an XPATH engine, why not?
  JS: What is you get a nodeset?
  MB: This is the string rendering of the nodeset.
  AB: What is the context for the XPATH evaluation?
  MB: The same as for a must expression evaluation.
  AB: But this can be in an RPC input.
  MB: Yes.
  AB: An alternative is to pass additional information to the NMS and
      then the error message would a format string and the NMS would
      plug data into the format string.
  AB: What if curly braces show up elsewhere?
  JS: Would we need a mechanism to escape the braces?
  AB: Sounds this could be done by the NMS.
  KW: It can be complex to identify which interface caused a problem.
  AB: The error-path has the details in machine readable format.
  AB: We only needs this for must expressions really.
  AB: We used $() to enclose XPATH expressions and we found that easier.
  KW: The issue how to identify the expression, not stuff inside the
      expression.
  AB: This is not lightweight to do.
  KW: Can a server simply return the string if it does not want to do
      XPATH evaluation?
  MB: RFC 6020 section 7.5.4.1 says that the error-message (if
      present) is to be used. What if both error-message and
      x-error-message exist?
  MB: If we drop Y44, can an implementation still generate a better
      error message.
  AB: Right now, this is a MUST.
  MB: I would like to allow 'better' error messages.
  AB: What about using other fields in the error-info?
  PO: What about rendering an extended error message into error-info?

  Proposal: Move to the issue to dead and leave RFC 6020 section
  7.5.4.1 unchanged. Extended error messages can be supported by a
  YANG extension and shipped in <error-info>.

* Y47: bit name too restrictive

  MB: Enum names are not restricted.
  JS: Enum names are very different from bit names but some of this is
      inherent.
  MB: Is this worth fixing? Having to support two rules for YANG 1.0 and
      YANG 1.1 is having costs.
  MB: If we were to restart, we likely would restrict enum names and
      relax bit names and make them the same. Too hard to do in YANG 1.0

  Proposal: Move to dead as it is not worth fixing it. Or more
  precisely, a proper fix would make the restrictions for enum names
  and bit names the same and that won't be backwards compatible.

* Y49: clarify nested submodule behavior

  MB: I prefer solution Y49-02.
  PO: What is the aim of a submodule? Is it hiding?
  MB: No, it is not hiding.
  PO: OK, so it is organization and readability.
  AB: Agree, this is not about hiding things. But, submodules have
      different scopes.
  MB: But from the XML perspective, it is one namespace.
  AB: I could go with Y49-02. If there is no include statement in the
      main module, it is not exported.
  MB: I would even say this is an error.
  MB: Other alternative: everything is exported (would be a 3rd
      solution).
  AB: Currently, if you split a submodule into smaller pieces, this
      ripples through.

  Action:

  - MB to write up Y49-03.

* Y55: clarify type in union

  AB: We could say unions are always strings in JSON.
  MB: If you send 1 as number over JSON, can it still be
      considered a string?

  Proposal: Adopt Y55-01.