Minutes for NETMOD at interim-2015-netmod-2
||Minutes for NETMOD at interim-2015-netmod-2
NETCONF Data Modeling Language WG (netmod)
11th YANG 1.1 Virtual Interim
Wednesday, January 21, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
AB = Andy Bierman
IB = Ignas Bagdonas
JS = Juergen Schoenwaelder
KW = Kent Watsen
LL = Lada Lhotka
MB = Martin Bjoerklund
PO = Peyman Owladi
* Agenda Items
- VRFY Y09 (no consensus)
- VRFY Y16 (netconf-capability-change notification)
- VRFY Y34 (difference between Y34-02 and Y34-04)
- OPEN Y18 (MB action done)
- OPEN Y57
- OPEN Y58 (move to EDIT once NETCONF signals OK for NACM update?)
- OPEN Y45 (factor conformance and update rules out of 6020bis?)
- OPEN Y26 (can we assign someone to this?)
* Y09 introduce optional keys
MB: I do not understand how default values solve a problem, are
defaults always included in the instance identifier?
AB: Yes, every key has to have value in an instance identifier.
AB: You may leave out key values in a create request.
AB: Y09-03 is a way of documenting that a certain value acts as a
KW: How does this map to SQL?
PO: In SQL, the compound key must be unique.
MB: Y09-03 requires you to invent this special value, just to
indicate that no value is there.
AB: We have done this for years in SMIv2.
AB: I think this change falls out of the scope of the 1.1 update.
PO: Default values are a way to not expose the special NULL value
used by implementations.
AB: Changing the instance-identifier type has ripple effects.
JS: We have three choices: declare Y09 dead or find agreement on
either Y09-02 or Y09-03 (with a default to declare this dead if
we do not find agreement)
PO: What is the value of Y09-03 despite that you can leave out a key
in a create message?
PO: Can I leave out default key values or does an instance
identifier always contain all key components?
PO: How does with work with filtering?
LL: If you leave out a key in a subtree filter, you will get all not
just the default.
MB: How will Y09-03 interact with defaults basic mode? It works fine
with explicit mode, but will it work with report-all or trim
JS: I am concerned about changing the value set of a base type. I do
not see consensus developing for Y09-02. So we either see
whether we can find consensus on Y09-03 or if do not see the
value of it, we simply declare Y09 dead.
PO: I do not see the value in Y09-03, but it does not seem to hurt
MB: Note that NACM does not use instance-identifier literally.
MB: Is this not the same as extending the range?
AB: But this is a base type.
PO: Can you go from an int32 to an int64?
MB: No, you can not.
KW: Is it worth solving this problem at all?
LL: This is really important for routing modules since we may resort
to artificial keys.
Proposal: Declare Y09 dead since the goal (optional keys) results in
changes that reach beyond the scope of the YANG 1.1 effort.
* Y60 yang 1.1 upgrade and YANG 1.0 coexistence
KW: What happens if you load a YANG 1.1 module into a server?
MB: We need to have text concerning coexistence, should we track
this as a separate issue?
JS: The interesting case might be a NETCONF server supporting YANG
1.1 hitting a NETCONF 1.0-only client. But ideally, clients
upgrade quickly and this is a corner case in practice.
KW: We may also have to talk about module update rules.
Proposal: Create a new issue Y60 in order to track this.
* Y16 module advertisement optimization
JS: We have three options:
1) add a more specific notification
2) augment a module-set-id into the existing
3) simply give advice that once a client receives a
netconf-capability-change notification, it should
retrieve and check the module-set-id
AB: Why would a client treat a module change different than any
other capability change?
AB: Are we only suppressing module advertisements in the hello?
MB: Yes, we are only caching module advertisements.
Proposal: Augment module-set-id into the existing notification.
* Y34 remove/deprecate/replace the 'anyxml' statement
AB: The main difference is that root is restricted to top-level data
nodes while anydata is not.
MB: The non-restricted version is needed for YANG patch.
AB: There are three cases: 1) fixed top-level data nodes, 2) fixed
arbitrary data nodes, 3) compile-time decided data nodes (this
is what YANG patch uses).
JS: What is the benefit of restricting this to the root node?
MB: It makes it easier to parse the XML since the server knows that
it is a root node.
AB: We only allow ncx:root in RPCs, not in datastores.
MB: I am not sure which problem Y34-04 solves.
AB: I could also live with dropping Y34.
MB: In practice, you often use anydata when you write anyxml.
AB: YANG patch will continue to use anyxml.
MB: How does that work with JSON encoding?
AB: Dynamic type conversion as needed.
MB: If we use anyxml in YANG patch, is the result interoperable over JSON?
MB: The current JSON mapping is silent how anyxml is encoded.
MB: We could use anyxml in YANG patch and then detail there how this
is encoded using JSON.
JS: This may be fine until we hit the usage of this kind and several
anyxml usage today are already anydata.
We did run out of time, hopefully we can discuss this further on the
mailing list and resolve it before the next meeting (so we can get
back to OPEN issues.)