Minutes IETF113: netmod
minutes-113-netmod-00
Meeting Minutes | Network Modeling (netmod) WG | |
---|---|---|
Date and time | 2022-03-22 09:00 | |
Title | Minutes IETF113: netmod | |
State | Active | |
Other versions | plain text | |
Last updated | 2022-05-03 |
minutes-113-netmod-00
Draft Minutes inclusive of the agenda. # 1) Introduction Chairs (10 minutes) Session Intro & WG Status Charles Eckel In-room cooordinator. Lou Berger speaking for intro Mahesh Jethanandani: I will work with Rob on his (ethernet) documents. # Chartered items: ## YANG Versioning Update (45 min) ### 2) Title: YANG Versioning Update - Overview https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-05 Discussion Leader: Joe Clarke :09 Joe Clarke speaking Lou Berger - based on the update we'll decide if there needs to be a second last call. No questions. ### 3) Title: Yang Packages https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-03 Discussion Leader: Jan Lindblad :21 Jan Lindblad speaking Charles Eckel: how do you envision -bis versions working? When changes look like a deviation. Jan Lindblad: deviations is not a way to communicate version changes. An update is just a BC or NBC version update. Slide 9: (API vs Implementation packages) Lou Berger asks if the question regards the concept or realization. Jan Lindblad: concept Benoit Claise: I can see how the implementation option would be most useful. Let's see if it gets used before spending too much time on it. (:38) Tom Hill: exatly the opposite of Benoit I prefer API package so I can tell what they support across vendors. Lou Berger (as contributor): Agree with Tom that from a provider/user perspective would like to specify what is desired (via API packages) and then have vendors state what they support via an implementation package. Scott Mansfield: (from chat) Was the point about listing conformance as part of the package? Benoit Claise: Going back to slide 8, API says what user/customer wants; the implementation package says what the vendor is doing. Is this the right way do represent this? Tom Hill: it doesn't help if vendors use different APIs, need to be more proscriptive. Rather than query router "what can you do?", I want to say "do this". Rob Wilton (contributor): API package is giving the specification, Implementation package says what the server is doing. Jeff Haas: (missed it: 39) Would like to focus API package on dependencies. Balazs Lengyel: it would be nice if a tool would enable discovery of what API packages a module/package implements. Jan Lindblad: The question was really whether making a distinction between API and implementation packages is useful. I think we struck a cord here, based on all the discussions spurred. Clearly the distinction between API and implementation modules is a meaningful one to most people. Thank you. ## 4) Title: Self Describing Data Object Tags (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-06 Presenter: Qin Wu Qin Wu speaking: :53 Lou Berger (as contributor): On "Tag Managment Conflict Resolving" slide, not sure why tags are any different than any other rw information. So I don't believe there is any unique issue here. The text change is fine, but unneeded. Qin Wu: agree Rob Wilton (as contributor): The module uses NACMs:instance-identifier typedef which allows tags to either be for a specific data instance, or more generically cover multiple instances (e.g., all instances of an MTU leaf). I think that this is the right thing to do, but it might be helpful if there was some extra descriptive text to make this clear (if it isn't already there). Lou Berger: chairs will discuss Last Call after the meeting. Don't see any reason not to. # Non-Chartered items: ## 5) Title: System-Defined Configuration (15 min) https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system-02 Presenter: Qiufang Ma Quifang presenting (1:04) Kent Watsen: On Slide 2, perhaps the WG should discuss if we should support in <intended> first, not shy away from it just because there is a "when" expresssion somewhere, especially as the update to the "when" expresssion would because it expand the its scope and so wouldn't break existing models and we can decide if it's worthing updating the other rfc Rob Wilton (as a contributor): I have some concerns about whether running configuration should always be required to be complete, or whether an incomplete configuration should be mergable with system configuration before validation. An example is creating an interface with a default interface type - should a client always have to specify this, or can a server use a system value without injecting it into the running configuration? Balazs Lengyel: Some SDOs specifify what must be created by the system, so would be a problem if we restricted this in any way Jan Lindblad: would like to ensure that existing clients don't break (Quifang concurs). Balazs Lengyel: Jan Lindblad: Balazs Lengyel: it would kill 3GPP YANG modeling Jan Lindblad: Not at all. All you need to do is to make sure 3GPP clients and servers implement flags to control this. Balazs Lengyel: Jan Lindblad: Balazs Lengyel: Rob Wilton (contributor): do you think it there should be a parameter (like "resolve-system") to enable system-aware clients can ask the server pull-in whatever <system> config needed? Quifang Ma: yes, will present next. Balazs Lengyel (on Slide 4): this is a show-stopper Kent Watsen (contributor): this is a not approved approach, there was a vigorous discussion on the mailing list, the system can act like a client to avoid the server make changes. Lou Berger: there's no RFC that precludes something automatically; this would be a change in allowed behavior which we have to take into consideration Balazs Lengyel: (in chat, after meeting ended?) I don't seem to be able to modify the notes, so here are some comments also stated in voice:System:Balazs: Other SDOs like 3GPP and O-RAN are using system-created data nodes. Their design depends on them in some cases. Clients are not allowed to create these list entries. Until now the system is allowed to modify the running configuration. If we would prohibit this that would be a major non-backwards-comptible change. I object to that. It would also need a YANG 2.0 revision. Even if we would prohibit the system to modify running, it would be possible to work around it. The system instantiates an onboard client to do the changes AND the system prohibits the change for other clients. However this is just a more complicated way of stating that the system itself modifies running; we gain nothing but make the world more complicated. While I agree that system-created data nodes can be problematic sometimes it is a fact of life, so we should not remove it. ## 6) Title: Immutable Metadata Annotation (15 min) https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-00 Presenter: Qiufang Ma Qiufang presenting (1:32) Rob Wilton (contributor) on Slide 5, has concern if servers decide some things are immutable may break existing clients. Having a parameter is a better choice that always returning the data might be better. Having this is as annotation to indicate where immutable data exists, without encouraging it might be a good solution. Should also consider config-replace like operations. Jan Linblad: agrees with Rob, restirctions make life difficult for clients, but RFCs say already that rejection can happen already. Qiufang Ma (to Rob and Jan): not introduce new restriction, just want to make the information visible. Balazs Lengyel: Generally supports work. Some SDOs use invarient to represent a similar concept. Some use immuable rules to say once created, cannot be removed. Rob Wilton: shouldn't encourage? Balazs Lengyel: would like to agree Balazs Lengyal: sometimes "immutable" can be specified in schema (YANG), i.e., don't need annotation. Balazs Lengyel (in chat, after meeting ended?) Immutable:3 potential use-cases for immutable: - invariant: once a leaf is created it cannot be changed - capabilities that are created by the systems and client cannot modify them. Is this better served by immutable or system data? - Immutable NACM rules that must stay in place to protect some parts of the configuration from any modification ## 7) Title: Updated Common YANG Data Types for Traffic Engineering (10 min) https://datatracker.ietf.org/doc/html/draft-busi-teas-te-types-update-01 Presenter: Italo Busi Italo presenting (1:50) Jeff Hass (from meetecho chat)- I can expand at mic, but BFD has had a similar issue for RFC 9127-bis. Trivial change, painful process: https://datatracker.ietf.org/doc/html/draft-ietf-bfd-rfc9127-bis-02. Short form is process is too heavy weight. Mahesh Jethanandani: provides BFD-bis experience (importance of the problem). Rob Wilton (AD) could be a separate draft the "updates" this draft and only updating the specific module. Not supportive of putting diffs into the Apendix. Italo Busi: (missed it) Rob Wilton: could add a comment to RFC Editor and enables annecdotal text to be removed before publication. Jeff Haas: Some concern regarding how to handle other modules that "imports" the updated module. Issue being discussed on BFD list. Lou Berger (as chair): Rob gave solution. Separately, don't rely on tooling. done at 2:03 ### Note takers: JJ = joel jaeggli JS = Jürgen Schönwälder MJ = Mahesh Jethanandani