Key Decisions (by draft) ======================== draft-ietf-netmod-yang-data-ext-01 - issue 1 move forward with the proposal on the slide - issue 2 proposal on slide (rob will comment on list) - confirm on list draft-lengyel-netmod-yang-instance-data-05 - move detailed use cases to appendix. draft-kwatsen-netmod-artwork-folding-08 - source code begin / end code to be confirmed on list draft-ietf-netmod-nmda-diff-00 - Milestone try to do the optimal (come up with the best format) as opposed to just using yang patch, and have one format from the outset. (targeted at 104) draft-wu-netmod-factory-default-01 - Poll for adoption as a WG item draft-ietf-netmod-module-tags-03 - Additional last call not required / confirm on list - Requested addition of an example draft-verdt-netmod-yang-versioning-reqs-01 - Poll for adoption after best effort at a description of the requirements draft-verdt-netmod-yang-solutions-00 - Lou writeup for Modified-Semver Minutes ======= Session 1 TUESDAY, November 6, 2018 0900-1100 Morning Session I Chitlada 2 Recording https://www.youtube.com/watch?v=TQrHqpvkC90 # Start Time Information 1 9:00 10 Title: Intro, Charter & WG Status Presenter: Chairs Draft: N/A 2 9:10 10 Title: Common Interface Extension YANG Data Models, Sub-interface VLAN YANG Data Models Presenter: Rob Wilton? Draft: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang-06 https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04 Lou Berger - We talked about formalizing the liaison with the IEEE - should we do that? Rob Wilton - Informal is fine with 802.1. Lou - You participate in the coordination meetings so you'll bring that up? Rob - Yes at various stages Rob - draft-ietf-netmod-intf-ext-yang is ready for last call Lou - Has the l2 vpn draft been raised with the bess group? Rob - IEEE is happy with current status. > 3 9:20 10 Title: YANG Data Extensions > Presenter: Kent Watsen > Draft: https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-01 Kent Watsen - Issue 1 We move forward with structure like on the slide (no objection) Issue 2 proposal is a large diverge from the main data structure requires updates to the zero touch model Rob - Does this make it not so nice to read? Kent - The instance document you get is probably identical. Lou - You can can augment the structure where before you could only augment the instance. Kent - Certainly with both of these we will confirm on list thank you. Reshad Rahman - If you don't have the outer container how do you have context? Kent - Really just have top level name structure makes explicit the RFC 8040 description statement > 4 9:30 15 Title: YANG Based Instance Data Files Format > Presenter: Balazs Lengyel > Draft: https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-05 Lada Lhotka - Not necessary to provide more use cases, indisputable that instance data needs to be represented. Balazs Lengyel - Will look into shortening that. Lada - Can have standalone instance data that does not belong to any server, Balazs - What do you mean by standalone? Lada - Just some data that I need to validate. Mahesh Jethanandani - I agree with Lada that we don't been more examples but be do need to know where it can be used. Lada - In some cases you have both. Balaz - In some cases you can have partial datasets. Open issues Kent - How who you do that (indicate which revision is used) Rob - You shouldn't have to have extra metadata in order to be able to parse an instance datafile. Balazs - You can write your instance data for all features supports. Compatible, ignoring of that additional data will work. Rob - Move the detailed use cases to an appendix, if you write a draft about server capabilities it will conflict with this draft Balazs - I can make it shorter. > 5 9:45 10 Title: Handling Long Lines in Artwork in Internet-Drafts and RFCs > Presenter: Adrian Farrel > Draft: https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding-08 Rob - There's no marker at the end of the folded data. Adrian - In the source you hit the ned of the artwork tag. Kent - We kept it (end marker) out of scope. If you look at plain text we don't support. Adrian - Disagree with two of the chairs. Kent - Source code tag would add begin and code end code. > 6 9:55 15 Title: Comparison of NMDA Datastores > Presenter: Alex Clemm > Draft: https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-00 Lada - What you mean by encoding? Alexander Clemm - The diff format. Lada - Use a different word to describe the encoding to avoid confusion with xml/json. Lou - Generally - we avoid options that are not strictly necessary. Alex - This proposed to use the yang patch format. Kent - Not sure extending is preferable, to extending yang patch. We don't have consensus on that yet Alex - Third case is don't define multiple formats but keep the hook that allows people to define their own. Lada - There are some advantages to permitting different formats. Otherwise will have to wait for those diff formats to exist Kent - I agree the diff format that we select may not be optimal. Lada - We have been discussing a staging repository for which this diff format could be used. what I heard Kent suggest is that we try to come up with a good format and if that doesn't work then fall back. Opposed to saying here's you mandatory format, and then saying do whatever you want later. Joel - sounds like we have a milestone with 104 Christian Hopps - If we find the ideal format what do we do? Lou - Not a fan of building the leaf for future items Rob - Add in filtering by origin metadata on the input (clarification)? > 7 10:10 10 Title: Smart Filters for Push Updates > Presenter: Alex Clemm > Draft: https://tools.ietf.org/html/draft-clemm-netmod-push-smart-filters-01 Michael Wang - do you need to define a more generic method, not just yang push? Alex - should we define filter like average that goes yang push would not go there outside of the scope Lou - How many people have read? (a few) Rob - Question as to where this should be pursued ? - Would you implement these filters everywhere? Alex - On top of yang push? > 8 10:20 10 Title: A YANG Data model for Event Management > Presenter: Michael Wang > Draft: https://tools.ietf.org/html/draft-wwx-netmod-event-yang-00 Lou - Suggest that you work with the authors of the other drafts to coordinate. Alex - Action and notification is not necessarily the same. > 9 10:30 10 Title: NMDA Base Notification for Applied Intended Configuration > Presenter: Qin Wu > Draft: https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-00 Qin Wu - Discussion of draft is moving to NETMOD has been discussed before. Kent - Where is the intended application to get sent? Qin - Last one is sent after applied operation. Kent - Useful for any clients that did not initiate toe commit Rob - I didn't understand why there are to notifications for the end of the event Qin - Originally had a single event. Rob - Best to have one event, with success or failure. Kent - Could simply call it intended, updated. Lou - How many have ready the draft? (a few) not sure their is commonality with the other two draft > 10 10:40 10 Title: Factory Default Setting > Presenter: Qin Wu > Draft: https://tools.ietf.org/html/draft-wu-netmod-factory-default-01 Qin - Also move from netconf to netmod Rob - Useful to talk about copy config RPC (can also use this) Qin - Was looking to make this transport independent Rob - yeah document Balazs - Doesn't work because target is required (requires NMDA) Kent - RPC reset factory - Should be described as different then reseting to factory default Lou - how many people who are interested? ( lots ) How many people have read it? (fewer but a few) How many people to we should adopt this as the starting point for our work in this area? (quite a few) none opposed > 11 10:50 10 Title: BBF YANG Update > Presenter: William Lupton > Draft: N/A William Lupton - Members contributing to IETF alarms work in CCAMP members contributing to IPFIX work still need to stick to the old non-NMDA RFCs as our base Lou - Appreciate the update (end of the meeting) > Session 2: > THURSDAY, November 8, 2018 > 1610-1810 Afternoon Session II > Chitlada 2 > Audio stream: http://ietf103streaming.dnsalias.net/ietf/ietf1035.m3u > > Presentation Start Time Duration Information > 1 16:10 10 Title: Intro > Presenter: Chairs > Draft: Lou - commencing / note well agenda module tags versioning requirements yang versioning potential solutions > 12 16:20 20 Title: YANG Module Tags > Presenter: Chris Hopps > Draft: https://tools.ietf.org/html/draft-ietf-netmod-module-tags-03 Chris Presenting Kent Watsen - would it make sense to call it "recommended-module-tags"? Lou Berger - predefined sounds pretty good Joel Jaeggli - How many have read this draft or previous version. A reasonable number. Are there any people who object to any of the changes made during the last call. There are none. I don't think that another last call is required. Kent - can we add an example Chris - what format would you like it in. Kent: xml/netconf or json/restconf is fine, just identify which is used. > 13 16:40 30 Title: YANG Versioning Requirements > Presenter: Joe Clarke (representing YANG Versioning DT) > Draft: https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-01 Joe Clark presenting Discussion on new requirement slide 1.4 Rob S - why is this phrased in terms of a single module needs to have this? Some versioning based on the union of all the modules. Made the problem statement very specific not in a useful way for operators. Joe - We recognize that our customers may want a bug fix that is not backwards compatible. We talked about deviations - this is to describe the requirement not the feature. Rob W - If you use a deviation you end losing? Rob S - We have that problem already with sets Why is this within a single module, you want to be a able to change a module Joe - The wording of this is there are multiple trains of software and there are customers have a need to make fixes in historical versions and have a way to identify those. (jabber) Martin Borklund - + 1 to Rob Shakir. Christian - Love the wording because it describes exactly what you want, and I don't want As an operator I'm screwed because you don't have a single train that I can build my tools on If you restricted major version changes to non-structural I'd by ok with it. would like to see some justifications in the form of changes that cannot be achieved with other mechanisms Joe - Would love to address to this with use cases. wording aside don't want to describe this as a solution. there could be a number of ways to solve this limiting branching null-pointer dereference is not going to require a module change Lou - you also want to solve the user problem? Joe - and we want to solve the user problem Reshad - if you (Chris) there is never a reason to do a change this then we're done. Rob W - Goal is to address for bug fixes Rob S - perhaps a go thing to do is to explain the release problem because that's the set of modules problem/lets stop making crap decisions about how to fork our software. Joe - Agree we talked about compatibility shims from a solutions standpoint. Rob S - Lets write those down then. Balazs - The operators come to us and say I don't want to upgrade the module path the old one. Rob S - Don't make it my problem please. Rob W / Rob S - Module deviations / is a way of handling bug fixes in old modules. Rob S - When we started the versioning was the only problem. Chris - import by revision Lou - Get a definition of a bug fix. Joe - If you don't like software release trains, you won't like that conversation. Rob S - What vendors do anyway should not be endorsed by the IETF. Lou - Perhaps we should document what we're prepared to agree and disagree on? Next slide discussion on req 3.1 / 3.2 Rob S - Need to support this kind of module filtering anyway / added GNMI specifically to handle this. christian - Used to for example embed version numbers in sysctl(s). Joe - We thought until about 10 minutes ago, that the requirements are complete. There is clearly some more work to be done. Joe - if we don't have to come up a with a formal definition of a bug fix Christian - May have to be a dissenter. Rob S - I think we should remove the entire second sentence (from 1.4). The cost you're avoiding is the cost the operator already has to pay. Kent - Needs rewriting. Mikael Abrahamsson - Agrees with Rob Shakir. Rob S - So you have to support more than one version of the module? have to support this combination - solution be entirely outside this problem space Tim Carey - ??? Joe - would remove this first sentence Tim - why would you ever mean the first sentence Rob S - oct 2015 catalog registry for yang modules draft we tried to describe it there Rob S - There are Joe - Asking for adoption of the requirements is premature. Lou - Would like you best effort at a description and then we can poll for adoption mark it as that. It is still under review? Lou - how many people think that would be a suitable foundation for adoption Rob S - will post an adoption comment (lots of hands a good number of people.) > 14 17:10 50 Title: YANG Versioning Potential Solutions > Presenter: Rob Wilton (representing YANG Versioning DT) > Draft: https://tools.ietf.org/html/draft-verdt-netmod-yang-solutions-00 Rob Wilton presenting Christian - Is this slide log scale? The solution space should be weighted towards the users. Lou - Does your evaluation cover all the requirements? Rob W - No this is a subset. Lou - But, we won't have a full solution until all the requirements are met. Christian - Why would you apply a fix on 1.0 but not 1.1? rob W - You wouldn't You're using deviations to take it down to a different version. Rob S - You can always publish a module which can only augment a previous one. Rob W - Benefits of semver are quite clear. Rob S - What happens when I make a second backwards incompatible change? Joe - talked about versions of this that would add a lot more complexity (slide modified semver) Rob S - This tells you what kind of change got made. What do I do about that? We tried to do something like this; Sure it's an indicator of what you have to do, but it's not sufficient Eliot Lear - option 5 - do nothing Rob S - deprecated nodes should still be supported? what does that mean? ? (Ericisson) - don't agree with bullet 2 Rob S - the problem is unavoidable because we have no system that relies solely on yang for interaction? Rob W - Modified semver is the current front runner Import by version... Christian - Client backwards compatibility - not fully explored Lou - On hook for a writeup Benoit Claise - Not all of have the luxury to start from scratch with models - I wish the IETF would produce some of those modules. It doesn't work that way at least for the vendors. Maybe what we could do is pretend this is a native modeling issue Document that in whatever way we can. Rob S - Would like to see that you can solve it with regular semver plus deviations. Christian - I think we understand you have issues to solve or that you definitely can't solve them in the IETF. It a question of whether that should be in the requirements. Rob W - Does the room feel like we're going in the right direction raise a hand? Balazs - Ask a different question. Lou - Until you start hitting the harder requirements I have trouble deciding to early. continue on, don't abandon the hard problems. Charles Eckel - Is semver or modified semver the right way forward? Rob S - very happy with semver? Wider solution is how problem space entirely works (end of the meeting)