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

* Participants:
    
  AB = Andy Bierman
  BL = Balasz Lengyel
  DR = Dan Romascanu
  IB = Ignas Bagdonas
  JS = Juergen Schoenwaelder
  KW = Kent Watsen
  MB = Martin Bjorklund
    
* YANG 1.1 Conformance

** https://tools.ietf.org/html/draft-bjorklund-yang-conformance-problem-00

  AB: Concerning A1, notifications are not required to implement if
      the server does not implement notifications in general.
  JS: Some wordsmithing of A1 might make this clearer.
  MB: A2 should be more precise that implements means implementing
      data nodes, rpcs, and notifications.
  AB: I am not sure about C1, if you need only a subset of a module
      and there is no handy feature for excluding the rest, there is a
      problem.
  MB: I believe C1 summarizes how things work today.
  AB: Are we trying to come up with tighter rules for humans or for
      tools to take advantage of the tighter rules?
  AB: I am not sure YANG 1.0 specifies C1 explicitly somewhere.
  JS: Does A3 not follow from A2?
  KW: A3 is more a corollary of A2.
  AB: The high-level problem is how to create and maintain the
      information needed to achieve A4. If it is too difficult to
      maintain and manage this information, things will not work in
      practice.
  AB: A4 is not the problem statement because we need to capture the
      maintenance problem.
  AB: Sometimes a robust solution is more verbose. Auto-numbering is an
      example where a fancy mechanisms makes things harder to use.
  MB: Perhaps we should not allow extensions of value spaces of
      typedefs (except identities that are extensible).
  
  MB: P1 is typedef-drift.
  JS: P1a-01 has the scope problem - if you want a new revision of a
      typedef, you have to implement the new revision everywhere.
      Similarly, if you need one updated type of inet-types, you have
      potentially to implement N other updates that come along with
      the new revision.
  MB: Question: If value space extension are problematic for typedefs,
      is it still OK to extend the value space of a leaf? I would say yes.
  JS: You might still break must constraints in other modules in this
      way. And for config false, things are very different.
  KW: In the netconf server configuration data model, almost
      everything is defined via groupings. If I can't extend them,
      things become problematic.
  AB: You can copy the groupings, may not look as nice.
  AB: Groupings are often written with a certain context in mind but
      then they can be used in very different contexts.
  MB: Another solution would be P1b-03 - typedefs never change.
  
  MB: P2 is showing that import-by-revision can lead to unresolvable
      conflicts requiring import updates (revision update ripple problem)
  AB: I think we should try to find a solution that avoids import-by-revision.
  MB: I agree.
  MB: Import by min revision does resolve this issue, but then it
      becomes unclear again which version of a typedef was used.
  JS: Import by min revision resolves P2, but then P1 is a problem
      again. To fix P1, you want import by exact revision, which then
      breaks P2 again.
  KW: Yes, and I can't cherry pick a single updated typedef from a
      module with N typedefs.
  
  MB: P3 is primarily about deprecated definitions, which then are
      optional to implement.
  JS: Interesting discussion what deprecated and obsolete means.
  BL: I think deprecated should mean "must still be implemented".
  KW: I think obsolete should mean "must not be implemented".
  KW: It would be nice if there would be an expire time associated
      with deprecated.
  JS: But you can already create warnings as soon as something is
      deprecated. Why do you need an expire time?
  KW: Other application maintainers may need to know that in order to
      plan they software update process.
  MB: I think we are talking about an automatic obsolete, i.e., if the
      timer expires, the definition moves from deprecated to obsolete.
  MB: P5 is about missing feature modularity
  BL: Perhaps the guideline here must be that you should not augment
      into something if that something is not essential to have; keep
      the tree flat.
  
** https://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04

  AB: I think we worked out that isolated problems can be solved, but
      the solutions do not work together.
  AB: Grouping drift is a major problem where I do not know how solve
      this (other than not allowing grouping changes)
  AB: We need to think about runtime solutions for certain things like
      identities.
  AB: I do not think that an implementation has to implement all
      identities derived from a common base.
  MB: I agree.
  AB: The runtime discoverable restrictions may also need to cover leafrefs.
  BL: But there are other restrictions that you can't describe. If I
      do not support 42 for uint8, then an attempt to configure 42 may
      simple fail with a runtime error.
  
  AB: We are at a situation where none of the solutions we have that
      would work do not look very appealing.
  MB: It seems import by revision does not help.
  MB: One option might be request via the guidelines that value set
      changes of typedefs or additions to groupings should not be done
      in the IETF.