Minutes for NETMOD at interim-2014-netmod-8
minutes-interim-2014-netmod-8-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2014-netmod-8 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2014-09-03 |
minutes-interim-2014-netmod-8-1
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.