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

=============================================================
NETCONF Data Modeling Language WG (netmod)
1st YANG 1.1 Virtual Interim
Wednesday, June 4th, 2014, 16:00-16:00 CEST
Minutes Benoit Claise, Juergen Schoenwaelder
=============================================================

* Participants

  - JS = Juergen Schoenwaelder
  - BC = Benoit Claise
  - AZ = Alex Zhankin
  - AB = Andy Bierman
  - BZ = Bernd Zeuner
  - DR = Dan Romascanu
  - JT = Jason Sterne
  - KW = Kent Watsen
  - LL = Lada Lotka
  - MB = Martin Bjorklund
  - PH = Peter van Horne
  - XL = Xufeng Liu
  - AN = anonymous

* Summary

  The goal of the 1st virtual interim meeting was to decide on the
  submitted issues marked NEW and without a strawman position (or a
  strawman position that led to discussions) whether they are in scope
  (OPEN) of the YANG 1.1 effort or out of scope (REJECT).

* Y31 allow require-instance in leafref

  Proposal: Keep Y31 open as already being discussed on the mailing
  list. LL, MB, AB, AZ in favor of moving this to open.

* Y09 introduce optional keys

  LL thinks a key not present simply does not contribute to the
  uniqueness requirement.

  AB against it since it breaks restconf. Why is this really needed?
  
  LL has no problem with opening the issue and seeing whether a
  solution can be found.
  
  AB how does this map to things like SQL? What are the interactions
  with optional keys?

  AZ we should perhaps abstract from implementation details.

  MB volunteers to come up with a concrete proposal and then we can
  decide whether the complexity is under control.

  KW does not see a simple mapping to SQL. I tend to agree with AB
  that this is perhaps complex. Why would you not use artificial keys?

  MB says that in some cases the data model would be more natural.

  AB says if a leaf is optional, then it is really not part of the key
  and you might be picking the wrong thing as a key.

  AB asks what happens if there are multiple optional keys? Can they
  all be optional?

  BC asks whether AB is afraid of the combination of multiple optional
  keys?

  AB responds that the key is crucial for naming.

  Proposal: Move this to open for now. Some concerns from KW and
  AB. We might revisit this issue later if the complexity/cost of a
  solution is too high. Action item for MB to provide a detailed
  solution proposal.

* Y19 we need a better unique

  LL says that nested lists can already be included in XPATH, at least
  the DSDL mapping handles this.

  MB says we need to make sure that the current unique works
  correctly with the DSDL and clarify RFC 6020.

  MB is fine with the interpretation of the DSDL draft. But MB also
  says that we need to check whether the DSDL mapping solution
  achieves the same as the issue writeup.

  AB is concerned that this adds complexity.

  LL got concerned that if semantics deviate from what the DSDL
  mapping currently does, then he is against accepting this.

  AB remarks that maybe it is easier to tell people how to use must
  statements to achieve similar results.

  AB is concerned that we end up with two unique statments and then we
  need to tell everybody what the difference is and when to use which;
  not convinced that this better unique is needed.

  PH this sounds more like an optimization.

  PO says it does not break backwards compatibility.

  Proposal: Reject this request for a new feature but clarify the
  semantics of unique in RFC 6020bis (might require to open a separate
  clarification issue). A new and more powerful unique seems more like
  a YANG 2.0 work item than a YANG 1.1 work item. The consensus on
  this was rough (MB prefers to have this issue opened).

* Y21 statement to define new XPath functions in a module

  MB we apparently need a few more XPATH functions. The question is
  whether these XPATH functions are hard wired in the language
  (requiring a language update for each addition).

  LL says that implementations simply can't ignore the XPATH functions
  and hence it does not satisfy the requirement of the extension
  statement.

  AB is concerned about interoperability problems.

  AZ thinks it is a bad idea to define XPATH function in YANG itself.
  
  MB says that in the IETF, we would need to bump the YANG version
  number when we add new XPATH functions.
  
  PO says the alternative today is to implement an extension to
  support the same function (which would be ignored by existing
  implementations).

  Proposal: Reject this request for a YANG statement to declare new
  XPATH functions.

* Y22 support constraints on unions

  AB says it is not clear which problem is being solved. Why does it
  need to get exposed which type statement of the union got selected?
  
  PO how is it well defined what the value set is?
  
  AB says that if a value matches any of the types in the union, the
  value is valid. The value set hence is really the union of the types
  involved.

  PO says in XML and JSON, you can have the type identified. What YANG
  does is sufficient for validation.

  LL agrees that this should be rejected.

  MB agrees to reject as well.

  PO suggests to clarify that this is primarily for validation and not
  necessarily for type identification.

  LL says there is text that types are tried sequentially.

  Proposal: Reject the issue and add a new issue that a clarification
  is needed about the nature of unions and that they primarily are
  needed for validation.

