=============================================================
NETCONF Data Modeling Language WG (netmod)
5th YANG 1.1 Virtual Interim
Wednesday, October 1st, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================

* Participants

  - AB = Andy Bierman
  - PH = Peter van Horne
  - JS = Juergen Schoenwaelder
  - LL = Lada Lhotka
  - DR = David Reid
  - KW = Kent Watsen
  - MJ = Mahesh Jethanandani
  - EV = Eric Voit
  - MB = Martin Bjorklund

status check of the action items

* Y23: support negative patterns as string restrictions
    
    MB: We will not do ignore-case since this is not supported by XSD
        based tools while the other modifier can be implemented
        outside the regex engine.
    MB: I will document this so we do not loose this bit of information.

    Issue moved to EDIT.
    
* Y25: make enum numbering purely informative and optional
    
    MB and LL explain their positions (essentially a recap of the
    mailing list discussion)

    AB: My implementation does not track enum number changes.
    AB: I believe we should not have had these statement (position,
        value) in the first place.
    AB: Why does the autonumbering on/off not work?
    MB: Then I have to implement emus/bits without a value/position anyway.
    MB: Why would your turn it off?
    AB: I doubt that anyone can move their code to a different
        implementation and hence this is not portable anyway.
    AB: You (MB and DR) want a permanent code point but this does need
        to happen at compile time.
    MB: But the code point is there today.
    LL: Explicit value/position statements are noise to a module where
        there are no natural values.
    LL: I believes autonumbering on/off is a reasonable compromise.
    
    RFC 6020 says: "The value is unused by YANG and the NETCONF
    messages, but is carried as a convenience to implementors." It
    also says in section 10: "An "enumeration" type may have new enums
    added, provided the old enums's values do not change."
    
    AB: From a modeling point of view, sometimes an enum has a natural
        numeric value but sometimes it simply does not have such a value.
    KW: I like the idea for autonumbering being optional but numbers
        are important if there are natural numbers assigned.
    
    Lets do a poll of opinions. The options are:
      (1) No change
      (2) Remove auto numbering
      (3) Add statement to make auto numbering optional (on/off)
    Name your choice starting from the most preferred option to the
    least preferred option.   
    
    MB: 1, 2, 3
    LL: 2, 3, 1
    AB: 3, 2, 1
    DR: 1, 3, 2
    KW: 2, 3, 1
    JS: 2, 3, 1
    
    JS: Is (2) more complicated on the upgrade path?
    LL: No because you take away only convenience to implementors.

    This needs to be taken to the list. (The result may mean that
    there is a majority for making a change here and out of the two
    options to make a change, it seems there is a majority to remove
    the auto numbering - which is after all a convenience to
    implementors.)

Y10: allow restrictions on enumerations
    
    MB: I prefer Y10-01 because it does not need new syntax.
    AB: I do not see the value of this, why not define a new type?
    MB: With subtyping, you can inherit semantics that are lost if you
        define a new separate type.
    LL: I suggested on the list include and exclude, which is different
        from Y10-02.
    DR: I have seen usage of this in SMIv2 but I have no strong
        opinion on this.
    LL: I prefer to leave things as they are.

    Poll of opinions. The options are:
      (1) No change
      (2) Do Y10-01.

    MB: 2
    JS: 2
    KW: 2
    LL: 1
    AB: 1
    
    AB: Does this interact with auto-numbering?
    MB: Current solution does work with auto-numbering, but it can be
        made to work if we remove auto-numbering.
    AB: For a large enumeration, Y10-01 is not user friendly. For small
        lists, create a new type.
    AB: I prefer a solution that allows to say I use all except this
        one (closer to LL's proposal on the list)
    
    MB: If you add an enum to a base type and you have excluded foo,
        then the addition carries through and this may or may not be
        what you want. Y10-01 at least makes it always clear what the
        set of values is.
    JS: I see your point but it may not make (conformance related)
        things worse than they are.
    MB: Y10-01 is better than the current situation and not more
        costly. If you define a separate type, you also have to list
        all enums plus you have to cut'n'paste the descriptions and
        the compiler will not be able to understand the relationship
        between the two types.
    
    Proposal: Move forward with Y10-01.
    
Y05: unprefixed path in top-level typedef
    
    AB: One issue is to resolve prefixes, another is relative nodes
        where the context node matters.
    MB: My action item on this is not complete. Need to work on this
        and we should return to this issue later.

Y12: initialized-by system
    
    JS: Is this issue resolved such that it can move into the EDIT
        state?
    JS: What is the alternate syntax referred to?
    JS: In the minutes, I see system-initialized true|false.
    MB: I agree to move this to the EDIT state. The syntax can be
        debated while being in the REVIEW state.