============================================================= NETCONF Data Modeling Language WG (netmod) 2nd YANG 1.1 Virtual Interim Wednesday, June 11th, 2014, 16:00-16:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - 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 * Summary 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 meeting. 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 list. 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 moment). 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 changing. * 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 if-feature and; or if-feature or; 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 nodes? 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 edits. * 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 illegal. MB: This is really a bug in the YANG 1.0 specification and we better fix it. 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 backward compatibility. AB: Why do we need to be able to reference things in the notification? 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 notification? MB: LL, is the example in Y04 is valid? LL: It could be valid - current() means the bref in the notification. 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 actually works. * 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 undefined forever. 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.