* Y26 allow mandatory nodes in augment
  
  MB believes the current rules are too strict but removing the rule
  would allow things to break easily.

  LL says the overarching principle is that published modules are not
  allowed to become invalid by augments.

  AB sees a problem if an old client implements old module A and later
  a new module augmenting module A comes along causing things to stop
  working for the old client.

  AB says there are ways this can be done if a module has been
  designed for such mandatory augmentations.

  MB says that in certain cases such a mandatory augmentation is fine;
  the problem is defining and writing down the rules.

  PO asks whether it is possible to create rules like augmentations
  with mandatory is allowed if the augmentation is guarded by a when
  statement?

  MB says it is difficult to write up such rules. Suggests to open
  this and reject it later if we can't come up with good rules.

  AB says unless we have service level conformance, the mandatory
  property is scoped to a module.

  PO asks whether we can just restrict it to what has come up in the
  interfaces data model?

  AB is concerned that it will not be a single case. It is important
  that we protect old clients. It will, however, be difficult for a
  YANG compiler to validate this.

  AZ supports this to be open since we have an actual use case.

  JS asks whether it is possible to relax the current rule with lots
  of explanatory text, assuming that implementations will generate
  warnings based on the current restrictive rule but humans may choose
  to ignore them if they checked that indeed old implementations do
  not break.

  Proposal: Open this issue even though a possible solution remains
  rather unclear.

* Y27 allow mandatory nodes in an updated module

  MB says the intention of the text was to protect old clients.
  However, different from Y26, the revision number changes here.
  MB suggests this to be opened.
  
  AB and LL agree to open this.
  
  Proposal: Open this issue.

* Y33 add 'attribute' statement

  LL says if there are only a really small set of attributes that we
  need, then he is fine with rejecting it.

  AB is OK with a reject since it is likely only a small number of
  attributes that we need.

  AB believes such an attribute statement will likely cause people to
  misuse it.

  Proposal: Reject this issue.

* Y36 associate a notification with a data node

  MB says that he did not have customers asking for this but Tail-f
  has something similar called actions (inlined rpcs). If we do this,
  it makes sense to add inline RPCs as well.

  AZ sees a use case.

  PO sees value in notification source properties attached to leafs.

  PO says that this is essentially about associating a notification
  with a resource object.

  MB says this is a nice to have feature because you can do
  without. Sounds more like a YANG 2.0 issue.

  AB agrees that this is an optimization, perhaps this can also be
  dealt with by certain design patterns.

  JS suggests that one could also think about guidelines on how to
  structure notifications to make resource identification easier.

  Proposal: Reject this issue. May be considered for YANG 2.0.

* Y37 allow notifications to be derived from other notifications

  MB says this is an optimization, nice to have, but not critical.
   
  AB says this is convenient and simple to implement.
   
  JS says that for other things we expect designers to explicitly
  design reusable things, we do not allow uses on an arbitrary
  container.

  Proposal: Reject this issue. Reject supported by LL, AB, and MB.

* Y39 define the terms system/user-controlled instances

  PO asks how exactly is this envisioned to be used?

  MB is concerned that it does not belong in the YANG language
  definition since this seems to be more architectural.

  LL agrees with MB, perhaps this can go into the architecture
  document? Or in a design pattern document.

  PO asks whether there are any consequences of not putting this into
  the YANG 1.1 specification?

  LL answers no, the question is more whether we define this in a
  single place instead of multiple places. Right now, this is defined
  in those data model documents that require this distinction.

  Proposal: Reject since this is an architectural distinction and
  should thus should be defined generically elsewhere. It does not
  seem to be a YANG 1.1 issue.

* Y50 additional extension grammar validation

  MB says this is a nice to heave feature for tool writers, users of
  tools likely do not care.

  PO says that this makes extensions more readable and well
  defined. But yes, this is a nice to have feature.

  MB says that Tail-f has an extension for this but it is a nice to
  have feature and not essential

  AB is concerned that this asks compilers to interpret ABNF at
  runtime.

  PO says that their implementation is not more constrained / precise
  than the existing YANG grammar.

  JS says if this can be done as an extension, why make it part of
  YANG 1.1? Simply write an extension YANG module.

  Proposal: Reject the issue since it can be done as an extension and
  does not need to be part of YANG 1.1.

* Y54 remove the advertisement of conformance information in NETCONF hello message

  MB says all conformance issues need to be discussed together and
  hence we should keep this open as well.

  LL suggests to write a new issue that consolidates all conformance
  related issues.
  
  AB says the way this is written it is not workable.
  
  JS suggests to move Y54 as a solution of Y16.

  JS does not like adding new issues, he prefers to cluster
  conformance related issues.

  Proposal: Open this issue as it is related to the other conformance
  related issues.