Minutes for NETMOD WG Sessions at IETF 96 (Berlin) ================================================== Session 1: MONDAY, July 18, 2016 1540-1740 Afternoon Session II Room: Schoeneberg Video: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_NETCONF&chapter=chapter_1 Audio: https://www.ietf.org/audio/ietf96/ietf96-schoeneberg-20160718-1540.mp3 Session 2: TUESDAY, July 19, 2016 1620-1820 Afternoon Session II Room: Tiergarten Video: https://www.youtube.com/watch?v=lp_NrYAQT10 Audio: https://www.ietf.org/audio/ietf96/ietf96-tiergarten-20160719-1620_04.mp3 Session 1: (Monday 2-hours) =========================== * 10 Min: #0 Intro & WG Status (Chairs) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-0.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-0.pdf Benoit Claise presenting: Been working on yang 1.1. ietf-library. opstate. We have been working on the opstate document. Difference between intended and applied. "Solved" in yang module design. Discussing revised datastore concepts. Issue in this SDO is we don't publish the work as RFCs fast enough. We've been waiting on opstate (document) No explicit support to support applied configuration. What do we do with counters? -state or not. Should not leave room until we have guidelines for all of IETF. This is a primary achievement for today. What do we do with counters - into state or an open branch? Open issue. Shouldn't leave room until we get guidance to give the rest of IETF.This is a primary achievement for today. # of yang modules in RFCs. We're hitting an inflection point. Need to have in a year from now many modules in RFC. If not, Should just stop doing yang modules in ietf - if we don't publish them as RFCs. Declare victory on protocols and encodings; it'd happen elsewhere if we didn't. Timelines (where we should spend our resources): - schema mount down as fast as possible. - Need solution by the next IETF. (this is 2nd highest priority) - Must also progress ietf rtg module. 40 different modules depending on that. - Progress all yang models that do not depend on mount. Q&A for Benoit: Rob Shakir: Push out all those RFCs. From user perspective, do they work together? We need to be able to interact and configure things. Would be happier with a few RFCs that work together. Benoit Claise: Changed procedure with yang doctors. Asking all chairs in ietf to proactively review modules; should be working together. Primary place this needs to be fixed is routing. That's what the RT design team is for. Find it unlikely we'll have perfect data models on day 1. Must think about how we iterate the models. Rob Shakir: need to focus on versioning and how things work together (e.g. model-catalog). From OC modules, we're about to hit v3. Making backward *in*compatible issues on a regular basis. Benoit Claise: We've been receiving yang modules from other places. Michael Abrahamsson: Trying to reconcile among 4 vendors what the common elements are to go into a model. As a vendor want to standard models that can map to many vendors equipment. Lou Berger: Important and helpful for users to stand up to say what belongs in the model. Dean Bogdanovic: We should be classifying modules and not models. Can be classified many different ways in models. If we focus on modules, it'll be clearer. Andy Bierman: Wrote a yang conformance document. Unit of conformance of a module isn't that useful. Want to identify modules that work together. Need to rethink rather ... conformance model in yang? Especially when we're not following the rules. His concept of yang pakcages of things known to work together. Thus you can move to things that need to change all together. Ladislav Lhotka: Been pushing progress in rtg modules for a while. Now that yang 1.1 is looming, do we want to change existing modules to conform to 1.1, or do we stick with 1.0 for these modules? Benoit Claise: What do operators in room think? Dean Bogdanovic: Last time we discussed this and agreed that drafts not in pub queue should move to 1.1 Benoit Claise: This is what I remember as well. Ladislav Lhotka: If we're trying to publish stuff asap, then moving to 1.1 may further delay things. Benoit Claise: confused, because I thought we discussed this Lou Berger: Expected you (BC) to say that we took this decision before and that YANG doctors will enforce it (all YANG modules to now be 1.1) Benoit Claise: Thought this was already decided. Ladislav Lhotka: Expect moving to 1.1 will likely break the checking tools we have deployed. Benoit Claise: first, we already check 1.1. If there's a tooling issue, that's a different issue than the modules Ladislav Lhotka: Conclusion go for 1.1. Andy Bierman: We previously said we wouldn't upgrade module, just the version. Lada is asking about 1.1 language features. We're keeping yang 1.0 as current RFC. (6020bis doesn't obsolete 6020) Benoit Claise: let's check the minutes from 95 Andy Bierman: sounds new to me... Rob Shakir: sounds like a tooling issue, agrees with Andy Benoit Claise: how does this impact your tooling? Rob Shakir: there is an impact to developing a 1.1 ingest tool Lou Berger: Should have some off and on-list discussion about this and specifically include the yang doctors. Benoit Claise: I want the guidelines *today*. Lou Berger: From the checking tool standpoint, should be easy to upgrade the modules, issue is breaking the tools. Benoit Claise: If I'm not using 1.1 features, do I need to bump the version? Ladislav Lhotka: One of the things that should be added/changed is the use of xpath. Right now we utilize the textual comparison in xpath. If we provide changes, we may break things. Lou Berger: Ask users of models: (customers) Who objects to yang 1.1? ... how many people didn't understand question? Chris Hopps: The problem with the question is, what does this imply? Whatever gets it out there the fastest is important. Dean Bogdanovic: Is the requirement to move everything to 1.1, or is there a choice? Lou Berger: Requirement to 1.1 even if you didn't need this as a feature. Andy Bierman: Do you think you're going to get more mature tools from rfc that's been out for 4 years or something in I-D state? There are plenty of things that are in 1.1 you shouldn't barf on. Lou Berger: Vendors, Same question (who objects to to yang 1.1?) Dean Bogdanovic: If you have something already implement to 1.0, leave it to 1.0. In yocta draft, Had to move one thing because it needed 1.1. In that case it made sense. Rob Shakir: Can you ask how many people are implementing (lot of hands raised...) Lou Berger: Thinks Dean has a good way forward, if you hve a model that needs 1.1 feature, go ahead an use it. Also ok to stay and 1.0. Kent Watsen: Also Andy's point as well. Lou Berger: see a nod of "yes" from AD Vladimir Vassilev: 1.1 to 1.2, will be same question? Lou Berger: We have that issue whenever we rev techs. Kent Watsen: If there's a feature in 1.2 you want to use, go for it. Otherwise you'd stay at whatever the current draft has. Juergen Schoenwaelder: Would like to add that yang doctors should push modules to take advantage of YANG 1.1 features, if they see a yang module that would benefit from 1.1. Phil Shafer: If you have important modules that use 1.0, and you have to support it, changes will force you to cascade your upgrades. Kent Watsen: so the need to update to 1.1 will quickly cascade, good point. * 5 Min: #1 OpState direction recap (Chairs) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-1.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-1.pdf Lou Berger: assumption that modules will adopt the 7223 approach (e.g. interfaces-state). If that's not the case, please bring it up on the list Benoit Claise: We should not leave room until we have agreement where to put the counters. Lou Berger: Would like to move 6987bis to last call. Believe it reflects consensus. Does anyone believe that 6087bis does not reflect their position? Chris Hopps: This seems severe, that we can't leave the room until this is settled. Don't think this should be a blocker. Module consumers can determine how to consume each module based on its documentation, no set rule is needed. Think we're ready to move forward (standardize models in the IETF)/ continue to work on things in IETF. Lou Berger: Don't want to enforce this; leave it as a convention, and conventions can be broken Chris Hopps: Yes. Lou Berger: note the text says "SHOULD", so it is just a recommendation Rob Shakir: Where state is located is important. If models are sprinkled throughout model, it's an issue for people accessing it. For the record, don't think this is the right decision. We've been working on this for 18 months. We have running code. Back in Dallas, we'll let you know how it goes. I think this is a premature decision. Lou Berger: Objecting to direction from applied vs. intended. Rob Shakir: A bad decision would be to give no guidance. Rob Wilson: ... Is it worth asking this question again after we see the solution presentations? Lou Berger: okay * 10 Min: #2 draft-ietf-i2rs-ephemeral-state-14 (Susan Hares) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-2.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-2.pdf Susan Hares presenting "Yang Feature" slide: must be a way for yang schema nodes to be flagged as only for ephemeral state... Dean Bogdanovic: Writeable operational state is dangerous to dabble in. E.g. in OSPF. You should only be allowed to update the state for RIB entries that you put in (not state your peers put in), otherwise you'll be in a constant state of convergence. Kent Watsen: let's not debate I2RS requirements in this meeting, take it to the I2RS list... Andy Bierman: Problem with this wording. What does this new statement actually do? YANG only has config true and config false. Shouldn't this be only with the protocol? Susan Hares: need a way to say a certain model, or parts of a model are ephemeral only. Jeff Hass: it needs to be possible to indicate that some config=true nodes are ephemeral while other config=true nodes should not be allowed to be ephemeral. Lou Berger: Please ensure that the requirements to NETMOD include this phrasing of the requirement that Jeff just articulated. Susan Hares: Have solicited feedback multiple times from yang doctors to arrive at the text we have. Frustrating that this text isn't clear to this group. Please ensure that any update to this text is reviewed by all and only one answer is provided. * 15 Min: #3 draft-schoenw-netmod-revised-datastores-01 (Juergen Schoenwaelder) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-3.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-3.pdf Juergen Schoenwaelder presenting: need more architecetural guidance. Datastores are such a fundamental concept. Need separation between conceptual model and what protocols do. Dean Bogdanovic: do we all agree on the definitions and differences between intended and applied - Lou: yes, Juergen: no ;) Chris Hopps: is the issue with the definition of intended vs applied? Juergen Schoenwaelder: no the issue comes much earlier in the definition of configuration Lou Berger: would be worthwhile to understand better your proposal Mehmet Ersue: as netconf co-chair, agree with Juergen that the opstate solution is a fundamental arch concept. Would like the datastore discussion to move to NETCONF WG Benoit Claise: yes, there is NETCONF impact, but don't care where it happens, as the same people are going to work on it. Balazs Lengyel: interfaces/interfaces-state resolution much more important than the intended/applied resolution. Enabling operational DS to have same structure as running datastore greatly simplifies things; supports datastore based approaches over branches. Eric Voit: is ACL config or opstate when 802.1x(?) is in play? Juergen Schoenwaelder: I believe that ACLs can come from multiple sources. Eric Voit: so they could be operational state? (Juergen nods) Norm Strahle: What about CLI, is it covered by intended? Juergen Schoenwaelder: Ideally all access mechanisms (NETCONF, CLI, etc.), typically CLI is integrated Susan Hares: BGP passes control state as part of its protocol, is it control state or operational state? Juergen Schoenwaelder: I believe that it would target the operational state datastore. * 10 Min: #4 draft-wilton-netmod-refined-datastores-01 (Robert Wilton) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-4.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-4.pdf Robert Wilton presenting: Dean Bogdanovic: when do I get confirmation that might commit was applied? Robert Wilton: with current model, it's not defined Kent Watsen: opstate-reqs defined a/synch config operations Ladislav Lhotka: Where would actual MTU be represented (slide 7) Robert Wilton: In a model defined config false node Ladislav Lhotka: an extra data node Robert Wilton: yes, for the specific case on MTU Andy Bierman: Seems complicated interaction model to just indicate single bit (is the leaf applied). Are there more use-cases because, alternately, I could just ask the box if it's applied yet. Is there more use-cases than just this? Robert Wilton: no I don't think so [EDITOR: not true, telemetry needs this to] Dean Bogdanovic: would like to understand how to map the commit process in the protocol context Vladimir Vassilev: concur with Andy. It's solving a very narrow problem. Time to commit is one thing, but, for example, NTP may take time to resolve. This seems like a lot of complication, NETCONF/YANG used to be simple, now getting scary Robert Wilton: Applied configuration is intended to tell an operator exactly wheat the system is doing, as opposed to today where it's not clear Rob Shakir: a subscription system is more likely to just subscribe to the applied information, so is more than just one bit [EDITOR: yes, see comment above] Susan Hares: same q I asked Juergen, assume that there is an ACL that is configured, and BGP flow state, how do they interact in your solution? Robert Wilton: probably same answer as Juergen's (i.e. BGP is operational state) Eric Voit: same question about ACL and 802.1x Robert Wilton: same answer as Juergen's Rick Taylor: surprised that opstate datastore didn't already exist, so this work is long overdue Chris Hopps: diagram looks complex only because it is a complex topic, but when thinking about implementation, it doesn't seem so complex * 10 Min: #5 draft-wilton-netconf-opstate-metadata-00 (Robert Wilton) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-5.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-5.pdf Dean Bogdanovic: regarding there being a way to describe that a value has been overwritten by ephemeral, you will have a problem there with lawful intercept Robert Wilton: let's discuss offline Dean Bogdanovic: -- * 20 Min: #6 Open discussion on revised datastores (Open Mic) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-6.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-6.pdf Chairs: This block of time had to be clipped - folks should come to Wed's breakout opstate session * 20 Min: #7 draft-ietf-netmod-schema-mount-02 (Ladislav Lhotka) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-7.pdf Andy Bierman: Use case is a server that wants to compose structure out of multiple. Don't understand how this relates to standards, or to routig-cfg module Ladislav Lhotka: it's related because we changed the routing-instances approach to depend on a TBD schema-mount solution Andy Bierman: seems like a presentation issue, YANG tools don't care. Lou Berger: This is to support the shift in routing area and is used to support logical network element and network instance Kent Watsen: this is intended to be used by module-designers (this is not the same as peer-mount) Chris Hopps: Eric Voit: can peer-mount be built on top of this? Ladislav Lhotka: yes, that is what the slide says (the "is this what we want?" slide) Chris Hopps: regarding 2 slides back, what did you mean, only useful at on level? Ladislav Lhotka: not so easy for recursive issue (nested VMs) Chris Hopps: don't understand DSDL thing, does it presume you know what models will be there beforehand Ladislav Lhotka: yes Chris Hopps: that's a big problem Balazs Lengyel: need a way to do schema-mount in YANG module using programmatic statement (not description statement) Andy Bierman: regarding validation, I see many incorrect must and when statements. Sounds like this will make things even harder, less likely model designers will get it right Ladislav Lhotka: i don't believe this makes anything harder Chris Hopps: regarding anydata, does that mean anything goes, or is it restricted or a free-for-all Lou Berger: sorry, we're overtime, we have to take this offline Session 2:(Tuesday, 2-hours) ============================ * 5 Min: #0 Intro (Chairs) * 10 Min: #9 Routing Area DT Update (Christian Hopps) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-9.pdf Common Naming an issue Schema mount / opstate drafts followed/needed New idea of tagging modules/branches instead of containment hierarchies Lou Berger: Comments on hash tag idea? Dean Bogdanovic: hashtags might become a mess. Limit the number of htags. Small set of standard tags + rules for private tags Christian Hopps: Idea to keep them loosely coupled. Let it develop organically. Dean Bogdanovic: At least provide conventions, Classification draft might include htag rules Christian Hopps: We should decide if a good idea Rob Wilton: perhaps use a standard prefix Lou Berger: Agreed. I think that's already been mentioned, e.g., "IANA" (by Chris) Andy Bierman: Like the idea. Suggest having conventions to avoid all the possible permutations. Andy Bierman: htag nice idea, but rules needed otherwise rout/routing/routes Kent Watsen: perhaps the classifications could be namespaced? e.g., #ietf:, #: Dean Bogdanovic: As author of classifications, perhaps take this into account Lou Berger: Do you want this on the offline catalog or on the device to Christian Hopps: This was on the slide * 10 Min: #8 draft-ietf-netmod-routing-cfg (Acee Lindem) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-8.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-8.pdf Acee Lindem: Question should new applied state impact this document Lou Berger: We would like to move to LC, any reservations on LC? Dean Bogdanovic: Should move to LC. Lou Berger: How many have read this version How many have read any version Acee Lindem: Have two changes would like to discuss: Acee Lindem: Metric could actually use protocol specific extension, route tag and unequal cost multi path as features, can be an augmentation. Also need to make change in interface and next hop identification. Ladislav Lhotka: believes that we had route metric before, okay to move forward Lou Berger: Are there any reservations for moving forward with this document after the discussed changes are made Lou Berger: Once change is made, will LC on the mailing list. * 10 Min: #10 draft-ietf-netmod-acl-model-08 (Dean Bogdanovic) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-10.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-10.pdf Mahesh Jethanandani: did you address the YANG Doctors comments Dean Bogdanovic: yes Sam Aldrin: can a single rule cover both L2 and L3? Dean Bogdanovic: need to chain multiple matches. Other options were discussed in the WG and rejected. Elliot Lear: it was a factual question: if I read the model, it's a choice, correct? Dean Bogdanovic: yes Lou Berger: How many have read the latest version How many have read any number Any additional issues to discuss How many think the draft is ready for (another) last call Lou Berger: Will issue another LC * 10 Min: #11 draft-ietf-netmod-rfc6087bis (Andy Bierman) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-11.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-11.pdf Andy presents Updates/changes Code extraction Tools need to be improve to only extract parts Benoit Claise: agrees that need to cover case of examples in documents and have tools do the right thing (Slide 4) Kent Watsen: would it make sense to different between YANG examples vs instance document examples, so as to further facilitate draft validation? Andy Bierman: could do anything, but need to decide what is covered. Perhaps discuss on list. Andy Bierman: Andy Bierman: When to use YANG 1.1? Use when 1.1 features are needed now, but you MAY use 1.0 if you don't need them. Updating just to be current will be expensive. Rob Wilton: Is YANG 1.1. a MUST/SHOULD MAY Andy Bierman: MAY Rob Wilton: clarification. Mark the model as YANG 1.1 even though it does not use YANG 1.1 feature? Andy Bierman: yes, e.g., to support import of a 1.1 module's definitions Lou Berger: From yesterday, MAY is as strong as WG supports Lionel Morand: Marking the model as YANG 1.1 would mean that it complies with clarifications made in YANG 1.1 Andy Bierman: Perhaps worth adding more guidelines on when 1.1 is appropriate beyond syntax changes. E.g. string definition and imports Balazs Lengyel: (re: slide 7) Tool too weak to classify foo and foo-state. Andy Bierman: I'd much prefer having deterministic tags vs overloading names Rob Wilton: prefer it recommends one way rather than allowing choice Andy Bierman: not sure we have consensus on this, current text does not put a stake in the ground Kent Watkins: Should we drop the section (5.23) for now Lou Berger: we should be precise about terminology, and the title of the section doesn't match the title of the slide. Is the slide making a general statement on containers or something specific about operational data (e.g., counters) Andy Bierman: the latter. Information should be contained based on information lifetime. E.g., the number of times an ACL is accessed (matched) should be stored with the ACL. If/if-state is also based on pre-provisioning and it may not be the answer for everything. Like the suggestion that opstate handle that (this) Juergen Schoenwaelder: would like to keep the text in, even if it is week. We make them aware of the problem. Kent Watsen: you mean that it lays out the options and background around why they might matter Lou Berger: but that isn't a guideline Rob Shakir: It is, having a common convention is useful Benoit Claise: don't want to delay guideline. As contributor, need to get the tooling right. Juergen Schoenwaelder: would like a slight modification, i.e., show relationship between trees, even if using same hierarchy. Balazs Lengyel: require identical hierarchy / tree structure. Benoit Claise: whatever works with tooling Lou Berger: current text uses description at times to provide relationships, does this match tooling requirement Andy Bierman: We can make the text state that same tree structure is recommended Rob Shakir: Please do. Benoit Claise: we have the guideline the not model the applied in the tree, do we need to say this too? Andy Bierman: opstate/applied state is a different topic. Lou Berger: Suggest this isn't the right document for the recommendation on modeling applied state. Benoit Claise: We will have a wiki for YANG doctors, but this isn't the right place for this Lou Berger: if putting into Wiki is not sufficient, can you propose text? Benoit Claise: yes Lou Berger: Changes have been discussed in slides and discussion. Are there any other changes left (pending)? Andy Bierman: No. Lou Berger: How many have read this version How many have ready any version Are there any technical objections that have not yet been raised/discussed Lou Berger: Wait till we have updated draft and then we can go to LC. * 10 Min: #12 draft-ietf-netmod-intf-ext-yang-01 (Robert Wilton) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-12.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-12.pdf Dan Romascanu: ieee proposed to do this draft. it configures ieee functions. Work is right, but close cooperation needed with ieee (wrt ensuring we don't break IEEE rules) Tim Carey: Is there divergence between this draft and IEEE and BBF, and current Robert Wilton: Yes, IEEE is more limited and BBF is wider scope, trying to understand and cover both in parallel Anton ? (Brocade): Why using 802.1Q and not AD and why limiting tag length to two Lou Berger: (overtime) please discuss on list * 10 Min: #13 draft-ietf-netmod-model-entity-01 (Andy Bierman) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-13.pdf Kent Watsen: BBF depending on this module, articulated a willingness to become more involved Balazs Lengyel: if we put notifications all over the place, we loss important features. (e.g., dampening) Should reuse not redefine. Andy Bierman: that's right, notifications may fall out for free. Dan Romascanu: The conformance related section needs edits Dan Romascanu: Again, sees this as pieces being replicated in a proprietary way as well as in other SDOs. So us useful. Kent Watsen: Need another rev before LC Lou Berger: Do you have an ETA? Andy Bierman: Update in ~ 3 weeks * 10 Min: #15 draft-ietf-netmod-yang-model-classification (Carl Moberg) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-15.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-15.pdf Lou Berger: WRT SDOs, the IETF has formal relationships with other SDOs and organizations and we can leverage in the document definitions Dean Bogdanovic: Could use this draft as foundation for Chris'/Rtg DT (#tags) discussed earlier Rob Wilton: Are Openconfig standard models? Carl Moberg: Open source organization Lou Berger: Do you have changes planned Carl Moberg: only small changes Dean Bogdanovic: We could add hashtags to this Carl Moberg: or handle in separate draft Lou Berger: What changes are need for classifications/hashtags Dean Bogdanovic: Don't yet know Lou Berger: come back with a proposal for classifications/hashtags Lou Berger: Are there any objections that haven't been discussed How read version? How read some version? * 10 Min: #14 draft-ietf-netmod-syslog-model-09 (Clyde Wildes/ Mahesh Jethanandani presenting) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-14.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-14.pdf Mahesh Jethanandani presents Kent Watsen: is this blocked by TLS client Mahesh Jethanandani: Yes (Clyde confirms via Jabber) Lou Berger: Question to Clyde, are there changes to this document that are likely based on changes to TLS document? Clyde Wildes: via Jabber, probably not Lou Berger: Should the document progress and be blocked by reference Mahesh Jethanandani: Yes Kent Watsen: TLS client is too immature yet Juergen Schoenwaelde: If the document is blocked, what does it matter where its blocked Lou Berger: in general, its better to progress the draft once the WG 's work on it is done to allow publication process to occur Juergen Schoenwaelder: as assigned YANG Doctor, will review in the next couple weeks Lou Berger: Chairs will discuss whether to wait for reference or run LC process and have document sit in REF WAIT state. In general its better to progress the draft * 10 Min: #16 draft-openconfig-netmod-model-catalog (Rob Shakir) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-16.pdf Andy Bierman: this is very similar to my yang-packages from long ago Andy Bierman: is this meant to be read from device or offline? Rob Shakir: offline Andy Bierman: like RPMs, needed for the next generation compliance. What would work together can not be contained in a module Kent Watsen: if offline, does it make sense for the IETF to standardize it? Rob Shakir: could be something else Benoit Claise: in favor of it being in the IETF Balazs Lengyel: also in favor of describing how modules work together Lou Berger: who thinks this functionality is important (a good number) Lou Berger: who thinks this WG should work on it? (basically the same) Lou Berger: Chairs will talk re WG adoption/next steps * 10 Min: #17 draft-asechoud-netmod-qos (Norm Strahle) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-17.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-17.pdf Overlap with draft in routing area, cooperating Work is likely to be move to RTG or TSV Kent Watsen: Followup presentation in RTG WG. (for those who are interested.) * 10 Min: #18 draft-agv-netmod-yang-compiler-metadata (Vinod Kumar S and Gaurav Agrawal) draft-agv-netmod-yang-annotation-ds-and-derived slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-18.pdf * 10 Min: #19 draft-sharma-netmod-fault-model-00 (Anurag Sharma) slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-19.pptx slides: https://www.ietf.org/proceedings/96/slides/slides-96-netmod-19.pdf Dan Romascanu: coauthor of RFC3877 where we reused ITU definitions Carl Moberg: is the IETF the right place for this? concern regarding taking source data from other SDOs (e.g., XL33) Anurag Sharma: this is pulling from and building on RFC3877 Dan Romascanu: as author of that RFC, this is good and external references are okay Alex Clemm: how different from alarms Carl Moberg: there was some prior work that you should look at if interested in earlier work Anurag Sharma: yes, let's talk Balazs Lengyel: if we do work, should be based on x733 Lou Berger: if we do this work, should be consistent across data planes Anurag Sharma: yes