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

=============================================================
NETCONF Data Modeling Language WG (netmod)
2nd YANG 1.1 Virtual Interim
Wednesday, June 11th, 2014, 16:00-16:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - AB = Andy Bierman
  - KW = Kent Watsen
  - MB = Martin Bjorklund
  - PO = Peyman Owladi
  - DR = David Reid
  - AZ = Alex Zhankin
  - LL = Lada Lotka
  - PH = Peter van Horne
  - GH = Giles Heron

* Summary

  After a short review of the outcome of the last virtual interim
  meeting, the group started going through the open issues in order to
  discussion solutions. Strawman proposals for solutions were
  identified for Y01-Y06. Since MB will be unavailable the next two
  weeks, it was decided to skip the next two virtual interim meetings
  and to continue on July 2nd.

  It was agreed that JS will track the state changes of the issues in
  the issues list.  MB will start work on a first I-D for YANG 1.1. It
  will contain a section with a high-level summary of the changes since
  RFC 6020 that will be part of the final RFC plus an additional
  section in the appendix cross referencing the issues list. This
  section is intended to make reviews of changes easier and will be
  removed from the final RFC.

* Y55 clarify type in union

  MB added this issue as discussed in the last virtual interim
  meeting.

  Proposal: Open this issue. JS to confirm this on the mailing list.

* additional clarification issue on the mailing list

  AB: Did recently send an additional clarification issues to the
      list. 
  MB: I believe this falls into an existing issue (Y41)
  AB: Why is the server making decisions whether or not to return nodes?
  MB: I am not sure I understand the question. It always depends on the
      semantics of the particular leaf.
  AB: A mandatory false node will not be returned if and only if it
      does not exist (ignoring filters and access control for a
      moment).
  MB: Depends on the semantics of the leaf.
  PO: Non-existence can have specific meaning.
  KW: Mandatory true would mean that a leaf always exist.
  MB: Is this something to be clarified?
  AB: I will take a look at the text to see whether something needs
      changing.

* Y01: allow boolean if-feature

  AB: I am fine with accepting Y01-01, the specification should get 
      the operator precedence right.
  AB: There might be an issue with a feature called 'and'.
  JS: This clash should only be an issue for
         if-feature and; 
      or
         if-feature or;
      and these can be handled as special cases.
  MB: Will add text to make sure that theoretical clashes with 
      features like 'and' and 'or' are well defined.

  Proposal: Adopt Y01-01, MB to work out the edits.

* Y02: allow must in input, output, and notification

  AB: Why do we need these top-level must expressions? When are
      they evaluated? I am fine with Y02-01, not sure about Y02-02.
  PO: I believe mandatory is essentially like a must in a top-level.
  AB: YANG does not allow top-level mandatories. The reason is that
      in practice not all servers may have mandatories all the time,
      e.g. when a module is loaded.
  MB: If you load a module, you need to provide a factory default 
      because otherwise the module would be invalid.
  PO: Here is an example: There must not be more than 100 VLANs on
      this port. This must applies for a top-level list. The logical
      place for the must statement is at the top-level.
  MB: We have the same issue with an empty container.
  AB: What is the context node for the must? The root?
  AB: Should we also consider rpcs? Or does this only apply to data
      nodes?
  MB: It seems Y02-02 does not work because of unclear context, so we
      better go with Y02-01.

  Proposal: Adopt Y02-01. AB and MB support this. MB to work out the
  edits.

* Y03 allow if-feature in refine

  LL: What does it mean? Assume feature in A, grouping in B. 
      C imports B.
  MB: The grouping does not use the feature.
  LL: Yes, I got confused.
  AB: Are there any problems if a refine rewrites an if-feature,
      e.g., adding or removing something from the expression?
  MB: But grouping expansion happens in the usual way, you could always
      cut and paste the grouping and add the if-feature as you like.
  LL: I think this is OK.
  KW: Can this break existing clients?
  LL: No, a server would have to advertise a new module.
  KW: I am not sure whether there could be an issue.

  Proposal: Go along with Y03-01. KW to double check that there is no
  issue with dependencies and versioning.

* Y04 accessible tree in xpath in notifs and rpc

  JS: Where has this become a problem?
  MB: Look at the example.
  LL: Is this similar to something in the SMI?
  AB: This does never happen in SMI.
  MB: The current situation is somewhat wired.
  PO: If you define a type in a top-level module, you can't use that
      type inside of a notification?
  MB: Yes, this is kind of true. It depends on the path and whether
      you have the same structure in a notification.
  PO: Are we sure this is a corner case? Reusing a type in a 
      notification may happen more frequently.
  MB: If we make this change (Y04-01), then existing notifications
      may be illegal.
  AB: We need to rule out solutions that make YANG 1.0 modules
      illegal.
  MB: This is really a bug in the YANG 1.0 specification and we better
      fix it.
  AB: I am in favor of Y04-04.
  MB: But how do we make the bref path legal in YANG 1.0?
  AB: When is this path expression actually evaluated? When the
      event occurs, when the notification is being prepared?
  PO: This seems to tighten the restrictions but conflicts with
      backward compatibility.
  AB: Why do we need to be able to reference things in the
      notification?
  AB: If the notification is returning copies of stuff in the data
      tree, everything should be fine. I am concerned about breaking
      things by changing the meaning of the path statement.
  AB: I believe this is a really corner case and any solution must
      keep existing notifications valid. It may require a new keyword
      to introduce different semantics.
  MB: What is the initial context node of a path statement in a
      notification?
  MB: LL, is the example in Y04 is valid?
  LL: It could be valid - current() means the bref in the
      notification.
  PO: Solution Y04-02 is _not_ problematic since top-level names can't
      clash according to RFC 6020 section 6.2.1.

  Proposal: Go along with Y04-02 now that we have realized that it
  actually works.

* Y05 unprefixed path in top-level typedef

  AB: I am fine with the first solution.
  PO: The binding should be done where the typedef is evaluated.
  JS: I agree with PO.
  MB: This would be solution Y05-03.

  Proposal: MB to write down solution Y05-03 and once done we get back
  to this issue.

* Y06 escaped characters in double quoted strings

  LL: A third solution is that \x means x.
  MB: Randy Presuhn likes Y06-02.
  LL: There may be backwards compatibility issue.
  PO: We pay attention to existing implementations or, if something is
      undefined, we are free to choose any interpretation.
  JS: What does "all known implementations" mean?
  MB: At least YumaPro and Tail-f.
  JS: This is a much more narrow statement.
  MB: Guidelines should say better use single quotes for pattern.
  PO: Could others have copied RFC 6536 style?
  MB: The only hard backwards compatible solution is to leave this
      undefined forever.
  LL: I am in favor for Y06-02.
  KW: I think this is the best option.
  MB: I am in favor of Y06-02.
  JS: I am in favor of Y06-02 as well.
  AB: I am fine with this, it seems a regression bug fix.

  Proposal: Move forward with Y06-02.