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

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

* Participants

  - JS = Juergen Schoenwaelder
  - AZ = Alex Zhdankin
  - AB = Andy Bierman
  - LL = Lada Lotka
  - PO = Peyman Owladi
  - PH = Peter van Horne
  - AN = Anonymous
  - TN = Tom Nadeau

* Summary

* Y20: new set of built-in XPath functions

  Proposal: MB to copy the functions he proposed to RFC 6020bis as a
  starting point and then we review and discuss changes.

* Y23: support negative patterns as string restrictions

  AB prefers solution #2, LL and PO as well. 

  Proposal: Adopt Y23-02.

* Y25: make enum numbering purely informative and optional

  LL and JS prefer Y25-01, AB likes it as well since the number is
  nowhere used in NETCONF.

  Proposal: Adopt Y25-01.

* Y26: allow mandatory nodes in augment

  AB: It is too restrictive the way it is, allowing all mandatory nodes
      is too much.
  PO: We then need to enumerate the cases where mandatory nodes would be
      OK.
  PO: You are not allowed to use it in cases that break backwards 
      compatibility?
  AN: That is what we want, but hard to implement. I think we need to
      start enumerating cases where it is OK and cases where not.
  AN: Augmentation may include mandatory nodes but it can't make
      something in a pre-existing container have additional mandatory
      nodes.
  LL: There can be containers designed to be augmented, e.g. for
      different address families.
  AN: Sounds like an abstract class concept where you can only
      instantiate concrete classes.
  LL: Yes. We have this with an 'abstract' routing entry.
  AB: But you break an old implementation, no?
  LL: We have this in the routing data model. If we could express that
      this needs an address specific module to work, we could handle
      this properly.
  JS: But this is on the container level, if we were to tag containers
      as incomplete, we would have machine readable information to take
      a decision whether an augment with mandatory nodes is allowed.
  AN: I think LL is really talking about a new issue.
  AB: ODL has designs with empty containers that are filled from the
      outside and these trigger wrong warnings.

  Conclusion: There is agreement that the current text is overly
  restrictive. The proposal is to add general guiding rules that
  backwards compatibility needs to be maintained. Lets see whether
  someone can write more concrete rules when mandatory nodes in
  augment are allowed.

* Y27: allow mandatory nodes in an updated module

  PO: How does this relate to Y26?
  AB: In Y26 the version number does not change.
  LL: But the server now announces a new module.
  AB: Clients do not have to check whether any other modules augment
      mandatory nodes into a given module.
  AB: In Y26, the client does not any indication that the module changed.
  TN: We are mounting devices into some parts of the tree. And some devices
      may have different versions of modules.
  PH: We also use modules in various projects.

  TN: Allow with specific rules and caveats.
  PH: This is a case where and old client accessing a new revision will
      find his request invalid.

  PH: Deprecate and obsolete allows a reasonable deprecation path.
  PH: With this proposal, you break old clients immediately.
  JS: This is not how RFC 6020 section 10 first paragraph says it works.

  JS: It seems Y27-01 breaks the second sentence of section 10 of RFC 6020.
  PO: Should we instead discuss that obsolete should have additional text
      that this should not be mis-used to break compatibility?

  Some discussion about versioning not fully captured.

  PO: Should we have guidelines how to go from current to deprecated to
      obsolete in RFC 6087bis?

  Conclusion: The strawman proposal is to reject this issue, AB to
  check what the feature issue is about, possible action to add
  guidelines how to go from current to deprecated to obsolete in RFC
  6087bis.

* Y28 support default values in leaf-lists

  AB: I prefer Y28-01.
  JS: But this has problems since we would have to introduce a syntax
      that works for all possible values.
  PO: It seems Y28-02 works out of the box.
  LL: I think we should go with Y28-02.
  PO: This is slightly different from other defaults for implementations
      threat treat internally each leaf-list value as a separate object.
  AB: You can add to a set of values of a leaf-list using a NETCONF
      merge and hence leaf-lists are rather different and we can't
      simply extend default in this way.

  AB: We should do this somehow but it requires some work since
      leaf-lists are really different from leafs here.
  AB: Right now all we do is putting text into description statements.
  PO: If someone comes along and explicitly configures 830, then the
      value is not a default anymore.

  Conclusion: AB will look at the necessary text what it means to
  modify leaf-list values. Perhaps there is a need to have a different
  keyword since the behavior is rather different here.

* Y29 allow choice as a short-hand case

  Strawman is to adopt the proposed solution.

* Y30 allow leafref in union

  LL: Does this require that the instance referred to exists?
  AB: You check whether it exists, if not, you go on to the next
      option in the union.
  PO: The existence of a certain leaf determines to which type a union
      value resolves. This makes it different from other types in a
      union.
  AB: This might make differences if you make multiple updates in an
      edit-config.
  PO: But this is the same for other types in a union.

  Clearly Y30 and Y31 are interrelated. We did run out of time and we
  will continue in Toronto. We will skip next week's meeting since LL
  is also on vacation and IETF preparations also need to be made by
  several people.