# Minutes for the NETMOD 118 WG Session {#minutes-for-the-netmod-118-wg-session} https://datatracker.ietf.org/meeting/118/materials/agenda-118-netmod https://datatracker.ietf.org/meeting/118/session/netmod ## Session: {#session} Tuesday, November 7, 2023 13:00-15:00 Prague (Central European Time) 12:00-14:00 UTC Room: Congress Hall 3 ## WG Chairs: {#wg-chairs} Lou Berger (lberger at labs dot net) Kent Watsen (kent plus ietf at watsen dot net) ## WG Secretary {#wg-secretary} Jason Sterne (jason dot sterne at nokia dot com) ## Session Information: {#session-information} Notes: https://notes.ietf.org/notes-ietf-118-netmod Slides: https://datatracker.ietf.org/meeting/118/session/netmod Zulip (chat): https://zulip.ietf.org/#narrow/stream/126-netmod/topic/ietf-118 Drafts (TGZ): https://datatracker.ietf.org/meeting/118/agenda/netmod-drafts.tgz Drafts (PDF): https://datatracker.ietf.org/meeting/118/agenda/netmod-drafts.pdf Datatracker: https://datatracker.ietf.org/group/netmod/about/ ICS: https://datatracker.ietf.org/meeting/118/session/31616.ics Recording: https://www.youtube.com/watch?v=IcVarlAhAdA https://play.conf.meetecho.com/Playout/?session=IETF118-NETMOD-20231107-1200 Jabber Logs: https://www.ietf.org/jabber/logs/netmod ## 1) Session Intro & WG Status (10 min) {#1-session-intro--wg-status-10-min} Presenter: Chairs ## Chartered items: {#chartered-items} ### 2) Common Interface Extension YANG Data Models, Sub-interface VLAN YANG Data Models (10 min) {#2-common-interface-extension-yang-data-models-sub-interface-vlan-yang-data-models-10-min} Presenter: Scott Mansfield Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang-12 Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model-09 Notes: Lou Berger: Please try to reolve the identified open issue on the list, and then we can move to last call both documents together. ### 3) System-defined Configuration (10 min) {#3--system-defined-configuration-10-min} Presenter: Qiufang Ma Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config-04 Notes: Kent Watsen: Mentioning that running must be valid but without specifying whether that means on the server or offline is a clever way of letting us move forward without getting stuck on the details. Maybe we need to separate into two parts? 1) long term theoretical whether running should be offline validatable alone vs 2) do we need to wait for YANG NEXT to change/clarify offline validity of running Rob Wilton: Let's have a dedicated interim. I don't think we can skirt this issue. Kent Watsen: Agree Rob Wilton: (re origin of system data copied into running) I'm not sure of the answer, but we should specify it. Kent Watsen: Origin is in operational only today, should we add it to running? The question of whether to upgrade (migrate) nodes in running may be connected to this issue of origin. Maybe upgrade migration only happens on nodes with certain origins in the running. Lou Berger: We should try and find a way of resolving the issues and scheduling an interim may help with that. ### 4) Extensions to the Access Control Lists (ACLs) YANG Model (5 min) {#4--extensions-to-the-access-control-lists-acls-yang-model-5-min} Presenters: Oscar Gonzalez de Dios Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-extensions-03 Notes: Rob Wilton: I don't have a strong preference on the 2 options, augment vs bis (just continue with what you have now) Mahesh Jethanandani: As author of ACL draft I prefer a bis Lou Berger: who read this? who thinks the current approach is good? who wants a bis? #### POLL 1: Who has read the draft? {#poll-1-who-has-read-the-draft} RESULT: about 1/4 of room #### POLL 2: If you read the draft, do you think it is ready for Last Call? {#poll-2-if-you-read-the-draft-do-you-think-it-is-ready-for-last-call} RESULT: most (all but 1) said yes Joe Clarke: Might want to use the base module without the augmentation. Bis would be more required if you need the new items as part of basic use of the module. Rob Wilton: If you do it as a bis, you can focus on the changes. Bis doesn't have to be particularly heavy although you can't really stop people from reading/commenting on the rest of the document. Lou Berger: I like the augmentation better (as individual). Lou Berger: The chairs will discuss off line and will likely proceed with last call. If you were the "no" for the doc being ready please send a note on the list. ### 5) YANG Versioning (45 min) {#5-yang-versioning-45-min} Presenters: Jan Lindblad and Joe Clarke Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-10 Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-12 Notes: #### Discussion of T7 (filename): {#discussion-of-t7-filename} Italo Busi: (re issue T7, filename) It is better to wait for next YANG version. Date is main identifier for now. It is a tag. Maybe in next version we should reverse and use the label. Avoid having 2 different ways to name the modules. Lou Berger: When do you think the next version would likely be? Italo Busi: Soon Lou Berger: YANG NEXT is going to take a while Italo Busi: That's OK Kent Watsen: I second Italo's comment entirely. When we switch to labels that should be the only way to do it. Per Andersson: I did a hackathon to add a label to the filename in pyang. It was pretty easy actually. I think we should do it now. Lou Berger: As contributor - I'm concerned about vendors doing their own thing. I'd rather have a format specified. #### Discussion of T8 (recommended-min): {#discussion-of-t8-recommended-min} Per Andersson: if not in order, produce a warning Kent Watsen: The word recommended isn't saying it has to be followed. If it less than recommended-min it is just a warning. In YANG NEXT we could make it more strict? Rob Wilton: We started with this being stricter. Got push back from the WG that changed YANG too much. So we softened it. Other opinions have been expressed that maybe dependency information should be outside the module (e.g. packages, library, etc). Branching adds some complexity. Kent Watsen: can't quite follow that - needs clarification offline. Lou Berger: There isn't a specific question on the slide. Jan Lindblad: We're split on this in the weekly call group. Lou Berger: Split with 2 camps or a lot of "not sure / don't care"? Rob Wilton: Some people think this is important. Others feel it is blocking the work. Lou Berger: so nobody is opposed? More about getting this work done. Rob Wilton: correct Kent Watsen: it seems like recommended-min is a compromise to allow it to go through. Rob Wilton: I think we'll end up with the same solution even if we delay this work. Jason Sterne: I echo what Kent said. This was weakened from a conformance statement to a recommended min to allow us to keep it in the work. I'm in favor. It is simply machine readable info for users or people constructing packages. * * * #### From the chat: {#from-the-chat} Balazs Lengyel: Import min is useful. Lets included it as a recommendation and warning. I agree with Ken. Joe Clarke: I, too, am in support of some kind of min signaling. I was more in favor of strength, but I can live with the warning in 1.1. Balazs Lengyel: Not needed as backwards compatibility is not even defined for instance data. Per Andersson: Keeping it as a warning and not enforcing would give implementors freedom to use compatible models if they know what they are doing and can ensure compatibility. Per Andersson: recommended-min I mean Joe Clarke: Yep. I think it's good to keep. Rob Wilton: @Kent, I see the reason for softening the import min-rev text for 3 reasons: (1) Because it is better to keep strict conformance out of YANG modules (i.e., put it into packages instead) (2) Because there are cases (with a branched history) where a different version of the file is valid, but would fail a strict min-rev check. (3) To get the work done (which was a lowest priority) Per Andersson: It adds value with recommended-min right away also, letting module authors signal to implementors how to use and what to expect Lou Berger: would really prefer (non) compatible was in metadata, but can live with plan Rob Wilton: non-compatible is also in meta-data as the extension statement Lou Berger: okay, sure... * * * #### POLL: WRT T8: Is min need now? YES=keep, NO=Defer to YANG next. {#poll-wrt-t8-is-min-need-now-yeskeep-nodefer-to-yang-next} RESULT: split with a slight leaning towards yes. #### POLL: WRT T8: Is recommended min need now? YES=keep, NO=Defer to YANG next. {#poll-wrt-t8-is-recommended-min-need-now-yeskeep-nodefer-to-yang-next} RESULT: Same as immediately previous poll - split with a slight leaning towards yes. Lou Berger: Don't select yes for both polls. #### Discussion of T9 (instance data): {#discussion-of-t9-instance-data} Lou Berger: Can you live without this? #### POLL: T9: Can you live without versioning of instance data? {#poll-t9-can-you-live-without-versioning-of-instance-data} RESULT: not huge participation, but 100% say "yes" #### Discussion of T10 (insignificant whitespace): {#discussion-of-t10-insignificant-whitespace} Lou Berger: The other one that I'd like is "should whitespace be included in a checksum". Yes - you'd need a pre-processor. Rob Wilton: This is really the question: do we want to be able to do a checksum using plain text. Jason Sterne: on implication if we don't require it to be a separate version, is imagine an author publishes two versions with different whitespace (e.g. shrink line length), then there might be two copies of that version 3.0.0 floating around. We should bump the editorial version at least. Lou Berger: So it would not have a digit change - it would be the identical. Jan Lindblad: Two different modules with different checksums (if they include whitespaces), but it is the same module. Kent Watsen: We've never talked about checksums before. Is it so important? Jan Lindbald: Checksums are useful when versions are floating around to know exactly which one we're talking about. #### POLL: Should whitespace be considered for the revision label?c. {#poll-should-whitespace-be-considered-for-the-revision-labelc} RESULT: A good number of people answered with a 3:1 ratio preferring to ignore whitespace. Italo Busi: When I download YANG files from different sources, sometimes there is an extra line at the end and sometimes there isn't. It would be confusing if those are different versions. Joe Clarke: Jason mentioned versions "floating around". Jan mentioned wanting to know which one is the "right one". If I care that I have *the* canonical 3.0.1 and want to be able to go to the official source, then we need the revision to include the whitespace. Kent Watsen: If you were to use a canonical checksum where would it be published. Joe Clarke: Checksums.txt on the website where the Kent Watsen: Checksum-ver instead of yang semver. Balazs Lengyel: People aren't so precise and this newline at the end will cause confusion. I'm in favor of normalizing before doing a checksum. Reformatting a description is a significant change and outside the scope of this discussion. #### Discussion of items T1-T6: {#discussion-of-items-t1-t6} Lou Berger: Clarification: these were sent to the list as the decisions that have been made based on previous discussions. Lou Berger: Silence means "you can live with this". I don't necessarily agree with all of it, but I can live with it. #### Discussion of YANG Semver: {#discussion-of-yang-semver} Kent Watsen: If it says either of compatible or non\_compatible, then they still have to go to the revision history to understand the relationship. So why have the suffix. Joe Clarke: Correct. For lineage you have to look at history. But for a quick understanding of compatibility you can just use the YANG semver to know if you need to dig further. Kent Watsen: So it means some patch changes can break things and some don't? Joe Clarke: Yes - because we can't increment anything else at that point, so we add the modifier. Ramkumar Rajagopalan: Why do I need that "compatible" extension in the example? If there is no modifier it is compatible. Joe Clarke: To indicate it isn't just a patch change. The change includes some other BC changes (e.g. maybe a new leaf). Next step is for authors to update the drafts based on the discussion. ## Non-Chartered items: (went out of order) {#non-chartered-items-went-out-of-order} ### 8) Mounting YANG-Defined Information from Remote Datastores (10 min) {#8--mounting-yang-defined-information-from-remote-datastores-10-min} Draft: https://datatracker.ietf.org/doc/draft-clemm-netmod-peermount-00 Presenter: Alex Clemm Ladislav Lhotka: avoid the name "mount" or we'll introduce confusion Alex Clemm: This is different problem space. Schema mount is mounting locally. This is federated data, about mounting instances on a remote system Jason Sterne: How does this deal with absolute leafrefs and paths in "must" statements in the device models. Those won't make sense when viewed from the northbound side of the composed controller model. Alex Clemm: This isn't config so "must" statements don't matter Jason Sterne: I'll take this to the list to avoid taking the rest of the time Rob Wilton: I thought schema mount was supposed to handle this scenario Alex Clemm: That was alias mount and was different. I can see this is confusing. Lou Berger This is different. There are some similarities. We need to take this to the list Jan Lindblad: I read the draft and it is interesting, but there are many open unresolved issues. This is not simple. Ignacio Martinez-Casanueva: We have an alternative terminology to the mount term we could consider: data virtualization * * * #### From chat: {#from-chat} Balazs Lengyel: I would call it remote-mount Lou Berger: I agree - had the same comment Lou Berger: I see this as akin to html caching * * * ### 6) YANG Extension and Metadata Annotation for Immutable Flag (10 min) {#6--yang-extension-and-metadata-annotation-for-immutable-flag-10-min} Presenter: Qiufang Ma Draft: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag-09 Balazs Lengyel: I'm concerned with the removal of the extension. 3GPP has nodes where it is known at design time that they are immutable. 3GPP will likely have to create their own extension since the IETF is rejecting this need. Rob Wilton: This WG should send a reply back to the 3GPP liaison statement. Maybe we should rename it as "system config" instead of "immutable"? One question, if a client writes to running, can a delete request of that same data ever fail? Qiufang Ma: If same value, you can add into running and can be deleted Kent Watsen: Conversely, if you can't add it to running, you can't delete it from running Rob Wilton: Fine, but it isn't that a client can add something to running, and then the system says "fine, now that is locked and you can never change it"? Lou Berger: Isn't that the extension that was removed? Rob Wilton: I thought the extension was just statically declaring this Kent Watsen: Immutability isn't dependant on any client interaction, it is purely server-defined Italo Busi: 3GPP needs this extension but also other SDOs. It is better to have one solution from IETF rather than each SDO doing their own thing. Lou Berger: 3GPP came to us to help them solve a problem (instead of just taking what we have and changing it). I think it would be good for us as a group to do that instead of telling them to do that in their standard body. Jan Lindblad: I think the contention here is really what immutable means. Some concepts from 3GPP may not be compatible with YANG but there may be a way to achieve the basic needs. Balazs Lengyel: If you have the info at design time that a schema node is always immutable, why not show that in the model rather than waiting for that info in an annotation at run time? * * * #### From chat: {#from-chat-1} Rob Wilton: @Balazs, why is the data immutable. Rather than labelling it as immutable, pehaps we can label it with what it is (e.g., perhaps it is device capabilities) and infer from that the configuration is immutable. Lou Berger: or use a tag Balazs Lengyel: @ Lou, Robert: The basic is to provide the information in design time bit runtime. I as I understand tag is only available in runtime. Balazs Lengyel: @immutable: I can live with a different name instead of immutable. The name is not so important. Lou Berger: see section 3 of 8819 - tags are available at design time * * * ### 7) A YANG Data Model for Interface Reference Topology (10 min) {#7--a-yang-data-model-for-interface-reference-topology-10-min} Draft: https://datatracker.ietf.org/doc/draft-ietf-ccamp-if-ref-topo-yang-01 Presenter: Scott Mansfield Olga Havel: Thanks Scott, I was thinking this same thing when I saw the draft. Kent Watsen: (as chair) Our understanding is there is a new "inventory" WG that deals with things like topology. Might that be the right place? NETMOD is a catch all if there isn't another group. Qiufang Ma: IVY \[Inventory WG\] is the new WG and it may be a place for this work. Rob Wilton: I will help find the right home. Bo Wu: I notice model is a network model, but adding an interface name as a leafref. Kent Watsen: Sorry Bo, but we're out of time for a question like that now. Please take it to the list. ### 9) Model Driven Telemetry integrating YANG with Time Series Databases (10 min) {#9--model-driven-telemetry-integrating-yang-with-time-series-databases-10-min} Draft: https://datatracker.ietf.org/doc/draft-kll-yang-label-tsdb-00 Draft: https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist-00 Presenter: Jan Lindblad Kent Watsen: Which parts of this work should be in which WG? Maybe splitting the work? Jan Lindblad: Maybe the mapping part in NETCONF and the framework part in NETMOD?