Minutes for NETMOD at interim-2014-netmod-13
||Minutes for NETMOD at interim-2014-netmod-13
NETCONF Data Modeling Language WG (netmod)
5th YANG 1.1 Virtual Interim
Wednesday, October 1st, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
- 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
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
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.
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
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.