Minutes for NETMOD at interim-2014-netmod-5
minutes-interim-2014-netmod-5-1
| Meeting Minutes | Network Modeling (netmod) WG | |
|---|---|---|
| Title | Minutes for NETMOD at interim-2014-netmod-5 | |
| State | Active | |
| Other versions | plain text | |
| Last updated | 2015-02-26 |
minutes-interim-2014-netmod-5-1
=============================================================
NETCONF Data Modeling Language WG (netmod)
3rd YANG 1.1 Virtual Interim
Wednesday, July 2nd, 2014, 16:00-18:00 CEST
Minutes Juergen Schoenwaelder
=============================================================
* Participants
- JS = Juergen Schoenwaelder
- AB = Andy Bierman
- LL = Ladislav Lhotka
- MB = Martin Bjorklund
- BC = Benoit Claise
- PO = Peyman Owladi
- PH = Peter van Horne
* Summary
During the meeting, the issues Y07, Y09, Y10, Y11, Y12, Y13, Y14,
Y16, and Y18 were discussed. For each issue, either a strawman
proposal has been found or concrete action items have been
assigned. We will continue with two more virtual interim meetings
before the face-to-face meeting in Toronto.
* Y07: do not allow when or if-feature on keys
AB: Says the solution is wrong, if-feature / when should not be more
specific than the parent.
AB: Is there not text somewhere else in RFC 6020?
PO: The leafs condition should at least be as restrictive as the
parent context.
PO: A statement that says something about the parent is irritating.
AB: What if I put if-feature bar on the parent?
MB: That is OK.
LL: What must be avoided are lists where keys are (partially) undefined.
MB: Make them illegal if the condition is different from the parent.
Proposal: Adopt Y07-01 with a clarification about the condition.
* Y09: introduce optional keys
Action: MB will write up a solution proposal.
* Y10: allow restrictions on enumerations
MB: I think we should do what SMIv2 allows.
AB: What prevents the second typedef from redefining enum a?
MB: Redefining the value would not be legal.
LL: What about having a different statement to define the set of allowed
enums to prevent overwrite issues?
MB: Not sure this helps since you can do pretty much all of this with
strings and pattern, see the first example.
AB: What happens if foo has a default b?
MB: That would be illegal.
LL: I prefer a different syntax.
Action: LL to write down another syntax proposal and MB to expand
Y10-01.
PO: What about restrictions on unions?
MB: Currently not allowed, should they be allowed?
JS: Unclear whether common programming languages allow something like this.
MB: An implementation issue.
JS: But people might simply not expect this to be available.
MB: Lets discuss this later, this is a separate issue.
* Y11: allow if-feature on enums
MB: This avoid having choices with an empty container.
AB: This is somewhat different since this usage of if-feature
is not related to data tree nodes directly but instead applies
to the value space of types.
PO: If you have if-feature for enumerations, would you also want to
have them for identities?
MB: Likely yes.
AB: I like this since it allows an NMS to restrict values shown to
a user based on the announced features.
Proposal: Adopt Y11-01 with the extension to allow if-feature also
for bits and identities.
* Y12: initialized-by system
JS: Does initialized-by system mean may be initialized-by system?
And initialized-by user means must be initialized-by user?
MB: No, it is more boolean.
MB: This is not a default, the server generates a suitable value.
PO: What about ports that change the MTU when sub-interfaces are
configured?
MB: YANG does not support dynamic defaults in that way.
AB: What about processing an edit-config with multiple list
entries, some with explicit values, some without?
MB: The server would have to figure this out.
JS: The server can be smart to figure out suitable values for a
given commit or be dumb and return an error (similar to an
edit-config with conflicting uids).
LL: Should probably have a different syntax, initialized-by user
is misleading, perhaps system-initialized true|false. It is
really system-initialized-if-missing.
LL: Only valid for leaf?
MB: I think also leaf-list, for consistency.
PO: May be a bit related to mandatory, default is likely illegal
with initialized-by system, need to write more complete text.
Proposal: Adopt Y12-01 but think about a better syntax. Applies to
leaf and leaf-lists. MB to create concrete text.
* Y13: allow multiple inheritance for identities
AB: I am not see the example - the example only defines two
regular identities.
LL: Not sure I wrote the example.
AB: What do I get by having multiple bases to an identity?
PO: Interfaces are good examples.
LL: It is good to use identityref with multiple bases.
JS: How do you maintain the identity derivation graph if things are
added over time?
LL: This is only useful if we have suitable xpath functions.
JS: Can someone write a complete example that shows how this solves
interface type issues?
Action: LL to write a more complete example.
* Y14: clarify the string value for identities when used in must/when
MB: I think Y14-01 is already used in the routing model.
LL: Need for this drops once we have xpath functions.
MB: We still need to define this.
Proposal: Adopt Y14-01.
* Y16: module advertisement optimization
AB: Not sure this is a YANG issue alone.
MB: YANG module advertisement is defined in RFC 6020.
AB: This does not work because there is no version number. If the
client could say here is what I have cached, then this could be
made to work.
MB: If we only suppress YANG 1.1 modules?
JS: Is the info in RFC 6022 (Y16-02) complete?
MB: Not sure, we implement /netconf-state/capabilities as what was
in the hello.
PO: I am leaning towards Y16-02.
MB: RFC 6022 talks about NETCONF capabilities. Does it also contain the
data models?
AB: Right now, the hello contains all modules. But this should actually
be subject to access control.
AB: I am in favor of Y16-02 since it allows to hide loaded modules.
JS: How does this work in RESTCONF?
Action: MB to look at the details whether Y16-02 can be made to work.
* Y18: fix "when" expression context node problem
LL: I do not like the solution proposal. The result may depends on the
order.
LL: My proposal would be to treat when equivalent to must.
MB: But this is backwards incompatible.
MB: I do not understand the problem you see.
LL: You need to at least specify what happens if there are circular
dependencies.
MB: Seems like a theoretical corner case.
PO: Perhaps even leaving this implementation specific?
AB: There are other when issues, e.g. the order in which expressions
are evaluated and it gets work if when expressions interact.
MB: How likely is this going to be a problem?
Action: LL to write up an example in which situations Y18-01 is
problematic.