Minutes for NETMOD at interim-2015-netmod-1
minutes-interim-2015-netmod-1-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2015-netmod-1 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-02-26 |
minutes-interim-2015-netmod-1-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
10th YANG 1.1 Virtual Interim
Wednesday, January 07, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================
* Participants
AB = Andy Bierman
BC = Benoit Claise
JS = Juergen Schoenwaelder
DR = David Reid
EV = Eric Voit
IB = Ignas Bagdonas
KW = Kent Watsen
LL = Ladislav Lhotka
* Pending Actions
- Y18 fix "when" expression context problem
Pending action MB...
- Y25 make enum numbering purely informative and optional
JS to start a thread on the mailing list. There once was rough
consensus for Y25-01 - we need to check what happens on the list.
- Y57 non-unique leaf-list
There was an action item for BL on 2014-10-15. Discuss today?
- Y45 better conformance mechanism
List of conformance use cases (action MB)
* Y07 do not allow when or if-feature on keys
This issue is in the REVIEW state but there was quite some
discussion on the mailing list. Where are we with this one?
LL: It was legal to have if-feature on a key in YANG 1.0, even though
it may not be too useful.
AB: Since YANG 1.0 does not have optional keys, the server is going
to reject this unless the expressions do match the parent (in
which case the if-feature or when statement is redundant but
not harmful).
AB: The only valid if-feature/when must be redundant.
JS: Should we add text to the guidelines about this so that tools
are encouraged to flag this?
AB: I agree.
JS to followup on the mailing list thread, trying to summarize what
was discussed today and to force a resolution of this issue.
* Y59 restrict use of 64-bit numbers in XPath expressions
Moved to open, quite some discussion recently on the mailing list.
Where are we with this one?
LL: I updated the text in the issues file just a few minutes
before the meeting.
JS: This is SVN revision 104.
AB: The text is fine.
Proposal: Adopt Y59-01
* Y45 better conformance mechanism
How to resolve this? Do we need to collect the requirements a
solution must satisfy? It sometimes feels like going in circles on
this.
Skipped since MB was not joining the meeting.
* AOB
LL: What about a structure statement as part of YANG 1.1?
KW: May not work since RESTCONF won't wait for YANG 1.1.
LL: It may be OK to use it in RESTCONF as an extension but there
should be an 'official' solution.
AB: It is not a step forward to use three different schema languages
(YANG, XSD, something for JSON) in RESTCONF.
JS: What is the benefit of having this extension rolled into YANG 1.1?
JS: We should encourage using YANG extensions where possible. If a
"structure" YANG extension that works with YANG 1.0 and 1.1 can
be written today, then I do not see an urgent need to make this
part of YANG itself.
A team of people (AB, KW, MB?, LL?) will produce an initial I-D
defining such a YANG extension. Once such an I-D is available, JS
will work with the NETCONF chairs and Benoit Claise to (a) determine
whether there is support for this approach in the community and to
(b) determine how this can be best handled process wise (that is
which of the two WGs can host this work).