Hi,
attached are the minutes of the 2015-09-07 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)
20th YANG 1.1 Virtual Interim
Monday, September 7th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================
* Participants
AB = Andy Bierman
G? = Gert ?
IB = Ignas Bagdonas
JS = Juergen Schoenwaelder
LL = Ladislav Lhotka
MB = Martin Bjorklund
* Data tree definition update (Martin, Lada)
See Lada's email concerning the different uses of data tree.
MB: I have done already most of the edits, but not yet checked in.
AB: The new definition combines multiple different trees into one.
LL: The wording may not be good enough, we should make it clear that
a "," really means "or".
* Extension statements and deviate-stmt / refine-stmt (Andy)
It seems groupings do not really anticipate extensions from an ABNF
point of view.
MB: I think the grammar is not the problem. But there is clearly
text missing and also not all statements can be refined (you
can't refine the type of a leaf for example).
AB: Properties like config true/false are often introduced when a
grouping is used instead of having this hardwired in groupings.
AB: Groupings are somewhat fragile, you can't easily move them
around, there are likely guidelines missing for groupings.
MB: I propose to add text that extension statements can be added
using a refine but the extension statement must define the rules.
MB: If you define an ephemeral statement, then the definition of the
statement must provide the details how it can be used.
LL: Shall we have restrictions on what an extension can do and what
it cannot do?
AB: There is the understanding of the annotation statement and then
there is the understanding of a specific defined annotation.
MB: It is difficult to define rules that make sure
extensions/annotations are backwards compatible.
AB: The usage must be client initiated and how you do that depends on
the specific circumstances.
MB: There is already text in the language extension section:
Care must be taken when defining extensions so that modules that use
the extensions are meaningful also for applications that do not
support the extensions.
AB: I will work on good and bad extension examples and incorporate the
text in the guidelines update.
MB: I can help with that.
LL: I will check that there is similar text in the metadata document.
MB: I will add text concerning the refinements.
* Data tree ordering (Lada)
LL: Is the data tree fundamentally unordered?
MB: Yes, the ordering is in the encoding parts.
Action: LL to check whether his comments have been resolved in the
svn version.
* Title of the document (Martin)
MB: Shall we remove "for the Network Configuration Protocol
(NETCONF)" from the title?
AB: I am concerned about people that want to use YANG for protocols
they do not talk about and they may even want to change YANG.
MB: The idea is to shorten the title and to leave it for the
introduction to explain what YANG was designed for.
JS: I am fine with a short title as long as there is clear text
about the purpose of YANG and its applicability in the text.
* Coexistence issue - allow version 1 modules to import version 1.1 modules?
(Martin)
MB: It should be fine for a version 1.1 module to import from an
version 1 module.
MB: What about allowing version 1 modules to import from 1.1 modules?
JS: What happens if a version 1 module augments an action defined in
a version 1.1 module?
MB: But how do we update inet-types.yang to 1.1?
JS: Version 1 modules can keep using version 1 inet-types.yang until
they want to use something present only in a newer revision.
LL: But what about import without revision?
LL: Submit an errata that a version 1 module can only import version 1
modules.
MB: How would this be advertised in the yang library?
MB: A (in 1) imports yang-types, B (in 1.1) imports yang-types,
yang-types exists in version 1 and 1.1 - which version will be
advertised?
AB: It will have to be the latest.
AB: I suggested that a version 1 module is parsed as a 1.1 module in
a mixed implementation and then you are fine to import a 1.1 module.
LL: I am fine with an automatic promotion.
MB: What about relaxing the rules only for modules that predate YANG 1.1?
AB: The server is going to have only one version, especially for
configuration.
Action: MB will start a thread on the mailing list and if needed we
continue this discussion next Monday.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
