Minutes for NETMOD at interim-2014-netmod-15
|Meeting Minutes||Network Modeling (netmod) WG Snapshot|
|Title||Minutes for NETMOD at interim-2014-netmod-15|
|Other versions||plain text|
============================================================= NETCONF Data Modeling Language WG (netmod) 6th YANG 1.1 Virtual Interim Wednesday, October 15, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - BL = Balazs Lengyel - MB = Martin Bjorklund - LL = Lada Lothka - EV = Eric Voit - AB = Andy Biermann - V? = Vladimir - DR = David Reid - JT = JF Tremblay - KW = Kent Watsen - TN = Tom Nadeau * Organizational - This is the last virtual interim allocated to YANG 1.1. How do we continue? - Allocate slots to continue right after the IETF week, keeping the Wednesday slots. - Can we use the 29th of October? The IETF meeting is November 9-14 and the next possible slot after October 29th would be November 19. - During the next meeting, we will try to tackle the conformance related issues again. * Y58 associate an actions with a data node JS: Is Balazs proposal complete? Do we need to formally define an RPC? MB: Yes, there should be an RPC for it. BL: I agree with an RPC definition. LL: What about the approach of sending an instance identifier? BL: Is this Q2? BL: Having the action element inside of the nested tree avoids issues with name clashes. This also maps more natural to the CLI. AB: The signature of a reset action may differ significantly depending on where it appears. AB: I do not really like this much but this is all implementation detail. MB: Does the DSDL not work with the example we have here? MB: I see why using instance identifiers may be problematic, I do not see why the nested encoding would be problematic since you have all the context. LL: How does this work with access control? AB: I believe NACM would need to be modified to check parameters that identify where an action belongs. It is easier for the nested solution. JS: Does this require changes to NACM? MB: The data model allows to set this, but the text in the procedures needs an update. MB: Action to look into the details of the NACM update. JS: What about notifications associated to data nodes? BL: No indication that somebody seriously wants this. AB: From a YANG point of view, it seems strange to do this for actions but not for notifications. MB: I agree with AB. LL: Are the access control arguments valid for notifications as well? KW: How is the list instance identified? MB: This is in the example, see the name leaf of the server element. Proposal: Use the nested encoding but remove the data wrapper. Open Y36 again and ask for proposals how to encode notifications associated with data nodes. * Y57 unique leaf-list LL: If we have such a leaf-list and it is ordered by system, it seems impossible to insert after a certain position. BL: Yes. AB: An insert after is always an error on a system ordered list. LL: Seems to be OK. I support this change. BL: Q1 - go with A1a? AB: A single leaf-list value is often not interesting, usually it is the whole list. KW: Do we need to solve this at all? Where does this pop up? LL: An example is an AS path where AS numbers can repeat. BL: We have a number of examples in proprietary data models. BL: Q2 - go with A2a? BL: Q3 - go with A3a? MB: What do you mean with addressing? MB: Can you also delete by position? Would that not be a solution? BL: Prefer to delete just one. MB: I agree with Andy. The way we handle leaf-list today makes this somewhat awkward. MB: If we add this, then the way we do thinks today becomes more a pain. AB: The way NC works today is that only one instance is deleted at time. MB: So this means A3a. AB: Yes. BL: Q4 - go with A4b? AB: Do we need a YANG substatement to say whether a leaf-list allows duplicates? BL: Yes. MB: How would you move say the second a somewhere else? BL: With position, you can remove the second a. MB: For moving, you have to specify two positions (current, new). BL: A move operation is currently not part of the proposal. BL: Do we need a move operation? JS: Does all of this only apply to ordered by user lists? BL: Some operations may require position and thus ordered by user lists, but others don't. LL: Can we simplify this? Does it make sense to edit system ordered lists? AB: I think it makes sense to restrict this to user ordered lists. MB: Why would we make it illegal to have duplicates in system ordered leaf-lists? LL: We are talking about different collections, lists and sets. LL: Perhaps we can even make this leaf-list and leaf-set. MB: Would the set have an order? BL: We have use cases for unique ordered lists. LL: You can use a must statement to make the list elements unique if need be. MB: We need to be compatible with YANG 1.0. MB: If an ordered-by user leaf list is moved to 1.1, then it means something else? AB: I do not want to introduce any changes unless absolutely necessary. We should not change silently how a leaf-list works. MB: Having the same YANG statement mean different things in two versions of YANG is to be avoided. BL: Unless you use the new keyword, everything works as it was before. MB: I rather add a new substatement than changing the semantics of existing statements. BL: A5 MB: Yes. KW: Some system ordered lists tend to be stable. MB: We need to be careful what happens with position if access control is applied. BL: I believe it is the same as why insert is not allowed on system ordered since there is no guarantee that the order is stable. KW: If I do a get-config followed by an edit-config on a single session, is the order not predictable? AB: The RFC is pretty clear that there is no guarantee that the order is stable. AB: An example is a balanced tree where a change of the tree can change the walk order significantly. KW: If the order could be assumed to be stable, position would work for at least a single session. MB: I am not sure why would use that. You can delete by value. BL: But for system ordered, you can have multiple values as well. LL: Leaf-lists in operational state will be system ordered and I can see that there might be non-unique values. BL: A6 BL: A7 AB: Does in this case position say find the second leaf-list element with the given value? BL: I have not thought about this in this way. MB: I think it should be the absolute position. AB: If you provide a value, you want the second of those with the same value. MB: If the leaf-list is a string and you allow an empty string, you can't distinguish the two cases. AB: This is a good point. But I do not like the server ignoring a value if it is presented. I think this should actually be an error if the value is not at the position. MB: I agree. KW: Yes. BL: A9 AB: Agree. BL: A8 AB: This should be an error. This is an edit-config that is not a delete. MB: What about replace? BL: Move is difficult since it requires two positions. BL: We skip A8 because I do not understand it right now. BL: Do we need a move operation? BL: If nobody speaks up, we will not do a move operation. BL: I will take an action item to write a proposal and a summary of the changes that are needed. * Y56 UTF8 non-characters LL: Is this to be done at the protocol level or the YANG level? JS: I think we should say what is allowed in YANG MB: This is about the character set, not about the encoding (UTF8 or UTF16, which is a protocol issue). MB: I agree that we should define in this in YANG. Proposal: Adopt Y56-01. MB will work the concrete text with the help of LL. * Y42 a better model for configuration versus state data is needed JS: We may want to move this to closed since there is nothing to do until I2RS has decided what they need. Once this happens, we can reopen this issue or add more concrete issues (which may be a better choice). Proposal: Move Y42 to DEAD. * Y28 support default values in leaf-lists LL: What about additive defaults? BL: Do you have examples where this is useful instead of overriding? LL: I can create an example, but perhaps additive defaults get complicated. BL: My feeling is that Andy's always replace behavior is simple to understand. JS: Adopt Y28-02? MB: Yes AB: Yes LL: OK Proposal: Adopt Y28-02. * Y13 allow multiple inheritance for identities AB: Is this an OR or an AND if I have multiple bases? MB: Y13-01 says AND. AB: If in the example the base would be non-commercial, only CC-BY-NC-SA would be valid. MB: We probably want multiple bases in identityrefs. But then why would it be AND and not OR? AB: I am not sure how this impacts my implementation yet. MB: You can get an OR by using a union type of multiple identityrefs. JS: Seems we go with Y13-01. Proposal: Adopt Y13-01.