# Notes for the NETMOD 116 WG Session {#notes-for-the-netmod-116-wg-session} https://datatracker.ietf.org/meeting/116/materials/agenda-116-netmod https://datatracker.ietf.org/meeting/116/session/netmod ## Session: {#session} Friday 2023-03-31 09:30-11:30 JST (00:30 - 02:30 UTC) Room: 4th floor, G412-G413 ## 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) ## Available During Session: {#available-during-session} MeetEcho: https://meetings.conf.meetecho.com/ietf116/?group=netmod&short=netmod&item=1 Onsite tool: https://meetings.conf.meetecho.com/onsite116/?group=netmod&short=netmod&item=1 Audio Only: https://mp3.conf.meetecho.com/ietf116/netmod/1.m3u Zulip: https://zulip.ietf.org/#narrow/stream/netmod ## Available During and After Session: {#available-during-and-after-session} Notes: https://notes.ietf.org/notes-ietf-116-netmod#both Slides: https://datatracker.ietf.org/meeting/116/session/netmod Drafts (TGZ): https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.tgz Drafts (PDF): https://datatracker.ietf.org/meeting/116/agenda/netmod-drafts.pdf Datatracker: https://datatracker.ietf.org/group/netmod/about/ ICS: https://datatracker.ietf.org/meeting/116/session/30184.ics ## Available After Session: {#available-after-session} Recording: http://www.meetecho.com/ietf116/recordings#NETMOD Jabber Logs:https://www.ietf.org/jabber/logs/netmod # 01) Session Intro & WG Status {#01-session-intro--wg-status} ### Chairs (10 minutes) {#chairs-10-minutes} Qin Wu: draft-ietf-netmod-node-tags-09 is ready, waiting for feedback on the mailing list Lou Berger: We have received a liaison. Scott Mansfield: ITU are also interested in this work, expect a similar liaison statement. Charles Eckel: It is important to give a liason response to the 3gpp. Lou Berger: We'd like to see response text sent to the list (or can send to the chairs) # Chartered items: {#chartered-items} ## 02) Common Interface Extension YANG Data Models, Sub-interface VLAN YANG Data Models (10 min) {#02-common-interface-extension-yang-data-models-sub-interface-vlan-yang-data-models-10-min} ### Presenter: Scott Mansfield {#presenter-scott-mansfield} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang-11 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-intf-ext-yang-11} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model-08 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-sub-intf-vlan-model-08} start: 9:40 Rob Wilton: About expired reference: is it informative? Scott Mansfield: yes, we can probably get rid of it Qin Wu: Could link with the attachment circuit work instead. Lou Berger: careful not to get too bogged down in that - we want to keep things moving forward Rob Wilton: Is the attachment circuit draft that you referenced a device level or network level model? Qin Wu: It can be used for both. ## 03) YANG Versioning Update and Discussion (30 min) {#03-yang-versioning-update-and-discussion-30-min} ### Presenters: Tom Hill and Joe Clarke {#presenters-tom-hill-and-joe-clarke} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning-08 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-yang-module-versioning-08} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver-10 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-yang-semver-10} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison-02 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-yang-schema-comparison-02} Start 9:44 Tom Hill presented an overview/update of the general work. No questions. Joe Clarke presenting on Schemma Comparison (i.e., current work) * * * Some exchanges happened on the chat at this point related to slide 7 of Joe's presentation (prefixed here with 'chat:') chat: Michael Richardson I assume counter\_t has more bits of precision than uint8\_t :-) 30 March 2023 at 20:58:27 PM EDT chat: Jason Sterne We probably need to more carefully define that example. We're still debating a lot of these cases in the weekly calls and haven't worked through all the details. 30 March 2023 at 20:59:33 PM EDT chat: Per Andersson It was a bit contrived example, and not presented in full, but the idea is that the base type for counter\_t is uint8 30 March 2023 at 20:59:39 PM EDT chat: Jason Sterne In that case, we might not classify that as NBC even in the schema algorithm. 30 March 2023 at 21:00:15 PM EDT chat: Jason Sterne But if we rename a typedef that is being used by that leaf, then that would be NBC in the schema algorithm. 30 March 2023 at 21:00:40 PM EDT chat: Michael Richardson Ah so, uint8\_t -> counter\_t is just a change of typedef, not increased number of bits. CBOR, JSON and XML mostly do not care about the transfer. 30 March 2023 at 21:01:08 PM EDT * * * back in the main meeting: Jeff Haas: Comment on slide 7. We need to define if counter\_t has the same base type or not. If counter\_t is also a uint8 (and maybe only added a 'unit' or 'description') then this change may be of interest to flag in the output, but may not be NBC. Joe Clarke: if the new typedef added a 'units' then maybe that doesn't change "on the wire" (algorithm 1) but it may change the "schema" (algorithm 2). Jeff Haas: Changes of typedefs that have regular expressions (patterns) aren't really possible to analyze (e.g. IPv6 address patterns are described with two totally different patterns (textually) but they have the same semantics). Joe Clarke: Yes, same for 'when' and 'must'. We will perhaps use 'potentially-nbc' as the output for these cases. Qin Wu: For on-wire perhaps we are just trying to identify syntax changes. For schema we are checking more.For a description change, do we use the on-wire algorithm or the schema-algorithm? Joe Clarke: Description change could affect how the value are interpreted, so it might be NBC even if the on-wire format does not change. Even though the client sends the same data, it may result in a different behavior on the server so we may have to flag that even for the on-wire algorithm. Qin Wu: on-wire may be easier to implement. Schema comparison may be useful but difficult. Are we going to mandate that both algorithms are mandatory or that one is optional? Joe Clarke: some of the output of this work may be reference code. Not sure what will be mandatory to implement yet. Maybe pick a reference tool like pyang that would have both algorithms. Qin Wu: how to report this? Does the output differentiate between whether the issue was found by the on-wire algorithm vs the schema algorithm? Joe Clarke: Reporting is still an open question, do you use --schema or --on-wire, is the output json? Same with level of verbosity in the output - do we keep all potentially-nbc in the output by default or not? Lou Berger: What encodings do you have in mind for on-wire algorithms? Joe Clarke: We have not discussed any encodings within the contributor group yet (e.g. binary, CBOR, etc). Rob Wilton: for encoding it comes down to whether we're embedding typedef name in the output. Lou Berger: The example with uint8 -> counter\_t would perhaps change (or not) for a binary encoding but maybe not for an XML encoding. Rob Wilton: The size would maybe change in a binary format and that would then be flagged (e.g. uint8 to uint32). Lou Berger: feels like a slippery slope - lets see where the work progresses Jason Sterne: We will have to take different encodings into account, even non-IETF formats as e.g. gRPC. For on-wire algorithm maybe typedef name changes aren't reported, but for the schema algorithm it would be a NBC change. The schema algorithm uses the full rules from Module Versioning (typedef name change = NBC). The big question is whether an on-wire algorithm, with a subset of rules, is useful for users/clients (who aren't augmenting, composing, etc - don't care if a typedef was renamed). Carsten Bormann: Biggest challenge in CBOR is when you put something in a union, the encoding has to change. A totally different encoding is needed when a union changes. That is always NBC. Joe Clarke: yes - as Jason mentioned we will have to take that into account. * * * Some exchanges related to 'encoding' happened on the chat towards the end of this presentation, shown here prefixed with 'chat:') chat: Christian Hopps integers and strings are strings in xml 30 March 2023 at 21:10:40 PM EDT chat: Alex Huang Feng Shouldn't the encodings be covered by other rfc such as yang-CBOR or yang-json ? 30 March 2023 at 21:11:11 PM EDT chat: Christian Hopps and very different things in binary :) 30 March 2023 at 21:11:14 PM EDT chat: Michael Richardson yang-CBOR is RFC9254. 30 March 2023 at 21:13:05 PM EDT chat: Jason Sterne The encodings are covered elsewhere, but what we define as NBC in the on-wire algorithm will have to take into account all the encodings that we want to consider. (which should include CBOR, gRPC IMO) 30 March 2023 at 21:14:43 PM EDT chat: Lou Berger (as contributor) I'm very warry of going down a path where yang ends up being encoding "aware" 30 March 2023 at 21:14:44 PM EDT chat: Christian Hopps It seems to me that "on-wire" compatability has a lot to do with the chosen transports encoding 30 March 2023 at 21:14:52 PM EDT chat: Christian Hopps it might even be the definition of "on-wire" 30 March 2023 at 21:15:21 PM EDT chat: Jason Sterne Maybe. But what if we said the only differences for on-wire is that it ignores typedef name changes & grouping name changes (at the limit)? 30 March 2023 at 21:15:40 PM EDT chat: Joe Clarke The on-wire (as Jason mentioned) is more of, "will this break the client". And one open question is still config v. oper. So on-wire has been initially construed as will it break the client from a config standpoint. 30 March 2023 at 21:20:21 PM EDT * * * ## 04) System-defined Configuration (10 min) {#04-system-defined-configuration-10-min} ### Presenter: Qiufang Ma {#presenter-qiufang-ma} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config-01 {#draft-httpsdatatrackerietforgdocdraft-ietf-netmod-system-config-01} Start 10:15 Rob Wilton: The question of running being valid needs further discussion. Somewhat of an ambiguity in 8342. Some people may intepret valid strictly (all leafrefs resolve, mandatory present, etc) but some may feel that if 'intended' is valid then it implicitly means running is valid by implication. If you have configuration you can comment out then how can both running and intended be valid? Kent Watsen: should we define validity as 'intended' being valid as NMDA does? Rob Wilton: before you poll I wanted to mention that we could have a solution where we define different sematics for NMDA servers vs pre-NMDA servers. Poll Question: WOULD IT BE OKAY TO MOVE TO NMDA'S INTERPRETATION NOW? (THAT RUNNING IS VALID VIS-A-VIS INTENDED) Poll Results: Few participated, no clear conclusion. Lou Berger: Not a lot of uptake on the poll. Many people may feel as I do that this needs more discussion. chat: Balázs Lengyel referenced by instance-identifier should be considered Rob Wilton: (referring to slide 5) my intuition is that "resolve-reference" should copy all items necessary to make the config valid. Charles Eckel: Could this mechanism address the "isInvariant" needed for 3GPP? Or do we need two mechanisms here? Quifang Ma: Reasons for two documents, 1) system config work now focuses more on general system config issue without defining any explicit flag to indicate immuability; 2) while immutable document is derived from system configuration, we do not want it to be limited to system config. There are cases for immutability beyond system config so it is its own separate draft. Charles Eckle: it would be nice to have one mechanism that meets both requirements (3GPP and other NETMOD system config uses) Balazs Lengyel: Two items: 1) autocopy cannot be defferred to the commit because you might need to copy nested objects and it will need several commits to do so. So I don't think autocopy can be deferred to the commit. 2) Some people want to use immutable even without system config. So that's another reason to keep it separate. # Non-Chartered items: {#non-chartered-items} ## 05) Security Considerations Template for YANG Module Documents (10 min) {#05-security-considerations-template-for-yang-module-documents-10-min} ### Presenter: Kathleen Moriarty {#presenter-kathleen-moriarty} ### Draft: https://datatracker.ietf.org/doc/draft-moriarty-yangsecuritytext-02 {#draft-httpsdatatrackerietforgdocdraft-moriarty-yangsecuritytext-02} Start 10:30 Glenn Dean: This may be the first time a trust issue has come to a technical WG for presentation. Minor change but will help IEEE to use it properly. Rob Wilton: Kent raised the question with netconf work of keystore drafts of how to properly populate the yang security section. We might have too much stuff in this section and may need to cut it down. But this is quite pressing. Suggest to pull this through the process quickly, and make an RFC, to keep liason relations good, then maybe create a bis (of this new RFC) to update the actual template text. Kathleen Moriarty: So you mean AD sponsor this as an RFC? Lou Berger: Can you re-state what you're looking for from this WG? Kathleen Moriarty: Move this quickly as an AD sponsored draft. Raise the modification of the template text as a separate issue, to be dealt with in another forum (in a bis draft of this RFC once published). Lou Berger: I would expect this to come to OPS area because it comes from the wiki. Let's do what is expedient though (here or OPS). Benoit Claise: It was put a wiki because it was changed a number of times in the past, and changes should be easy to do. But now we want to do this as 'track'. So what is the process for that? Are we losing flexibility in doing what is right for updates? Kathleen Moriarty: Note it hasn't been updated since 2018 so it is reasonably stable. Although the group is talking about potential updates. Glenn Dean: This path is so IEEE can make use of it as a reference for license material. Because it is an external org we had to go this path. Lou Berger: I'm still uncertain of the specific ask from teh trust. Can we just update it on the wiki? Kathleen Moriarty: No. That was the problem. Glenn Dean: We can't do that, because the Trust provisions need a document to reference. We can't license out the wiki. We don't want to cut a specialized license for this. Publish an RFC, wrap it in these two tags, and you're good to do. Extenal orgs can take that text, modify as needed, and publish. Must be via RFC not wiki. Lou Berger: I like the expedited solution. I would suggest to the trust that they consider general licensing terms for the wiki so the next person that comes along addresses that as well. Glenn Dean: We'll take that under advisement. Lou Berger: The action is on Rob to create a draft and what working group to put it in. Rob Wilton: There is a draft, and I'm happy to AD sponsor it directly rather than putting it through any WG. Michael Richardson: Thanks for the slide. I didn't get this understanding from the document (that may need clarification). Was it really necessary to have this as an RFC and no other place we can do this? Kathleen Moriarty: Yes. We looked and this is the only way forward. Michael Richardson: does this new document constrain us to not keep using the wiki internally? Updating it there, etc? Glenn Dean: We don't have the means to license out text from the wiki. The wiki is fine for internal IETF use and process. Michael Richardson: Fair enough. Let's get it done as quickly as possible then. ## 06) YANG Extension and Metadata Annotation for Immutable Flag (10 min) {#06-yang-extension-and-metadata-annotation-for-immutable-flag-10-min} ### Presenter: Qiufang Ma {#presenter-qiufang-ma-1} ### Draft: https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag-05 {#draft-httpsdatatrackerietforgdocdraft-ma-netmod-immutable-flag-05} Start 10:40 Jason Sterne: \[Referring to slide 8\]. The slide says the only way to change an immutable leaf is to delete and re-create it. If a candidate is supposed to be declarative (i.e. what I want to achieve), shouldn't it be the server that automatically deletes & re-creates in order to achieve the desired configuration? The candidate would accept the new value and the flag would just warn the user that the parent object would be deleted/re-created by the server. Qiufang Ma: I think it should be the client to delete and re-create. There may be a traffic disturbance if the server deletes and re-creates. POLL: IMMUTABLE - QUESTION FOR GROUP: IS IT TIME TO ADOPT? almost half participated, almost all supported. -- expect adoption call on list Kent Watsen: I wanted to answer Jason's question. Qiufang said it correctly - nothing changes. There is no new run-time behavior being asked by the server. The server only has to ferry a document to the client. No new run time behavior on the client either. If they don't want to look at the document they don't have to request the document. But if they wish to have more knowledge about how the server behaves then they can request the document. So just goodness I think in that regard. Balazs Lengyel: No new behaviour on the server, only here to model existing behavior. Some of these behaviors in 3GPP have been around for decades and aren't going to modify this. But they want to be able to document this in YANG. Either we serve them e.g. 3gpp and ITU or the behaviour is put in proprietary solutions or in description text etc. Jan Lindblad (from chat): The requirements to serve 3GPP and ITU can be fulfilled without removing core YANG principles. ## 07) Representing Unknown YANG bits in Operational State (10 min) {#07-representing-unknown-yang-bits-in-operational-state-10-min} ### Presenter: Jeff Haas {#presenter-jeff-haas} ### Draft: https://datatracker.ietf.org/doc/draft-haas-netmod-unknown-bits-01 {#draft-httpsdatatrackerietforgdocdraft-haas-netmod-unknown-bits-01} Start 10:54 Jason Sterne: This is a modelling convention. Is this an informational RFC? I could see many such proposal for various modelling proposals/templates. Do we need to define applicability? Jeff Haas: I would recommend a proposed standard for the type, user should have freedom of using it or not. No mandate. Users have freedom to use whatever modelling techniques they want. This is just a tool in the toolbox. Alex Clemm: How do you avoid the versioning problem? You still need to change the model. Jeff Haas: Indeed, there is a change in terms of schema presentation (the unknown bits change, this is expected), should not be NBC but it is an upgrade. Balazs Lengyel: actually this does modify the NBC rules, a change in the schema (specifying unknown bits) could be considered as backward compatible. Probably needs to be documented in the RFC Jeff Haas: I think of this as an upgrade, but interested in hearing the WG opinion on how it should be treated (wrt to BC vs NBC, markings) POLL: QUESTION FOR GROUP: ARE YOU INTERESTED IN WORKING ON UNKNOWN BITS: YES = YES; HANDS DOWN = NO; NO RESPONSE = NO OPINION Lou Berger: about half responded, of those overwhelming supported ## 08) YANG lessons from BGP YANG work (10 min) {#08-yang-lessons-from-bgp-yang-work-10-min} ### Presenter: Jeff Haas and Mahesh Jethanandani {#presenter-jeff-haas-and-mahesh-jethanandani} ### No associated draft {#no-associated-draft} Start 11:03 No time for questions. chat: Qin Wu @Mahesh, do we have strong agreement to delegate thing to IANA? would it be great to provide more examples to help understand how this practice is excercised 30 March 2023 at 22:14:40 PM EDT chat: Benoît Claise Next, we'll follow the same process for the topology-related YANG modules (what we call the Digital Map) 30 March 2023 at 22:15:05 PM EDT chat: Lou Berger straw poll - should we have an interim to discuss lessons learned? 30 March 2023 at 22:17:14 PM EDT \[a few folks supported this idea in the chat\] chat: Qin Wu I think it is a good idea, I have resonance on packing model for test and validation. We have see a lot of initiate to do this. 30 March 2023 at 22:18:40 PM EDT chat: Joe Clarke +1 on the BGP work. Also interesting to see the OC "donation". 30 March 2023 at 22:14:42 PM EDT chat: Jeffrey Haas We decided to change direction from several things in the oc module. Many of our motivations for such are differing agendas between the orgs. IETF cares about all the stuff, oc is an operational focused subset. But it’s important to recognize the history and contributions. We’ll likely borrow ideas both ways over the maintenance life 30 March 2023 at 22:18:47 PM EDT chat: Jeffrey Haas One bit of work mahesh skipped in the slides is how collaboration tools for integrated testing, draft generation and model validation was incredibly helpful. Some baseline tools like we used that are IETF supportive would be generally helpful to the organization. 30 March 2023 at 22:20:47 PM EDT chat: Juan Cardona Some kind of tooling for model examples, model coverage, etc for ietf models could be very useful.. I would even dare to say that it should be mandatory. Jeff, what tools did you use? 30 March 2023 at 22:25:04 PM EDT chat: Jeffrey Haas The usual tools. Just inside a docker container with good make files No need for local installs 30 March 2023 at 22:30:42 PM EDT ## 09) Incident Management for Network Services (10 min) {#09-incident-management-for-network-services-10-min} ### Presenter: Chong Feng {#presenter-chong-feng} ### Draft: https://datatracker.ietf.org/doc/draft-feng-opsawg-incident-management-00 {#draft-httpsdatatrackerietforgdocdraft-feng-opsawg-incident-management-00} Start 11:13 Balazs Lengyel: We had a very similar discussion in 3GPP about alarms and incidents. Alarms can be very low level (e.g. one interface is down) or can be very high level (e.g. 1/2 of network is down). An alarm could be based on dozens of counters and states. So we don't really need a different mechanism in addition to alarms. Is the information provided by an incident different than provided by an alarm? Rob Wilton: take a look at the SAIN documents (in RFC editor queue). How is this different and can this be done as augmentations on that model? Qin Wu: We try to align with TMF and we're aware of 3GPP. incidents are different from traditional alarms because they focus more on the service level. Try to provide more abstration and reduce load on the higher level management systems. Benoit Claise: Advantage of this work is that it is trying to map two different worlds: TMF (top down) and IETF (bottom-up), which we have to do. This is the first attempt to do this matching and I've known we need to do this work for a long time. Thank you for this work. ## 10) ANIMA yang-data/sx:structure, RFC8366bis discussion (10 min) {#10-anima-yang-datasxstructure-rfc8366bis-discussion-10-min} ### Presenter: Michael Richardson {#presenter-michael-richardson} ### Draft: https://datatracker.ietf.org/doc/draft-ietf-anima-rfc8366bis-07 {#draft-httpsdatatrackerietforgdocdraft-ietf-anima-rfc8366bis-07} Start 11:24 Michael Richardson: There is an example repo where I put all these methods we tried togeher into a simple version. A link is on the mailing list. POLL: INTEREST IN INTERIM FOR VOUCHER CONCERN? Lou Berger: Even if not all participated there is enough interest for an interim. # Unscheduled time (0 min) {#unscheduled-time-0-min}