Minutes for the NETMOD WG Sessions at IETF 101 ----------------------------------------------------------------------------------------------- IETF 101, London, March 19-23, 2018 Two Sessions: TUESDAY, March 20, 2018 15:50-18:20 (Blenheim) WEDNESDAY, March 21, 2018 13:30-15:00 (Blenheim) WG Chairs: Lou Berger Joel Jaeggli Kent Watsen Available During Sessions: Audio stream: http://ietf101streaming.dnsalias.net/ietf/ietf1012.m3u Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-101-netmod Meetecho: http://www.meetecho.com/ietf101/netmod/ Jabber: xmpp:netmod@jabber.ietf.org?join/ Slides: https://datatracker.ietf.org/meeting/101/session/netmod Available Post Sessions: Recording: https://www.ietf.org/audio/ietf101/ YouTube: https://www.youtube.com/watch?v=e2iTr8EDlwA TUESDAY, March 20, 2018 15:50-18:20 (Blenheim) Afternoon Session II Room: Blenheim ============================================== Session Intro / WG Status Chairs (15 minutes) #1 Interface-ext & VLAN Lou Berger: What's need to get interface-ext and VLAN drafts to Last Call? Robert Wilton: 1) For interface-ext, there's not that much more to doing these drafts it's really just adding some examples. I think that they should be ready for working with last call, so there's not much further to do. 2) For intf-vlan-model, it need checked with IEEE. Lou Berger: In order to do that check, do we need to do a formal liaison or will you just handle it through informal you know people working in both organizations? Robert Wilton: I'll do informally. #2 Liaison response to IEEE & BBF: Benoit: I've seen those liaisons, I wanted to send answer to those SDOs, and I was just waiting for the last piece -- the schema mounts. So hopefully it will be done pretty soon. Chartered items YANG Module Tags Chris Hopps: (10 minutes) https://tools.ietf.org/html/draft-ietf-netmod-module-tags-01 Robert Wilton: (Slides P3) One of the implications is that ‘mask tags’. It is gonna be a list of things you're removing from the operational states, so in the operational view of the data, you'd only see the tags list module tags. You wouldn't see the masked type of the tags. This is an interesting case where you've got some new configuring that then it doesn't appear in operational state, it doesn't appear in the apply convict this effectively I can and negative complicated. So I think goodness to think that through and check that that's the right switch. Chris Hopps: We should look at it make sure it's the right way. Benoit Claise: Are you going to use this yourself and when you have your to change depending on that. Chris Hopps: I personally don't do our module organization, so I can't say exactly how they're gonna use it. But I've presumably the device model. Benoit Claise: What do you expect the vendor within there? Chris Hopps: I don't have expectations or anything. It's like hashtags, I picture it more as something that's it's a not an obvious thing that we do. We organize things and people may come up with new ways to use it. The example that caused it to be birth was that the device model. Martin Bjorklund: When we talk to device from an orchestrator and the device advertisers, you sell modules, and there are some overlap, for example there might be a native way of doing stuff, ietf standard way of doing stuff, and openconfig way of doing stuff. And these models overlap or they provide the same functionality, but your different modules. in that case it would be very useful to find out which modules belong to itself, so that we can make it one of them, so that's something I would like to see. Martin Bjorklund: Another comment on this: if you consider using identity? Chris Hopps: No, I mean the idea was to make it. So it (tag type) could organically be used organically, so that the user could add them easily to the system, and so that would be done sort of install routers or hardware in my system, and I want to add things. Michael Wang: If you consider to define some metadata? Chris Hopps: There are other mechanisms to actually tag instance data right. This is working on the schema level. YANG Data Extensions Martin Bjorklund (10 minutes) https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-01 Kent Watsen: I think if you want to use groupings that the module designer has to anticipate that the grouping would have to be fine, because they meant they may actually have groupings to implement. But if they did that, that's great. If they don't do that, could scheme mount be used? Martin Bjorklund: Possibly. For the other hand this yang data extension, it defines the data structure that is not part of any datastore. It's something outside of datastore, so I wouldn't think that schema mouth should be defined in this extension. Robert: Keep it simple. Kent Watsen: This draft say that anyone who wants to create a yang to use this yang extension, that they must create a grouping, and then use the grouping, and they're thereby ensuring the downstream compositions can occur by using the grouping. Juergen Schoenwaelder: I prefer that extensions do not define data nodes. Alex Clemm: I just want to mention this is important to be solved. I don't know where the right place, but I think that is really a key something that it's missing action framework and we need this. Martin Bjorklund: The question is should we do it in this document. Maybe separate documents will address it. Joe Clark: Ratify this and use this to focus on something. More error focused in a different document. Kent Watsen: If we don't do it now, then we would have to spin up another effort almost immediately. Because there are dependencies from the yang push, and really the drafts need to have this. Martin Bjorklund: This is more important to publish the basis draft with a yang day extension. Alex Clemm: Just for future. Non-Chartered items: New YANG Module Update Procedure Joe Clarke (10 minutes) https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-03 Christian: When you're deprecating, is there an ability to specify a time duration? Joe Clark: We don't have a specific data element. We introduced for a time bound deprecation but we talked about it in the text. Ruediger Volk: In irregular software development rather than a deprecation date, I get the version number that is going to duplicate with IETF process, kind of dates are hard to predict. Version numbers can be managed. Chris Hopps: When you say you don't want a date. Is that you don't want a date to be standardized or you don't want to date from the vendor telling you when they're gonna stop supporting it? Ruediger Volk: I mean you don't want to have to say I have to obsolete this now, because I picked that day. There's something the data is useless. Lou Berger: The date means is expect this to disappear unless you come talk to us. A lot of distros have version and dates on which they'll stop supporting their version Ruediger Volk: I'm just saying don't standardize don't require a date. Benoit Claise: That's a thing right, because if you're a vendor and you know to be duplicated and you know the version you can write, but if you don't know it's going to push yourself a constraint just don't do it. (you need tooling) Lou Berger: I really like that approach, because it addresses the issue of a server meaning to support older and newer clients at the same time. It gives you a nice transition timeline. Lou Berger: It's not really changing the module name, it's a new semantics to the xpath. It happens to be a change of the path, but really it's just an encoding of the major version. Robert: A patch level is useful, it is like a rafter on published module where you might be modifying example description statements, but it's useful to say it has changed, but the change is sort of insignificance. Lada Lhotka: 1) Suggest not to introduce this, because sub-modules have their share of problems, and I believe if they are used, then they should be really tightly coordinated and the revisions can be included in yang version information, so I believe this is not necessary to do it. 2) Patch number may be useful. Using patch semantic version, it might be possible to keep the RFC unchanged. Chris Hopps: Non-speaking as an operator. I want the namespace of change, it's backwards, it's not compatible, I can't deploy and run a client against something where there was a backwards incompatible thing. Lada Lhotka: I proposed to encode derivation, not a date in the namespace. Chris Hopps: I wouldn't want revision in this namespace, because it's not changing. If it's compatible, I can still control that device, even though it's a newer version, I don't want to change them. But for a major change, I can no longer use my client controller, so I wanted to change light but only the major. Blaze: We allow incompatible changes without name changing, or given today and changing the name is rather big, and people like to see their connection. Martin Bjorklund: I think you're making pretty fundamental changes to the yang language. There's probably need for a new yang version, but he thinks the change for deprecated obsolete or something that should definitely be pursued. Tom Petch: It too late. Benoit Claise: I've been seeing different SDOs open-source project and also vendors that we need to change the way we've been working. We could say we have a good metric because the number of languages producing RFC are going up. If people leave that you have the perfect yang modules, not use from now, because an RFC. This is just wrong. Mahesh: Is there anything in the draft that actually talks about how authors are supposed to keep track of the major minor changes? Joe Clark: In this draft in terms of how one determines what is say backwards-compatible, the concept of this derived semantic version. We've been using in a tooling standpoint algorithmically to determine when the major, when the minor, when the patch version would increment. Juergen Schoenwaelder (jabber): I agree with Martin that changing the versioning is far reaching impact and requires a new version of YANG. Jason Stern: I think what you're saying is we have two forms of major breaking changing a module name and changing a major version. A YANG Data Model for module revision management Michael Wang (15 minutes) https://tools.ietf.org/html/draft-wang-netmod-module-revision-management-00 Kent Watsen: Why are you defining a top of a model instead of augmenting yang library? Michael Wang: Actually, we also augment the yang library. This model is used to provide the update details. Robert: This is something that's useful to standardize or whether this is just something that we provide advice and tolling? Michael Wang: I am not sure whether is better, defining a standard or a tool, it depends on WG’s decision. But I think it is not a bad idea to define an information document to guide user to do such works. Joe Clark: The semantic version doesn't standalone by itself, you have to compare it to something. I think from the tooling standpoint there's huge value in this. We've already seen consumers they appreciate the output of that, but I don't know that alone, what you are solve. I don't know that our proposal and your proposal conflict. Michael Wang: I don't think to have some overlap, I believe that two solution can compatible. I think they can work together. Your solution can help user to know this version is big change version, or patch version. And our solution help to reflect the update details. Carry (Nokia): This requires two things for this to work. One is for people to provide it and the other is to have the ability to consume it. I would suspect that if we're having problems with vendors already that that say I'm not even adhere to a major, minor, patch. A guideline that they're gonna be able to build all these individual constructs and archives. It's a great idea. I'm just wondering if the industry would be supportive of that as they define their modules and have that particular rigor in place or require that particular rigor and that's my biggest concern. Joe Clark: We don't expect any vendor to produce these artifacts what we've done in our tooling. Jason Sterne: I'm not sure what the clients gonna do with this list of dynamic information. Kent Watsen: Same concern. Michael Wang: In some vendor systems may support different revisions of same module, and they can check the change log list to decide if they need to update or synchronize all of models which depend on this. Open discussion (0-20 min) Handling Revisions (Miss name): I don't know how to solve this I can just assume user and operator in your safe. I've had a lot of pain when it comes to going between different versions. Kent Watsen: I think we need to be more things Chris Hopps: This is not particularly an IETF thing, it relates to modules and yang. I think the IETF can change, but one really painful thing that we've had is that vendors are changing the modules of a ship like with every release in incompatible ways. Kent Watsen: There's no guarantee that anything's backwards compatible because we can't, but going to your other drop the module tags draft, so there's standards modules, and there's vendor specific modules, so maybe this would be very beneficial for standards which is our personal pain point and then vendors can continue to be backwards. Balazs Lengyal: You can very fast determine if it's compacted or not, and then you can try to use your software that was prepared for the other compatible version. And I don't want to change the module name or the namespace because all my scripts, all my software, will stand down that namespace and that module name. I don't care about my being compatible, but I don't care about that there's a change I have to investigate it, and that I can decide what to do about it. Lou Berger: When you say that you want to discover what's changed. You want to do that with the device or would you like to do it with offline mechanism like a catalog based mechanism? Balazs Lengyal: If I get the simple that's good for me what the changes are, you can't find out more you lose compact were incompatible really programmatically. Often we have the case when the model is not changed for the behavior behind the model it's changed, so you will anyway need to study manually. I would say that this detailed analysis, it's very useful. Charles: This maybe being too late for in some regards, but I think through the need for this type of thing is only going to increase a lot of requests or we need to move faster when we move. So I think whatever mechanism we do, we've got in order that it works very well for lots of backward compatible changes, that's done to work very a little touch easy way to deal with that just. The faster we try to put out yang models the more we're going to have to change. Kent Watsen: Yang next that would be a long term solution, we really need a short-term solution. Can we work what is the word short-term solution? Balazs Lengyal: That's what we are doing, we come to a new yang version. Chris Hopps: I'll count that idea earlier. I don't think we need to change the language if we were to put some semantics on the URL. I'm sympathetic to the people saying the patch number was useful. Robert: Just adding in semantic version as an extension or protection is fairly easy. Tom: We're too late to try and impose a formal structure of major/minor patch and so on. Juergen Schoenwaelder: Namespace is used by XML, JSON uses module names for the name space. So you have to change the module name for a major revision. Lou Berger: How many think the working group should be working on the topic of model versioning? (Good number) Joel Jaeggli (via jabber): Agree that it is an important problem. We need operational guidance on to work with that I can just say, I had pain, I don't have other quickly the doctor please make me better. Lou Berger: How many people would be willing to work on the problem, and with the understanding that the first step is to define what problem we're gonna address. (Reasonable number) Lou Berger: How many are willing to offer text. (Reasonable number) Lou Berger: OK, we would like your names send it to netmod chairs. We're gonna talk about maybe doing either an informal or formal design team. Lou Berger: It's a design team to go work the problem, and the first step will be the problems statements. YANG model for finite state machine Nicola Sambo (10 minutes) https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-02 Jason Sterne: I assume the idea is going to do maybe a configuration change, just as if it was any other management client like netconf client. Nicola Sambo: The use case of the transponder yes there is a configuration action. so we reconfigure the modulation format and the fact. Jason Sterne: This action which is trying to do a configuration change just like any other client it's gonna get blocked. Because the management system is doing some edit configs, doing a commit that could take seconds or a minute or however long it wants, if this is just doing a standard commit like any other a standard configuration change, and commit like any other client, then it's gonna be stuck behind any locks by any other management stations. Nicola Sambo: We can we can think about how to how to handle these issue. Joe Clark: What if nothing changes in that? Nicola Sambo: If nothing changes that that it means that no transition is triggered, and we stay in the same state, in the current state. Xiaojian: There is maybe need a detection mechanism. Nicola Sambo: We can execute actions in sequence but we can also think to execute actions in parallel. Kent Watsen: May have overlap with ECA model. Lou Berger: The next step is to talk with ECA model and see if you could get them work together. Document Conventions for Handling Long Lines in Artwork Containing Code Qin Wu (10 minutes) https://tools.ietf.org/html/draft-wu-netmod-yang-xml-doc-conventions-00 Kent Watsen: As a contributor I think this is an important problem solve, and this is a unique to XML now, like to cover Json and other formats. Balazs Lengyal: We need a convention. Benoit Claise: It's a larger problem. Kent Watsen: Make it simple so we can get a solution now faster but I would say this is a lot more complex than what I proposed. Lou Berger: This is something that could just be solved through tooling. Do we need a document on it? Benoit Claise: You know just having a convention there would be way more helpful. Robert: I think it's a useful problem to solve. Just pick one that's quite simple to do and just move with it fast. Martin Bjorklund: I think we should do this. I agree with Kent to make it simple. Lou Berger: How many people think that this problem is something we should solve in the working group? (Reasonable number) Lou Berger: How many think that this draft is a good foundation a good starting point for the working group? (Reasonable number) Lou Berger: How many people would like to talk and tell us why they think it's not a good idea to start with this document? Charles: It gonna be too complicated. I just like the very simple. YANG Instance Data Files and their use for Documenting Server Capabilities Balazs Lengyel (10 min) https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 Robert: I like this work useful. In terms of your model definition, you using metadata, not using regular leaves, there is not clear to me. Balazs Lengyal: Because this is actually metadata about the instance data set. It's not real data. Robert: Other comment is you've defined XML, JSON format I think also again doing a binary encoding, it could be useful. Joe Clark: Yes, we there's value. Balazs Lengyal: I would add that yang module tags as one more use case. Lada Lhotka: An adoption is to define this instance data as a normal container, and the scheme mount for inserting or building this are not supposed. Martin Bjorklund: Help to have top level stuff in here. Kent Watsen: I agree with Martin, I think it is an useful work, but I also thought that yang might have been a better approach for approaching this. WEDNESDAY, March 21, 2018 13:30-15:00 (Blenheim) Afternoon Session I Room: Blenheim Video Recording: https://www.youtube.com/watch?v=wI4oHJ9_4KE ================================================ Session Intro Chairs (10 minutes) Schema Mount : Resolving Last Call Comments Martin Bjorklund (20 min) https://tools.ietf.org/html/draft-ietf-netmod-schema-mount Kent Watsen: Is a presence container really necessary? Martin Bjorklund: No. We don't want to require parent reference. Benoit Claise: Next steps - new version, then Last Call for two weeks for full review. Lou Berger: v09 might be sufficient. Based on comments, a v10 might be necessary, but not a given. Benoit Claise: are the NMDA compliance statements currently included? Martin Bjorklund: It should state that it coveres both NMDA and non NMDA servers. Long Term rfc7895bis / NMDA Schema Mount Support Discussion Ladislav Lhotka (20 min) Martin Bjorklund (20 min) Rob Wilton: this means you can embed a schema anywhere? Lada Lhotka: yes. Jason Sterne: does this mean can only embed one schema at a node? Lada Lhotka: not sure if we need to worry about multiple schema at same target. Martin Bjorklund: so Jason's point, I mean you wouldn't with this proposal you would not support what we have today and that any use case requires where you could have possibly different schemas at different instances of the same mount point. It explicitly does not support this case. Lada Lhotka: this does not support in-line case Martin Bjorklund: so this would be use in addition to the existing schema mount? Lada Lhotka: yes Lou Berger: What is a schema-node-id (on slide 4) Lada Lhotka: Same syntax as we use for augment Robert: Are we are also standardizing instance data? Lada Lhotka: We would have examples in the documentation Balazs Lengyal: it is fine for instance data to be a prescriptive part of an RFC Lou Berger: the node we are augmenting might have other children, and could this drive complexity? Maybe this is a designer's choice (just put in a restriction to avoid collisions.) Martin Bjorklund: augment is different from a Mounted Schema because the mount implementation cannot place the same constraints on execution environment Balazs Lengyal: you should take just as much care in implementation of both Lou Berger: should we consider design-time mounts? Lada Lhotka: would need a new YANG 2.0 for this. Balazs Lengyal: The YANG library instance data does in effect give you design time mounts. Lada Lhotka: we need to make sure design time mounts mean the same things to both Lou & Balazs Lengyal: would love to have a statement of what can be supported in the draft. Lou Berger: A mounted schema might have dependencies specific to that module which need to be documented and expressed Martin Bjorklund: instance documentation in RFC might also result in deviations (how would these be documented?) Robert: can provide text rather than instance data in RFC as a way of avoiding such complexities Lou Berger: we can determine whether this is in WG scope after someone comes up with a proposal to consider. Lada Lhotka: so this would Obsolete SM-09 Martin Bjorklund: more like it, updates it Lada Lhotka: prefer to keep inline and use-schema cases separate Martin Bjorklund: This would make library complex. Tim: did you say this solution just get used with NMDA? Martin Bjorklund: can work with non-NMDA elements, and pre-NMDA solutions as well. Discussion (20 min) Rob Wilton: What is see difference between solutions is how heavyweight the solution is. Heavyweight favors Martin's solution, lighter weight matches better to Lada's proposal. Prefer heavyweight. Balazs Lengyal: worried about level of complexity from the many proposals. Lou Berger: This is the start of a discussion, and is should converge. Discrepancy detection between NMDA datastores (Alex Clemm) https://tools.ietf.org/html/draft-clemm-netconf-nmda-diff-02 https://datatracker.ietf.org/doc/slides-101-netconf-discrepancy-detection-between-nmda-datastores/02/ Robert: what level of comparisons validly can be done across different datastores (e.g., intended and operational)? Expect nuances. Alex Clemm: the intent is to compare data which propagates between datastores. Martin Bjorklund: just compare the nodes which are actually in the different datastores. Put this explicitly in the draft. Martin Bjorklund: need to explain how the filters are supposed to work. I.e., defining a common selection. Martin Bjorklund: this is important work, and should be done. Rob Wilton: thinks it generally useful Lada Lhotka: supports the work. As for filters, use something simple. Perhaps just root and depth of trees. Martin Bjorklund: subtree and xpath filters are available Lou Berger: Please publish on NETMOD, and get ready for comments. Generalized Network Control Automation YANG Model (Igor Bryskin) https://tools.ietf.org/html/draft-bryskin-netconf-automation-yang-01 Lou Berger: this seemed a model based thing rather than something protocol (which would place this in NETCONF) Kent Watsen: seems to be partial overlap with FSM work. Need continuing discussions. TBD Igor Bryskin: doesn't feel like there is lots of overlap Kent Watsen: continuing discussions should happen here Interest from room: (a 'reasonable' number of hands)