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

=============================================================
NETCONF Data Modeling Language WG (netmod)
3rd YANG 1.1 Virtual Interim
Wednesday, July 2nd, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - LL = Ladislav Lhotka
  - MB = Martin Bjorklund
  - BC = Benoit Claise
  - PO = Peyman Owladi
  - PH = Peter van Horne

* Summary

  During the meeting, the issues Y07, Y09, Y10, Y11, Y12, Y13, Y14,
  Y16, and Y18 were discussed. For each issue, either a strawman
  proposal has been found or concrete action items have been
  assigned. We will continue with two more virtual interim meetings
  before the face-to-face meeting in Toronto.

* Y07: do not allow when or if-feature on keys

  AB: Says the solution is wrong, if-feature / when should not be more
      specific than the parent.
  AB: Is there not text somewhere else in RFC 6020?
  PO: The leafs condition should at least be as restrictive as the
      parent context.
  PO: A statement that says something about the parent is irritating.
  AB: What if I put if-feature bar on the parent?
  MB: That is OK.
  LL: What must be avoided are lists where keys are (partially) undefined.
  MB: Make them illegal if the condition is different from the parent.

  Proposal: Adopt Y07-01 with a clarification about the condition.

* Y09: introduce optional keys

  Action: MB will write up a solution proposal.

* Y10: allow restrictions on enumerations

  MB: I think we should do what SMIv2 allows.
  AB: What prevents the second typedef from redefining enum a?
  MB: Redefining the value would not be legal.
  LL: What about having a different statement to define the set of allowed
      enums to prevent overwrite issues?
  MB: Not sure this helps since you can do pretty much all of this with
      strings and pattern, see the first example.
  AB: What happens if foo has a default b?
  MB: That would be illegal.
  LL: I prefer a different syntax.

  Action: LL to write down another syntax proposal and MB to expand
  Y10-01.

  PO: What about restrictions on unions?
  MB: Currently not allowed, should they be allowed?
  JS: Unclear whether common programming languages allow something like this.
  MB: An implementation issue.
  JS: But people might simply not expect this to be available.
  MB: Lets discuss this later, this is a separate issue.

* Y11: allow if-feature on enums

  MB: This avoid having choices with an empty container.
  AB: This is somewhat different since this usage of if-feature
      is not related to data tree nodes directly but instead applies
      to the value space of types.
  PO: If you have if-feature for enumerations, would you also want to
      have them for identities?
  MB: Likely yes. 
  AB: I like this since it allows an NMS to restrict values shown to
      a user based on the announced features.

  Proposal: Adopt Y11-01 with the extension to allow if-feature also
  for bits and identities.

* Y12: initialized-by system

  JS: Does initialized-by system mean may be initialized-by system?
      And initialized-by user means must be initialized-by user?
  MB: No, it is more boolean.
  MB: This is not a default, the server generates a suitable value.
  PO: What about ports that change the MTU when sub-interfaces are
      configured?
  MB: YANG does not support dynamic defaults in that way.
  AB: What about processing an edit-config with multiple list
      entries, some with explicit values, some without?
  MB: The server would have to figure this out.
  JS: The server can be smart to figure out suitable values for a
      given commit or be dumb and return an error (similar to an
      edit-config with conflicting uids).
  LL: Should probably have a different syntax, initialized-by user
      is misleading, perhaps system-initialized true|false. It is
      really system-initialized-if-missing.
  LL: Only valid for leaf?
  MB: I think also leaf-list, for consistency.
  PO: May be a bit related to mandatory, default is likely illegal
      with initialized-by system, need to write more complete text.

  Proposal: Adopt Y12-01 but think about a better syntax. Applies to
  leaf and leaf-lists. MB to create concrete text.

* Y13: allow multiple inheritance for identities

  AB: I am not see the example - the example only defines two
      regular identities.
  LL: Not sure I wrote the example.
  AB: What do I get by having multiple bases to an identity?
  PO: Interfaces are good examples.
  LL: It is good to use identityref with multiple bases.
  JS: How do you maintain the identity derivation graph if things are
      added over time?
  LL: This is only useful if we have suitable xpath functions.
  JS: Can someone write a complete example that shows how this solves
      interface type issues?

  Action: LL to write a more complete example.

* Y14: clarify the string value for identities when used in must/when

  MB: I think Y14-01 is already used in the routing model.
  LL: Need for this drops once we have xpath functions.
  MB: We still need to define this.

  Proposal: Adopt Y14-01.

* Y16: module advertisement optimization

  AB: Not sure this is a YANG issue alone.
  MB: YANG module advertisement is defined in RFC 6020.
  AB: This does not work because there is no version number. If the
      client could say here is what I have cached, then this could be
      made to work.
  MB: If we only suppress YANG 1.1 modules?
  JS: Is the info in RFC 6022 (Y16-02) complete?
  MB: Not sure, we implement /netconf-state/capabilities as what was
      in the hello.
  PO: I am leaning towards Y16-02.
  MB: RFC 6022 talks about NETCONF capabilities. Does it also contain the
      data models?
  AB: Right now, the hello contains all modules. But this should actually
      be subject to access control.
  AB: I am in favor of Y16-02 since it allows to hide loaded modules.
  JS: How does this work in RESTCONF?
  
  Action: MB to look at the details whether Y16-02 can be made to work.

* Y18: fix "when" expression context node problem

  LL: I do not like the solution proposal. The result may depends on the
      order.
  LL: My proposal would be to treat when equivalent to must.
  MB: But this is backwards incompatible.
  MB: I do not understand the problem you see.
  LL: You need to at least specify what happens if there are circular
      dependencies.
  MB: Seems like a theoretical corner case.
  PO: Perhaps even leaving this implementation specific?
  AB: There are other when issues, e.g. the order in which expressions
      are evaluated and it gets work if when expressions interact.
  MB: How likely is this going to be a problem?

  Action: LL to write up an example in which situations Y18-01 is
  problematic.