Minutes for NETMOD at interim-2015-netmod-18
minutes-interim-2015-netmod-18-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2015-netmod-18 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-09-15 |
minutes-interim-2015-netmod-18-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
21st YANG 1.1 Virtual Interim
Monday, September 14th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================
* Participants
AB = Andy Bierman
BC = Benoit Claise
JS = Juergen Schoenwaelder
KW = Kent Watsen
LL = Ladislav Lhotka
MB = Martin Björklund
TC = Tim Carey
* Coexistence Discussion
There was some mailing list discussion around this topic since the
last virtual interim meeting. Have we arrived at a resolution?
LL: I think there can be issues even with a version 1 only server.
MB: Why is there a problem with a version 1 only server?
LL: What if client knows a 1.1 module and picks it instead?
MB: The client must respect the modules announced by the server.
MB: The latest revision is the latest revision advertised by the
server, not the latest locally known revision.
JS: We seem to have three options:
1. If there is a 1.1 revision somewhere in the imports, the
version 1 module is parsed as a 1.1 module.
2. Version 1 modules are not allowed to import 1.1 modules, this
means a server may need to announce the version of a module
implemented and the version that may be used to resolve
version 1 imports without revision.
3. We allow version 1 modules to import from version 1.1
modules.
AB: The goal is not to break old clients. If adding 1.1 modules
breaks clients, this is a problem for deployment.
KW: Perhaps the problem is not big enough to worry about? This is
just a one time software version upgrade.
AB: What if we next do 1.2 etc? A massive upgrade without a real
benefit may not be useful.
AB: This problem would not exist if there would have been import by
revision everywhere.
AB: The version 1 client only knows about the hello module
advertisements. So what about allowing an old client to continue
with its view of world even if the server implements a 1.1
version?
LL: Does this not break with default statements that have changed a
bit in YANG 1.1?
MB: The old client will not see the default statement, I do not
think this is a problem.
KW: But it impacts things, e.g., when the client uses with-defaults.
AB: It is important that the version upgrade to YANG 1.1 is a cheap
and gradual process.
MB: I agree.
MB: If we upgrade ietf-interfaces to YANG 1.1, we still want to be
able to use the YANG version 1 version of ietf-ip, which has not
changed at all. We do not want to force a revision of ietf-ip
just because ietf-interfaces a server implements got upgraded to
1.1.
TC: Why would a 1.0 client not utilize 1.0 data models?
MB: Does this mean to implement multiple revisions? It depends on the
changes whether this is expensive.
TC: Does the minor version not imply nodes should be backwards
compatible?
JS: Lets not confuse data model version number and the version of
the language data models are written in.
JS: Announce YANG 1 modules via <hello> messages and YANG 1.1
modules via the YANG the library as long as they are
semantically consistent, that is the YANG version 1 module
remains a proper valid subset of the module written in YANG 1.1.
KW: Is there an issue with get-schema?
MB: No, there is a version input parameter that makes this clear.
Action: Add text and examples to the guidelines document explaining
how servers implementing YANG 1.1 modules can support
modules written in YANG version 1 and when in which
situations servers might need to stop supporting modules
written in YANG version 1.
* Constraints Discussion
LL and MB discuss something internally, they will summarize the
proposal to the list once they conclude the discussion.