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