Minutes for NETMOD at interim-2014-netmod-6
||Minutes for NETMOD at interim-2014-netmod-6
NETCONF Data Modeling Language WG (netmod)
3rd YANG 1.1 Virtual Interim
Wednesday, July 9th, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
- JS = Juergen Schoenwaelder
- AZ = Alex Zhdankin
- AB = Andy Bierman
- LL = Lada Lotka
- PO = Peyman Owladi
- PH = Peter van Horne
- AN = Anonymous
- TN = Tom Nadeau
* 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
PO: You are not allowed to use it in cases that break backwards
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
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
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
* 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
AB: This might make differences if you make multiple updates in an
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