=============================================================
NETCONF Data Modeling Language WG (netmod)
20th YANG 1.1 Virtual Interim
Monday, September 7th, 2015, 17:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  AB = Andy Bierman
  G? = Gert ?
  IB = Ignas Bagdonas
  JS = Juergen Schoenwaelder
  LL = Ladislav Lhotka
  MB = Martin Bjorklund

* Data tree definition update (Martin, Lada)

  See Lada's email concerning the different uses of data tree.
  
  MB: I have done already most of the edits, but not yet checked in.
  AB: The new definition combines multiple different trees into one.
  LL: The wording may not be good enough, we should make it clear that
      a "," really means "or".

* Extension statements and deviate-stmt / refine-stmt (Andy)

  It seems groupings do not really anticipate extensions from an ABNF
  point of view.
	
  MB: I think the grammar is not the problem. But there is clearly
      text missing and also not all statements can be refined (you
      can't refine the type of a leaf for example).
  AB: Properties like config true/false are often introduced when a
      grouping is used instead of having this hardwired in groupings.
  AB: Groupings are somewhat fragile, you can't easily move them
      around, there are likely guidelines missing for groupings.
  MB: I propose to add text that extension statements can be added
      using a refine but the extension statement must define the rules.
  MB: If you define an ephemeral statement, then the definition of the
      statement must provide the details how it can be used.
  LL: Shall we have restrictions on what an extension can do and what
      it cannot do?
  AB: There is the understanding of the annotation statement and then
      there is the understanding of a specific defined annotation.
  MB: It is difficult to define rules that make sure
      extensions/annotations are backwards compatible.
  AB: The usage must be client initiated and how you do that depends on
      the specific circumstances.
  MB: There is already text in the language extension section:
	
	Care must be taken when defining extensions so that modules that use
	the extensions are meaningful also for applications that do not
	support the extensions.
	
  AB: I will work on good and bad extension examples and incorporate the
      text in the guidelines update.
  MB: I can help with that.
  LL: I will check that there is similar text in the metadata document.
  MB: I will add text concerning the refinements.

* Data tree ordering (Lada)

  LL: Is the data tree fundamentally unordered?
  MB: Yes, the ordering is in the encoding parts.
  
  Action: LL to check whether his comments have been resolved in the
          svn version.
	
* Title of the document (Martin)

  MB: Shall we remove "for the Network Configuration Protocol
      (NETCONF)" from the title?
  AB: I am concerned about people that want to use YANG for protocols
      they do not talk about and they may even want to change YANG.
  MB: The idea is to shorten the title and to leave it for the
      introduction to explain what YANG was designed for.
  JS: I am fine with a short title as long as there is clear text
      about the purpose of YANG and its applicability in the text.

* Coexistence issue - allow version 1 modules to import version 1.1 modules? (Martin)

  MB: It should be fine for a version 1.1 module to import from an
      version 1 module.
  MB: What about allowing version 1 modules to import from 1.1 modules?
  JS: What happens if a version 1 module augments an action defined in
      a version 1.1 module?
  MB: But how do we update inet-types.yang to 1.1?
  JS: Version 1 modules can keep using version 1 inet-types.yang until
      they want to use something present only in a newer revision.
  LL: But what about import without revision?
  LL: Submit an errata that a version 1 module can only import version 1 modules.
  MB: How would this be advertised in the yang library?
  MB: A (in 1) imports yang-types, B (in 1.1) imports yang-types,
      yang-types exists in version 1 and 1.1 - which version will be
      advertised?
  AB: It will have to be the latest.
  AB: I suggested that a version 1 module is parsed as a 1.1 module in
      a mixed implementation and then you are fine to import a 1.1 module.
  LL: I am fine with an automatic promotion.
  MB: What about relaxing the rules only for modules that predate YANG 1.1?
  AB: The server is going to have only one version, especially for configuration.
  
  Action: MB will start a thread on the mailing list and if needed we
          continue this discussion next Monday.