Minutes for NETMOD at interim-2014-netmod-2
||Minutes for NETMOD at interim-2014-netmod-2
NETCONF Data Modeling Language WG (netmod)
2nd YANG 1.1 Virtual Interim
Wednesday, June 11th, 2014, 16:00-16:00 CEST
Minutes Juergen Schoenwaelder
- JS = Juergen Schoenwaelder
- AB = Andy Bierman
- KW = Kent Watsen
- MB = Martin Bjorklund
- PO = Peyman Owladi
- DR = David Reid
- AZ = Alex Zhankin
- LL = Lada Lotka
- PH = Peter van Horne
- GH = Giles Heron
After a short review of the outcome of the last virtual interim
meeting, the group started going through the open issues in order to
discussion solutions. Strawman proposals for solutions were
identified for Y01-Y06. Since MB will be unavailable the next two
weeks, it was decided to skip the next two virtual interim meetings
and to continue on July 2nd.
It was agreed that JS will track the state changes of the issues in
the issues list. MB will start work on a first I-D for YANG 1.1. It
will contain a section with a high-level summary of the changes since
RFC 6020 that will be part of the final RFC plus an additional
section in the appendix cross referencing the issues list. This
section is intended to make reviews of changes easier and will be
removed from the final RFC.
* Y55 clarify type in union
MB added this issue as discussed in the last virtual interim
Proposal: Open this issue. JS to confirm this on the mailing list.
* additional clarification issue on the mailing list
AB: Did recently send an additional clarification issues to the
MB: I believe this falls into an existing issue (Y41)
AB: Why is the server making decisions whether or not to return nodes?
MB: I am not sure I understand the question. It always depends on the
semantics of the particular leaf.
AB: A mandatory false node will not be returned if and only if it
does not exist (ignoring filters and access control for a
MB: Depends on the semantics of the leaf.
PO: Non-existence can have specific meaning.
KW: Mandatory true would mean that a leaf always exist.
MB: Is this something to be clarified?
AB: I will take a look at the text to see whether something needs
* Y01: allow boolean if-feature
AB: I am fine with accepting Y01-01, the specification should get
the operator precedence right.
AB: There might be an issue with a feature called 'and'.
JS: This clash should only be an issue for
and these can be handled as special cases.
MB: Will add text to make sure that theoretical clashes with
features like 'and' and 'or' are well defined.
Proposal: Adopt Y01-01, MB to work out the edits.
* Y02: allow must in input, output, and notification
AB: Why do we need these top-level must expressions? When are
they evaluated? I am fine with Y02-01, not sure about Y02-02.
PO: I believe mandatory is essentially like a must in a top-level.
AB: YANG does not allow top-level mandatories. The reason is that
in practice not all servers may have mandatories all the time,
e.g. when a module is loaded.
MB: If you load a module, you need to provide a factory default
because otherwise the module would be invalid.
PO: Here is an example: There must not be more than 100 VLANs on
this port. This must applies for a top-level list. The logical
place for the must statement is at the top-level.
MB: We have the same issue with an empty container.
AB: What is the context node for the must? The root?
AB: Should we also consider rpcs? Or does this only apply to data
MB: It seems Y02-02 does not work because of unclear context, so we
better go with Y02-01.
Proposal: Adopt Y02-01. AB and MB support this. MB to work out the
* Y03 allow if-feature in refine
LL: What does it mean? Assume feature in A, grouping in B.
C imports B.
MB: The grouping does not use the feature.
LL: Yes, I got confused.
AB: Are there any problems if a refine rewrites an if-feature,
e.g., adding or removing something from the expression?
MB: But grouping expansion happens in the usual way, you could always
cut and paste the grouping and add the if-feature as you like.
LL: I think this is OK.
KW: Can this break existing clients?
LL: No, a server would have to advertise a new module.
KW: I am not sure whether there could be an issue.
Proposal: Go along with Y03-01. KW to double check that there is no
issue with dependencies and versioning.
* Y04 accessible tree in xpath in notifs and rpc
JS: Where has this become a problem?
MB: Look at the example.
LL: Is this similar to something in the SMI?
AB: This does never happen in SMI.
MB: The current situation is somewhat wired.
PO: If you define a type in a top-level module, you can't use that
type inside of a notification?
MB: Yes, this is kind of true. It depends on the path and whether
you have the same structure in a notification.
PO: Are we sure this is a corner case? Reusing a type in a
notification may happen more frequently.
MB: If we make this change (Y04-01), then existing notifications
may be illegal.
AB: We need to rule out solutions that make YANG 1.0 modules
MB: This is really a bug in the YANG 1.0 specification and we better
AB: I am in favor of Y04-04.
MB: But how do we make the bref path legal in YANG 1.0?
AB: When is this path expression actually evaluated? When the
event occurs, when the notification is being prepared?
PO: This seems to tighten the restrictions but conflicts with
AB: Why do we need to be able to reference things in the
AB: If the notification is returning copies of stuff in the data
tree, everything should be fine. I am concerned about breaking
things by changing the meaning of the path statement.
AB: I believe this is a really corner case and any solution must
keep existing notifications valid. It may require a new keyword
to introduce different semantics.
MB: What is the initial context node of a path statement in a
MB: LL, is the example in Y04 is valid?
LL: It could be valid - current() means the bref in the
PO: Solution Y04-02 is _not_ problematic since top-level names can't
clash according to RFC 6020 section 6.2.1.
Proposal: Go along with Y04-02 now that we have realized that it
* Y05 unprefixed path in top-level typedef
AB: I am fine with the first solution.
PO: The binding should be done where the typedef is evaluated.
JS: I agree with PO.
MB: This would be solution Y05-03.
Proposal: MB to write down solution Y05-03 and once done we get back
to this issue.
* Y06 escaped characters in double quoted strings
LL: A third solution is that \x means x.
MB: Randy Presuhn likes Y06-02.
LL: There may be backwards compatibility issue.
PO: We pay attention to existing implementations or, if something is
undefined, we are free to choose any interpretation.
JS: What does "all known implementations" mean?
MB: At least YumaPro and Tail-f.
JS: This is a much more narrow statement.
MB: Guidelines should say better use single quotes for pattern.
PO: Could others have copied RFC 6536 style?
MB: The only hard backwards compatible solution is to leave this
LL: I am in favor for Y06-02.
KW: I think this is the best option.
MB: I am in favor of Y06-02.
JS: I am in favor of Y06-02 as well.
AB: I am fine with this, it seems a regression bug fix.
Proposal: Move forward with Y06-02.