Minutes for NETMOD at interim-2015-netmod-2
minutes-interim-2015-netmod-2-1

=============================================================
NETCONF Data Modeling Language WG (netmod)
11th YANG 1.1 Virtual Interim
Wednesday, January 21, 2015, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================

* Participants
    
  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
      special value.
  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
      mode?
  
  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
      either.
  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
         netconf-capability-change notification
      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.)