Minutes for NETMOD at interim-2015-netmod-5
minutes-interim-2015-netmod-5-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2015-netmod-5 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-03-05 |
minutes-interim-2015-netmod-5-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
14th YANG 1.1 Virtual Interim
Wednesday, March 4th, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================
* Participants:
JS = Juergen Schoenwaelder
MB = Martin Bjorklund
KW = Kent Watsen
AB = Andy Bierman
DR = Dan Romascanu
LL = Lada Lhotka
* Y45 better conformance mechanism
JS provided a solution proposal that was discussed and a bit fine
tuned during the discussion. This will be added to the issue list
as solution Y45-02.
Scope of the work:
- A conformance framework for defining conformance that can cut
through sets of modules (and their features) may be needed at
some point in time but it seems that this can be done later once
there is more experience and such a conformance framework is not
required to solve in YANG 1.1.
Simple solution:
- Typedefs must not change their value space or semantics. If this
is needed, a new typedef needs to be created. This does not
affect the ability to make bug fixes.
- Groupings must not change their structure or semantics. If this
is needed, a new grouping needs to be created. This does not
affect the ability to make bug fixes.
- Leafs can have their value space extended but this is not
automatic.
- The definition of 'deprecated' and 'obsolete' may need some
clarification, the wording borrowed from SMIv2 may not be
precise enough for configuration management.
- We can consider to define RPCs that allow to retrieve possible
value sets for certain types (or leafs?). But this does not have
to be part of the YANG 1.1 specification; this could also be
part of the YANG library (and such RPCs might even be an
optional feature).
Discussion
AB: This could lead to corner cases for enums that get updated
regularly.
MB: But in such cases, identities might be a better option.
MB: Can we allow to add enums if they are scoped by a new feature?
KW: This seems to be OK.
AB: But the client has no control if the feature is enabled, so this
can't be done.
MB: Does this imply that import-by-revision is not needed anymore?
JS: Probably simplest to leave import-by-revision as is. It likely
won't be used anymore since importing a specific revision does
not add value (the latest revision always works). It merely
documents which revision was used when a module was published.
AB: What about include-by-revision?
MB: This may still be useful. I usually use include-by-revision but
never import-by-revision.
AB: What about augment drift?
MB: I believe an import-by-revision in this case means
import-by-min-revision.
AB: I may have must statements in my augmenting module that make
assumptions about the value space of the leafs being augmented.
AB: There probably should be guidelines how to write must statements
that are update friendly.
MB: Instead "if module implemented it needs to be advertised" write
"if module advertised it has been implemented" to allow in the
future to add other ways to define and communicate conformance.
MB: If I have a new conformance mechanism and I only implement a
module partially, do I still advertise the module?
JS: No, you do not implement the module so you do not advertise
it. You likely advertise the new future conformance statement
instead.
MB: Any NETCONF specific text needs to be clearly marked since protocols
may differ how announcements are implemented.
AB: On constrained devices, the YANG library may not be local to the
device.
Everybody seemed to be OK with Y45-02. JS to add it to the issues list
and to start a verification on the list.
* Y34 remove/deprecate/replace the 'anyxml' statement
AB: anyxml is terminal, there is no schema data within anyxml,
except when we use it that way since we have no other choice.
AB: I think my current thinking aligns with what the proposal is.
KW: The logical extension of anyxml would be anyblob.
JS: But this should be avoided since the goal is interoperability.
LL: I like anyblob, anyxml was just a misnomer.
MB: But in YANG patch, we do not want anyblob - we want YANG data.
AB: I need the server to be encoding independent and I do not want
encoding specific information in the schema.
AB: Inside the server, there is no encoding. Encoding is something
that happens when data is serialized.
MB: LL, can you live with the current proposal?
LL: Yes. But even with anydata we might not have a complete solution.
MB: It is important to define how anydata is encoded in the various
encodings, it is not an issue if the encoding of anyxml is not
well defined in all encodings.
Everybody seemed to be OK with Y34-05. JS to try another consensus
call on the mailing list.
* Y18 fix "when" expression context problem
MB: Shall we verify Y18-01 on the mailing list?
LL: I think I made some comments on the mailing list. I think your
proposal is to introduce a temporary context node.
MB: When would there be multiple instances? I guess leaf-lists. This
may be a corner case.
LL: I think the text should deal with the situation if there are
multiple context nodes.
MB: Your proposed text says if there is one, use it. If not, create
a temporary one. Does it matter if there are multiple candidates?
LL: I think we should say something, even if it is pick one of the many.
MB: I will update the issue with this input.
AB: If the particular node has instances, then the instances are evaluated.
Like last time, we tasked MB and LL to work out a new proposal that
covers the corner cases.
* Y25 make enum numbering purely informative and optional
LL: OK with declaring this dead if protocols start using the numeric
value. MB should update the text that other encodings may use
the numeric values.
MB: Perhaps remove all encoding specific discussion and statements
that the numeric value is not used.
Everybody seems to be happy with Y25-02.