=============================================================
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.