o============================================================= NETCONF Data Modeling Language WG (netmod) 3rd YANG 1.1 Virtual Interim Wednesday, July 9th, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AZ = Alex Zhdankin - AB = Andy Bierman - LL = Lada Lotka - PO = Peyman Owladi - PH = Peter van Horne - AN = Anonymous - TN = Tom Nadeau * Summary * 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 OK. PO: You are not allowed to use it in cases that break backwards compatibility? 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 nodes. 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 this properly. 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 6087bis. * 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 union. AB: This might make differences if you make multiple updates in an edit-config. 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 several people.