Hi,
attached are the minutes of the 2015-10-12 virtual interim meeting.
Please let me know if something needs fixing.
You can find all the virtual interim meeting minutes next to the YANG
1.1 issue list in the NETMOD WG subversion repository:
http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
=============================================================
NETCONF Data Modeling Language WG (netmod)
22nd YANG 1.1 Virtual Interim
Monday, October 12th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================
* Participants
AB = Andy Bierman
DR = Dan Romascanu
JB = James Bensley
JS = Juergen Schoenwaelder
KW = Kent Watsen
LL = Ladislav Lhotka
MB = Martin Björklund
RW = Robert Wilton
SM = Scott Mansfield
* VRFY mandatory nodes in augments (Y26 related)
https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU
MB: I am not convinced we should change MUST NOT to SHOULD NOT.
RW: This comes up in practice and the MUST NOT partially conflicts
with RFC 6087bis.
MB: I understand the use case but tools would not be able to
interpret a SHOULD reliably.
RW: Would a tool not be able to generate a suitable warning?
RW: Within IETF, peer review should catch bad uses. Companies will
receive customer feedback.
LL: In some cases, modules are designed to make mandatory augments safe.
Conclusion: We go with SHOULD NOT and we move the text from RFC
6087bis into the YANG 1.1 specification to avoid a dependency on RFC
6087bis.
* OPEN when statement context clarification
https://mailarchive.ietf.org/arch/msg/netmod/_Ab-__IOsGj7FOv_OEJmfX0wG_8
MB: I think I recall that we arrived on the mailing list at some
text we agreed to.
MB: I can summarize the final proposal check it on the mailing list.
Action: MB will send the conclusions to the mailing list for
verification.
* VRFY module name uniqueness
https://mailarchive.ietf.org/arch/msg/netconf/CyWQQU9FnyJJG88j81VE8Q2Nh8U
MB: I tend to agree with Randy that we really want MUST but it is
difficult to achieve this without a central registry.
MB: Perhaps state that within a server module names MUST be unique.
KW: This is already implied by the YANG library.
Conclusion: State that module names MUST be unique within a server.
The SHOULD be globally unique does not change.
* VRFY anydata clarification
https://mailarchive.ietf.org/arch/msg/netmod/qiAkN9QA0SrjHV82W3HQEYUI-VI
Also note Lada's comment that anydata should exclude anyxml from the
"unknown set of nodes that can be modeled with YANG". Lada later
asked whether anydata can have attributes in the XML encoding. (Not
sure I got this right, Lada please correct me.)
MB: Exclusion of anyxml is fine.
JS: I agree.
LL: What about attributes?
MB: Attributes are not tied to data nodes.
LL: What about extensions?
LL: If there is no data model and you receive attributes, is this
legal or not?
MB: I think it should be legal to have attributes in the anydata
content if we allow attributes on data nodes.
Conclusion: Add text to exclude anyxml but leave the rest of the
wording as is.
* OPEN more than one revision of a module
https://mailarchive.ietf.org/arch/msg/netmod/sBVhgKtO7Pjsd1GzybqNe3DtVSo
MB: Unclear what the question is. Is it about advertising multiple
revisions in situations where modules got extended?
Action: MB to followup on the mailing trying to figure out what is
behind this question.
* OPEN choices corner cases
Balazs asked a couple of questions concerning nested choices on the
list. Is there anything concrete to be done for YANG 1.1?
LL: I do not think that any changes are needed. This can get tricky
but it is not a specification problem.
LL: Perhaps discuss in the guidelines document some of the cases
that were brought up on the list?
MB: Make sure the text covers Balazs first example (I will take a
look).
AB: I did not agree with any of Balazs' requests for changes.
Conclusion: Nothing to be done in YANG 1.1, perhaps good to discuss
examples further in the guidelines documents, LL will take a look.
* AOB
MB: YANG 1.1 has a dependency of YANG library.
JS: I can contact the NETCONF chairs to check the status and the
process forward.
AB: There was one issue with modules with import without revisions.
MB: Is this a question concerning YANG library or does this affect
YANG 1.1?
AB: It is a question concerning YANG library.
MB: In hindsight, I think we should have used the JSON instance
identifier notation in XML as well.
AB: I will look into the YANG library so that we can get things out.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
