Minutes for NETMOD at interim-2014-netmod-19
minutes-interim-2014-netmod-19-1

=============================================================
NETCONF Data Modeling Language WG (netmod)
10th YANG 1.1 Virtual Interim
Wednesday, December 17, 2014, 16:00-18:00 CET
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  JS = Juergen Schoenwaelder
  LL = Lada Lhotka
  MB = Martin Bjorklund
  AB = Andy Bierman
  DR = David Reid
  JT = Jason Sterne
  BC = Benoit Clais
  BL = Balazs Lengyel
  KW = Kent Watsen
  DR = Dan Romascanu

* Status Check

 - Y09 introduce optional keys
   Need to validate adoption of Y09-03 on the mailing list.

 - Y16 module advertisement optimization
   Need to validate adoption of Y16-03 on the mailing list.

 - Y18 fix "when" expression context problem
   Pending action MB => action to be completed

 - Y59 restrict use of 64-bit numbers in XPath expressions
   Moved to open, perhaps discuss resolution?

 - Y25 make enum numbering purely informative and optional
   JS to start a thread on the mailing list. There once was rough
   consensus for Y25-01 - we need to check what happens on the list.

 - Y26 allow mandatory nodes in augment
   Pending action LL => action done

 - Y58 associate an actions with a data node
   Pending action JS (check with NETCONF chairs concerning NACM update).

 - Y34 remove/deprecate/replace the 'anyxml' statement
   Need to verify Y34-04 on the mailing list and that it can handle
   all existing meaningful uses of anyxml.

 - Y49 clarify nested submodule behavior
   Need to validate adoption of Y49-04 on the mailing list.

 - Y57 non-unique leaf-list
   There was an action item for BL on 2014-10-15 => action to be completed

 - Y45 better conformance mechanism
   How to resolve this? Do we need to collect the requirements a
   solution must satisfy? It sometimes feels like going in circles on
   this.
  
* Y45 better conformance mechanism

  JS: We seem to go in circles, can we collect use cases to verify
      solution proposals against?
  MB: Yes, we seem to go in circles.
  AB: Using import-by-revision everywhere is one solution, but it has a cost.
  AB: I wanted to move conformance out of the YANG module, conformance
      is specified separate from the objects.
  BL: Simplifying assumptions may be needed (only one version per module)
  AB: Do we agree on one module per server?
  MB: Only one module where you implement data nodes.
  KW: Import by revision resolves which version of a type has been used.
  MB: This may lead to massive updates if a type module changes.
  JS: Lets distinguish between (a) a modular server implementing multiple
      versions within a module and (b) different modules importing from
      different versions of some other module.
  MB: Import by revision does not solve the problem.
  MB: The problem is two augmenting modules importing the augmented
      module at different revision numbers.
  KW: RFC6020 says must statement can be relaxed, it is silent about
      when statements, perhaps an errata?
  AB: Phil said that if B augments A, then a server needs to implement A
  KW: If you have a module A that imports only groupings from B, then the
      server does not need to claim implementing B
  BL: We use a lot of imports without import-by-revision.
  MB: This may be a maintenance issue.
  AB: There is already some confusion about what needs to be announced.
  KW: You can add a must statement to a new node, but you can't add a
      stricter statement to an existing node.  
  BL: But you can break the rules by side effects.
  BL: I like to know which version of a typedef module is actually
      being used.
  MB: The requirement is that the client can understand which version
      of a typedef module is actually used by a module.
  AB: Perhaps keep it simple - if you change a grouping, you have to
      give it a new name.
  KW: Lets collect statements (axioms) we agree on (or not).

  
  A0. Claiming conformance means that the server implements all
      protocol-accessible nodes, rpcs, notifications (modulo supported
      features).  It does not include aspects that are not directly
      accessible, including typedefs, identities, and groupings.
  A1. A server can only claim conformance (i.e., implement the
      data-nodes, rpcs, notifications) to one revision of a specific
      module at a time.
  A2. A server does not need to claim conformance to a module that was
      only imported by other modules for purposes other than augment.
  A3. A server must claim conformance to a module if it is imported by
      another module for the purpose of an augment statement by
      another module the server claims conformance to.
  A4. The version of all imported items including typedefs, groupings,
      etc. must be visible to the client.

  BL: We need to maintain backwards compatibility since management
      systems are very hard to update.
  LL: But backwards compatibility rules hard coded in the language
      limit flexibility where needed.
  AB: I agree with BL, we need to be most concerned about software updates.
  AB: The cost of being wrong can be high, so try to check the modules
      well before publishing them.
  KW: I believe vendors will implement functionally overlapping modules.
  MB: What is in that case the response to a get-config?
  KW: Without a namespace, you get the default module set, otherwise
      the namespace defines what is returned to a client.
  KW: The developers of submodules may use imports at different revision
      levels.
  BL: This may be fine for the developers, but how does an operator deal
      with this?
  KW: I assume the operator's code is data model driven. The
      import-by-revision will tell them which imported definition was used.
  AB: In a module, you can't import a module multiple times. But this
      happens with submodules if they import at different revisions.
  BL: I do not like to allow importing different revisions of A in
      different submodules.
	
  MB: But it depends on the solution. We need to work out the use cases
      and evaluate the solution against use cases.
  BL: RFC 6020 says multiple revisions imported in a module is not
      supported. It is not clear whether this applies to modules and/or
      submodules.
	
  AB: You can only have conformance to things that are protocol
      accessible.	
  LL: A server advertises the identities it implements by advertising
      the module where the identity is defined.
  JS: I do not think this is valid for say iana-interface-types.
  AB: The set of identity values that can be used is a runtime issue.
  KW: Is this not similar to groupings?
  MB: No, because the value is used (or not) at runtime.
  MB: Use an RPC to discover possible values at runtime.
  LL: The problem is the IANA interface type list, the identities should
      be defined in type specific modules.
  BL: Even with specialized modules, we will see the problem again. At
      the end, every identity ends up in a separate module.
  AB: Line cards often have specific constraints and we need to be
      able to deal with this.
  BL: There are also license restrictions that apply.
  AB: The problem is when import-by-revision is mixed with import
      without revision.
  KW: We need to distinguish the different types of imports (import
      for just groupings/typdefs/etc vs import for augment).

  Actions:

  - MB volunteers to kick of the process of collecting use-cases and
    solutions.