IETF Meeting Minutes

Session Date/Time: 20 Mar 2026 01:00

Benoit Claise: Good morning and welcome. This is the NMOP meeting. So, I have next to me Thomas. Thank you for helping. Reshad, you're online, right?

Reshad Rahman: Yes.

Benoit Claise: Very good. So, welcome to this session. By now, you should know that Note Well that you read whenever you register for the IETF. So, we have someone remote, Reshad. We've got a presenter as well, so make sure you're signing into the Datatracker. Make sure that whenever you have a question, you click on the small hand as you know by now. What else? Join the mic queue. If there is a show of hands, that's the way to participate there. If you are remote, make sure you use a microphone like I guess Reshad is doing, a good one. And I think that's about it for the administration. This is the second meeting we're having, so we can be quicker here.

So, as always, we need to take minutes. It's great if we can all participate. Can I have one or two persons taking the lead here for the meeting minutes? Thank you, Dan. Much appreciated. Thank you, Chongfeng. And by the way, whenever you go to the microphone for a statement, it would be great that you double-check the minutes to make sure it was well captured.

All right, the agenda. So, we're going to start first with the SIMAP concepts [draft-ietf-nmop-simap-concept], then a couple of documents related to project one, the YANG Push, so YANG-Push to Message Broker Integration [draft-ietf-nmop-yang-message-broker-integration], YANG Message Keys [draft-ietf-nmop-yang-message-broker-message-key], and the YANG Message Keys and YANG Push Topic [draft-ietf-nmop-message-broker-telemetry-message]. Then something new about BMP YANG module. Med will follow with the RFC 3535, 20 Years Later [draft-ietf-nmop-rfc3535-20years-later]. Then the outcome of the Knowledge Graph Design Team, the AI-based Network Management Agent, the Models for Distributed Authorization, the Generalized Capability Principles, and the Applicability of the 8795 YANG Model to SIMAP. So, is there any agenda bashing?

One thing I would like to stress with Reshad is sometimes it's difficult to see which presentation we give airtime. We have, in this case, a couple of presentations that are late and for which there's not much feedback on the mailing list before presenting. We are lucky to have two sessions for historical reasons because we have Hackathons, etc. Pay attention that if we ever go to a one-session of two hours, this will not fly. So, we always prioritize the items that—on which there is discussion. So, if you post a draft like one week before the deadline, then next time it might be a problem. There is time allocated in there, so make sure that whenever you present, you also take care that it contains Q&A. Again, we're lucky there is 10 minutes in the end, right? So, but take that into account. Reshad, is there anything to add here?

Reshad Rahman: Yeah, I just want to add on what you just mentioned, Benoit, is the goal of meeting face-to-face is not just to present, but to have some good lively discussions. I seem to remember, I forget whether it was in Montreal or in Madrid, we had good discussions on Message Keys. It's a draft which had been published, you know, way before. I think we even had an unofficial meeting on that. We had good discussions. It's really hard when there's a 00 which is published right at the deadline to have a good enough group of people to review it and have relevant discussions on that live. So, that's the main reason why we encourage people to try to publish early and get some traffic on the mailing list. Thank you.

Benoit Claise: Thank you. So, first presentation. Olga, you have the clicker.

Olga Havel: Sorry guys, I know it's early Friday or late night, but we'll go quickly through this. So, today I'll talk—I won't do the full refresh. I'll just point to the things that are changed in the draft, updates since IETF 124, and what next for SIMAP. So, this is the refresh summary slide, but I put things that are changed into red. We added in SIMAP definition—we did some minor changes to SIMAP definition adding topological and splitting data and model examples. We also added definitions for SIMAP API, SIMAP Client Application, and SIMAP Server.

In regards to mentioning topological entities and topological properties, we added clarifications in the document and we clarified what they are. We also changed all the comments related to the use cases and to the requirements. And for the Hackathon—the important thing for the Hackathon was that we had a joint Hackathon with the Knowledge Graph, where we put SIMAP into Knowledge Graph. But we also put Active Inventory, Passive Inventory, and relations from the topology to inventory, Wu Bo's draft. And we tried to kind of see if to test for the completeness of the semantics. And there were three issues that we brought back to the IV [Inventory Management] and we attended two side meetings for IV where everything worked for Active Inventory in terms of relationship between SIMAP and IV, but for Passive Inventory, relationship was missing. We also gave some comments about passive device being a network element, which they also already were discussing about, and some topological information being repeated between the two. So, this is under discussion as well. So, we had a good side meeting yesterday as well. So, the results of our Hackathons were shared with IV.

So, we had 49 issues opened as a result of the last call and all issues are addressed on the mailing list, GitHub. We have zero issues open now, so we pushed version 08 in February 2024. And then Reshad did a shepherd's review and came back with some five questions. For three of them, we kind of made changes and for two, we gave clarification. And Reshad said he's happy with the—with what we changed. So, we have now version 09 that we hope will go to the IESG.

And what next for SIMAP? We are working on the modeling gaps and there is a version of the document submitted yesterday and shared on the NMOP mailing list. The goal is after this IETF to focus more on modeling and have a discussion of the mailing list in regards what are the best candidates for each of the requirements. The document was changed. We added some kind of feature, YANG feature grouping of the requirements, maybe that we can kind of group them into multiple groups so that it's maybe easier to do reviews and publishing, etc. We did some modeling changes and some editorial changes. So, going ahead as well, so on the right side, you can see kind of how we group the features. But this is just initial proposal, so we will discuss on the mailing list. And for Hackathons, we are planning two things. One is to continue SIMAP modeling for all these gaps and if there are candidate approaches, to kind of implement them and compare them, evaluate them. And also, SIMAP in Knowledge Graph, we want to test all the different external relationships that are important. Now we have it with inventory. We'll have it with new versions. Then we want to continue with anomaly, etc. So, thanks everyone. If you have any questions or issues or feedback on either SIMAP modeling or SIMAP in Knowledge Graph, please contact any of the authors after this meeting or by email. Thank you.

Benoit Claise: So, thank you Olga. So, a couple of things. So, I have to do the shepherd write-up. That should be a formality after what we've done, I mean the back and forth. So, that should be good. So, after that, my HD AD will review that and, you know, you might have to do another round or two of updates. And after that, it would go to the IESG. Regarding SIMAP YANG, so I haven't paid too-too much attention to that because we already have a bunch of other working group documents to pay attention to. So, has there been lots of eyes on that document or has it been mostly author-driven and not much feedback up to now?

Olga Havel: Well, the document was driven by the gaps from the requirements, you know. But we were focusing on closing all issues of this document so to be able to kind of have a focus on the modeling approach where the requirements are agreed. So, we have initial proposals there, but they are really kind of there for the start of the discussion to—to get involved more people. And our goal would be to engage more people and to find people who are interested in reviewing the modeling and coming with some feedback.

Benoit Claise: So, based on what the current—the latest changes you did to the SIMAP YANG doc, do you think that document is in a state that it can be reviewed by more people or do you need to do more updates before we get to that phase?

Olga Havel: I think at the moment I would prefer that we discuss each of the requirements on the mailing list individually. Maybe it's too much to review the whole YANG document in one go. Our goal was to kind of start with the most important requirements and then just send the snippets to the group, mailing group, so that people will engage. I'm worried if there is a 51-page document that people will be discouraged to review it. But any advice is welcome.

Med Boucadair: Med Boucadair, Orange. First of all, yeah, many thanks to Olga I would say for the dedication of the hard work you are putting on this document to—to have something which is really stable. I think that we have a good document in terms of defining the concept and how—what are the potential, I would say, of this concept and how it's actually grafted to other concepts that are useful for the network management. That's for the first part. Now that we will be starting, I would say, the concrete implementation or realization of the SIMAP itself. As you know, we have two proposals on the table right now. The one that you are proposing with the starting from the base topology and then enhance it with the SIMAP functions. And as we will be having, I would say, later in this session, the other approach starting from the TEAS, which is more rich and then try to profile it and trim it to, I would say, to come to something that will be satisfying the SIMAP options.

I think that for the sake of saving everyone, I would say, time and energy, I think that I would really recommend that for the working group, for the starting point, to decide actually on which one to, I would say, to adopt or at least put the two teams, I would say, to try to be working as a team. Because otherwise, we'll be repeating the same discussions again and again. So, just for saving your time and energy and for the others as well. Whether we just have that discussion at the, I would say, an architectural level to say that, yeah, these are the features, I start from here, I want to converge and arrive at that time, what is the gap there, and do the same exercise from the other approach, the TEAS. And see if people here in the room, at least in the NMOP, and I really like to have more operators chiming here rather than having single, I would say, contributors from single affiliation and so on. This is nothing against the people who are really contributing because we are a voluntary-based organization and I'm really glad to see people contributing to this. But having more eyes, I would say, from the people who will be really deploying this, will be really helpful for us as a working group to produce something that will be useful and implementable in the real networks. That's at least the—I don't know for the chairs, I think this is also something that needs to be, I would say, considered. Trying to help coach this a bit, because this is beyond technical matters at some point and we make the need—we make the need to make a decision early in the process rather than just leaving it later on.

Olga Havel: Yeah, I appreciate that, Med. Thanks.

Mahesh Jethanandani: Mahesh. I think I—what Reshad was trying to get to is try to figure out what's the best way to move this forward. And in support of what Med said, I think the more eyes on the document, the better. So, even if it's a rough concept, I would say instead of sending snippets where you might miss the concept of the entire model, send what you have, try to get feedback on the model, and that would be my suggestion as a way to move forward.

Olga Havel: Thanks.

Benoit Claise: Thank you, Reshad. Anything you want to add?

Reshad Rahman: No, it's good. Thank you.

Benoit Claise: Thank you. Next is Thomas.

Thomas Graf: Hello everyone. I would like to present some updates on the Message Broker Integration draft [draft-ietf-nmop-yang-message-broker-integration] and also mainly a report what's happening at the Hackathon and go a bit more in detail than what we—the time that was allowed on the Hackathon presentation itself.

So, from a document update perspective, there were only a couple of minor changes. So, in the overview, we got comments that the consumer and the message and the producer should be outlined a bit more detailed, so we added them on the diagram. And also, some of the terms which the document itself defines, we added in the terminology section. And since we also added in the schema registry context, we are now putting the YANG features into context. So, because depending on which YANG features are being enabled, the YANG schema tree is changing. So, we updated that section in the schema registry. And at the very end, we detailed on the milestone section in the appendix what actually was the state on the implementation side of the IETF 125 Hackathon. What's still missing is the security and operations considerations section, so we intend to do that by the next IETF. Otherwise, we believe that the document is ready.

Now focusing on the implementation. So, in this Hackathon, you will notice in yellow marked that basically we are now moving further up the chain. So, our main focus was the producer, consumer, the YANG validation part, schema registry aspect. And we have with libyang and YANG Kit two YANG libraries we are using and steadily extending to fit our use cases. Everything is on GitHub. So, there on this link, you will find for the different system components. In each components, you find packet capture, JSON, logs, also some descriptions depending on like which implementation, what has been implemented and I will detail that in these slides.

So, starting with the publisher. You know already from the past IETF meetings, we have basically the RPC calls where you can add, remove subscriptions for each implementation and we have the notifications and as a PCAP but also as a transformation after the vendor receiver is receiving. That's the feature coverage in this IETF. You see in green marked, we have with ArgoOS a new implementation, which is supporting YANG Push, UDP Notif, distributed notif, the envelope, but also the system capabilities including the transport aspect. I added also now this slide because we started besides having just a YANG Push implementation, we have also now vendor started in implementing for operational metric IETF models. You will notice in the upcoming IETFs that this list will get longer and longer as we pass on. Right now, the main, I would say, coverage is around IETF Interface, IETF Hardware, IETF Alarms, and IEEE LLDP. On the brackets on 6WIND, we were not able to do all the tests there, so therefore I keep that open for the moment.

Now moving on to the more, let's say, exciting aspect, so to the YANG Push receiver side. So, in the Hackathon directory, you will find basically a description how Netconf is organizing the subscriptions. So, there, like on a YANG Push publisher, you have a so-called YANG Content ID. That YANG Content ID is basically for the entire YANG data store, while the receiver now organizes that for a set of subscriptions sharing the same YANG schema tree. So, it creates this ID, and within this ID, basically it obtains all through the YANG library of the YANG Push publisher, all modules and its dependencies, and basically stores that within a models directory. For that shared schema tree, it creates its own YANG library. So, basically then with that YANG library and the set of modules, it can recreate the YANG schema tree and perform the schema validation against the notifications. If you have any questions, please interrupt me or come to the mic at any time.

Moving on to the next, going more northbound towards the schema registry. So, this is just an example. So, we have two examples in the directory for, I think, I believe it's IETF Alarms and IETF Interface, if I'm not mistaken, where you see in the screenshot below, that's basically the schema 560 which has been registered and all the dependencies to its submodules. And 560 then, you will see later, is being used when the message is being serialized as a producer to the message broker itself. That leads me to the message broker. So, here we are showing just in the trace logs how basically we can troubleshoot. We have for each—so in a YANG Push notification message, we have a so-called sequence number. And in this trace log, we're basically looking for each sequence number, so basically for each notification, not only the so-called cache content ID I was sharing before, but also the schema ID. So, we know basically how that translation is being performed.

Going to the consumer. And if you look at the directory, you will notice that it's very similar organized than the receiver itself. The only difference is since this time we don't have a cache content ID, we have a schema ID. So, when basically the message on the consumer side is being received, it goes to the schema registry, obtains all the schema, stores them in for that schema ID in a modules directory, generates a YANG library, and then the same way as in the receiver, it uses that model directory and the YANG library and validates the messages again. So, here, I would say, under a normal operator, he would not validate the messages twice. Normally, either you choose to do that already on the receiver side, so before the messages are being produced, or you go for the option to do the validation on the consumer side.

Now that was the first implementation with Netconf. We have a second implementation with the Cisco Crosswork. So, the difference between the two is in Netconf we are using libyang for the schema validation, where in the Cisco Crosswork case, they opted for YANG Kit. And here in these slides, we are describing basically how Cisco Crosswork on the YANG Message Broker consumer side is organizing the YANG modules per schema ID. Here during the Hackathon, we noticed that YANG structure support was missing in YANG Kit and Scott from Cisco contributed to the project there. So, now we have to state that the schema validation for the structure components in the telemetry message is working. What's currently missing is the so-called Anydata validation support.

So, this is the Message Broker status which we currently have. So, we have the telemetry message support in Netconf and PMACity. Both of them also support the YANG Push receiver for UDP Notif. We have the schema retrieval through Netconf get-schema, which is supported by Netconf. It can act also as YANG Message Broker producer. And we have with Netconf also a test consumer to validate the end-to-end chain. It supports Anydata validation, so this has been merged in the latest devil release of libyang. And we have with Apache Kafka then the confluent schema registry, a YANG schema plugin in the schema registry and we have test serializers for the consumer and producer implementation. In Crosswork, we have the consumer and also we can validate the schema against the telemetry message. However, as said, we are now missing the Anydata validation which will be up next for the next IETF Hackathon. On the Ciena Blue Planet side, we also have a YANG Message Broker consumer and the validation. However, there we were not able to finish all the tests and we will do that after this IETF.

Looking back on the previous IETF 124 Hackathon, these were actually the action items and we basically implemented the following. So, we have libyang now supporting Anydata and structure, and even within Anydata, the structures are supported. Before IETF 124, we had explicitly to say libyang which YANG nodes are structures. This is no longer needed, so it simplifies a lot the use of libyang. Then we had two impediments on PMACity side which was in the last IETF 124 Hackathon implementing the telemetry message. This has all been fixed. Thanks a lot, Paolo. And we have also now the YANG features support on the schema registry side and in Netconf all the capability I was mentioning before.

There are a couple of items for the next two Hackathons. So, we have to finish up the Ciena Blue Planet UA workflow engine tests. There are some incomplete tests on the 6WIND side. We have already started with collaboration with the Insa Lyon. So, Moxons Vivek is looking into the different YANG feature coverage between the different YANG libraries we're currently using, libyang and YANG Kit. So, we're looking also into YANG tools from OpenDaylight and looking what is currently being covered, what is missing, to get there a good overview and we would like to share that with the IETF community in the next IETF 126. Then the Anydata validation in YANG Kit is missing. In some vendor implementation, we found that there were some mistakes on how deviations are being described in the YANG library. They were only in the import-only section. So, therefore we had to do a minor workaround just to make the chain workable and this will be removed by the next IETF. Then there are some optimizations we need to do on the YANG Push receiver side. So, right now the subscription state from YANG Push is not preserved across the reloads. This needs to be added and in case the subscription state would be missing for some reason, we want to also add a capability to obtain the subscription state from the router, from the publisher. And then there are some additional optimizations on the Netconf session queuing during the schema retrieval. So, right now for each subscription, the YANG Push receiver is reaching out in parallel to the router and that might not be ideal for every case. And then we want to start on the Message Key implementation. So, right now we are publishing all the—or we are producing all the messages into one topic. Based on the concept which we are describing in the Message Key document [draft-ietf-nmop-yang-message-broker-message-key], we want to separate that now in the different topics with the appropriate addressing name concept and also by creating dynamically the Apache Kafka topics through the Apache Kafka API. Lots of people were involved. Many thanks to everybody who was contributing and working on the Hackathon. I think this was really a great effort. Any questions or comments from the audience?

Benoit Claise: Maybe I'll make some comments here. So, it's great that you have more and more implementations, right? It's also perfect that you keep an overview of all the different ones, because all these drafts are interrelated. It's great that you're also doing some tool developments. Now, I haven't had time to check with Reshad about this, right? But when I see the plan for IETF 126, 127, I'm wondering at which point in time will the document be published? And it's not that we have to publish soon, because as long as we make progress and that we keep improving and testing and all this. But I'm of two minds here, right? Publishing and declaring victory at some point in time, but also keep testing because this is the way it works. So, just thought for food—sorry, food for thought—that I have to discuss with the AD and Reshad. Reshad, if there is something you want to add.

Reshad Rahman: Yeah, I mean, I had a similar question, like in terms of what's the goal line? And I don't mind what the goal line is if it's far. I just wouldn't like a goal line which keeps moving based on new things that the authors want to do. So, we don't have to agree now or discuss now, but, you know, we need to decide what the goal line is. And also regarding publication, I think I noticed there's four normative references on Netconf docs. So, that has an impact on publication too. And then last, there's that one thing where I missed your email from last year, Thomas, which we still need to close. I could be off base, that whole thing about NACM and all that. That, you know, is a lingering item on my side. Thank you.

Thomas Graf: Absolutely, Reshad. We will get back to that. And also, as I was mentioning, I—we were this time really focusing on the implementations and based on that, we would like now to basically write the security and the operations consideration section. And I updated in the back of the slide deck all the reference normative references we have, so there were slight progress compared to the past IETF. So, yeah, I will come back when the document will be ready and assign me a write-up.

Med Boucadair: So, continuing on the same, I would say, topic, and I fully agree with what Benoit mentioned and also with Reshad. I think at some point we just need to define what is exactly the experiment we are carrying here. It makes sense, yeah, to continue because there is something which is really never ended because we are each time identifying new issues, things that are really missing, problems with existing specifications, things that are froze in the specifications but does not comply with what we want to deploy and so on. So, this is something which is really iterative. And so at some point, we need just to stop and to say that, yeah, we freeze it here, we can release this point and then move to a next iteration of the experiment. That's in terms of the theory. But in practice, if we want, I would say, to publish, I would say, the document, we have the dependencies of on the other documents there. So, even if the NMOP decides to send this document, for example, to the IESG, because this is the experimental document that we want to do, the document will be just stable in the and be waiting for the in the RFC Editor queue and so on. So, I think there is some engineering to be done in term of the documentation itself. We need to be a little bit wise on how—on the pieces that we'll be putting there. Maybe that's one way to define the experiment, that is that maybe we will be stopping what you have documented in six month before and the other pieces that are still under development, we can have them as part of the next version of the experiment. So, I would really like that we can, I would say, leverage on what you have done so far, show that we are progressing and aligned with the spirit we had for the NMOP is that this is—we have the experimental work, we have running code, we show it works. We also show when it is failing, that means that and this is something which is reported back, I would say, in the in the RFC 3535 update that we are working on is that if there are specifications here in the IETF that are not suitable to what we want to achieve, we need to say so as well. That's a good, I would say, input and please document all of this. And thank you, Thomas, again for this work.

Thomas Graf: Thanks a lot, Med. Makes perfect sense.

Benoit Claise: And one more thing I want to add on this is when we created NMOP, we put in there the experiment. It was actually a new type of things in the IETF where you don't produce document. The success is whenever we have code. So, on that front, it's a success already. So, which one do you want? Message Key? [draft-ietf-nmop-yang-message-broker-message-key] Just click. Close and go here. No. And I click down. Number five, Message Key. You'll have to go through slightly differently. Okay. Click. Just a brief update on the Message Broker Message Key document. We concluded the—yes. So, first a small introduction into the Message Broker Key for those who were not following. So, the main focus here is really about having an addressing concept on the Message Broker. That means not all the YANG Push subscription are ending up in the same topic. So, we have a topic—an addressing concept which takes the subscription type and also the subscription path into context and produces that in different Message Broker topics. On the other side, it's also about indexing the data, so making sure basically that in the partitions in the topics that we can index that efficiently. That helps us in reducing the amount of consumed messages because we can now directly consume the message that these messages or a subset of the messages we want and also we can leverage for on-change subscription topic compaction to reduce the amount of messages in the topic.

So, this is one out of four Message Broker documents and covers these use cases. We passed working group adoption. Thanks a lot for everybody who was commenting and reviewing, especially to Olga, Rob, and Michael. We started to address these reviews. So, we added in the last iteration the schema ID, schema registry, YANG data consumer, and YANG data node as terms. We removed the dependency on RFC 9254 on the YANG schema identifiers, so to—to simplify the document. And we basically defined a new way how the—the Message Keys are being defined. And we changed the document from YANG module name to prefix. We changed the topic name from YANG module name to prefix. However, during the Hackathon, we found out that this is actually a bad idea, because the prefix can change on each YANG import and therefore is not a unique across all the YANG modules so probably we will revert that change. And that's the state on the document. But now, since I just spoiled the Hackathon, Moxons will also did a great work on analyzing the document and trying to do a proof of concept and see what works and what doesn't, so that will be the next presentation. Any questions or comments from the audience? If not, then thank you. Oh, we've got Rob in the queue. Rob.

Rob Wilton: Hi, sorry, I seem to have lost my voice. It's only because it was on the slide. What's the opinion for the working group in terms of module name to prefix? I think using module name is the right thing or something similar, the observation you had there that the prefix isn't unique is the right one. So, I think module name probably has to be the answer here.

Thomas Graf: Exactly, yeah. Makes sense.

Rob Wilton: And the other thing that's worth saying at that same point is that where like XML used prefixes, that was okay because they bound it to a namespace, which is you then unique. But it feels like YANG's moved away from using prefixes towards module names because the uniqueness or is sort of guaranteed even though it's longer.

Thomas Graf: I see. Exactly. Makes sense. Thanks, Rob.

Maxance: Hi, I'm Maxance. I did the Message Key Message Broker PoC during the Hackathon. So, here are the results. I'm speaking on the behalf of the whole Hackathon team, which is composed of Thomas Graf, Wanting Du, Pierre Francois, and myself. I also want to thank Ahmed Elhassany, which also worked on this PoC and gave us really good insights before the Hackathon. So, yeah, quick recap of the draft. Thomas just presented the draft, so I'm going to be quick. Basically, we are taking an IETF Telemetry Message [draft-ietf-nmop-message-broker-telemetry-message], we're taking the YANG Push subscription part, and from that YANG Push subscription, we are using the subscription filter to derive a unique broker topic name and a broker message key, so that we can do the topic compaction basically and get the latest state of each key.

The current document proposal for the broker topic naming. Basically, the idea is to take the XPath filter, find the absolute schema node ID which in—you have an example here from the document—you take the interfaces/interface, you replace all the slashes by underscores, and then you prepend the project name, the environment so that prod or dev or something, the subscription type which you derive from also the YANG Push subscription part of the IETF telemetry message, you then append the YANG word, and then the module prefix, and finally the absolute schema node ID. For the broker message key, you take the same XPath filter, you also take the absolute schema node ID. If that points to a list, you append the list key identifier. So, for interfaces, the key for the list is name, so you append that and then you append the key value. So, if you are getting the interface called eth0, you append that.

We found a few issues. Here is the list. I'm not going to go over the list now. I'm going to go for each item. You have references as well for issues that were open on the GitHub page of the document with a bit more details on some of those issues. So first, the broker topic naming restrictions. For some message brokers like Kafka, the length of the topic must be under 249 characters and it can only be composed of alphanumeric, underscores, dashes, and dots. And it is—you get a warning when you create a topic which contains both the underscores and the dots because they—there's some—Kafka will confuse if you have dots and underscores basically. The YANG identifiers, they are composed of alphanumeric, underscores, dashes, and dots, but they don't have maximum size restriction. So, a safe mapping is in the general case most likely impossible, right? You have more restrictions on the topic naming than you have on YANG identifiers. So, we believe that collision avoidance must be proposed for this document.

Second issue is that you can have in the IETF telemetry message XPath filter or you can also have a subtree filter. And in the document, the topic name derivation is only specified for the XPath filter, so that's—we're missing this part of the subtree filter derivation. Also, a subtree filter can return multiple roots as a result. So, what should be the absolute node ID then? That needs to be figured out. There's also the message key format which is not fully defined. Should it include the YANG module prefix or not? From the examples, we also see that the separator is slashes, but it's not specified explicitly. So, it would be nice just to get a sentence for this one. And we're missing the data store, so you can get collisions basically on the same topic for this one for different data sources.

You have also the key derivation that is slightly underspecified for the lists. It is defined for basic lists. Basically, you append the key identifier, you append the value of this key for an element. But what about lists that are nested into other lists or lists that use multiple keys? We also need maybe key name sanitization in case you—you get something that is not available for a key or topic name. Fifth issue, the XPath is more expressive than just a simple path. Basically, the XPath is—you know, coming from XML, it's really, really expressive. You can get really fancy with it. For example, if you put double slashes, you can match anything in the tree that matches this expression. You can also do unions. So, it is not specified in the document what happens when you get unions or double slashes or predicates with functions or predicates that do not have as a filtering the key of a list. So, deriving the name of the key of the list is—you need to get to the YANG module basically, that is not said in the document.

The sixth issue we found, the topic derivation might contain module prefixes. So, RFC 7950 Section 14, an absolute schema node ID is basically a node identifier separated with slashes and a node identifier might contain or not this optional prefix with columns. The column character is not allowed in some message broker topic names such as Kafka, so that is also something that needs to be resolved. Number seven is the key derivation with the attribute select. So, that's the @ character of an XPath. This is allowed in XPath. I haven't seen this in used with YANG modules or YANG data, but it's part of the XPath specification. The behavior is not specified in the draft, so that would be nice just to get a sentence for this one. Number eight, there are no mentions of what happens when you have different YANG module revisions or features. Maybe there is an impact, maybe there is not. There's probably an impact for example, broker topic name or the key derivation. So, if there is an impact, it would be nice to also get some mention of those YANG module revisions and features.

Number nine, Thomas already talked about this one. But yeah, the latest version of the draft tries to reduce the size of the topic name to fit the 249 characters by replacing the name of the module with the prefix of the module. On import, you can override that even though it is not recommended by RFC 8497, but there might be instances where you get into some collision with the prefixes, so you need to override that prefix and then it doesn't—it's not unique anymore in the set of the whole YANG modules you're using. So, that also needs to be discussed in the document. Maybe avoid the prefixes since they can be overridden.

So, as a conclusion, we found a few gaps. The keys are usually just byte arrays in a message broker, so that is fixable. The topic names are usually a bit more restrictive, especially in Kafka, right? We saw the constraints. So, that is a harder issue. We discussed some potential solutions with the authors of the draft. Maybe reducing the scope of the features supported by this draft and then falling back to manual mapping, maybe would be something. Or non-human readable topic names, or maybe we can find a general case solution to derive the topic names. As a possible optimization, we also noticed that the absolute schema node ID is part both of the topic name and also in the key, but all the keys are in the same—all the keys that contain some absolute schema node ID are in the same topic containing the same absolute schema node ID. So, maybe we can optimize a bit and take away this absolute schema node ID from the key. And I think that is all. Yeah. Thank you very much.

Thomas Graf: Perfect. Thanks a lot, Maxance. I think that's a very good summary on all the issues. I think that was a really great effort in doing this and I like the conclusion side at the very end. It shows the complexity from the filtering side on the XPath and subtree, and I think it's the right way we should start reducing the scope there to simplify a bit. And indeed, the—I agree the keys, I think we're going to find a solution on the topics name. That will be a more challenging one. Also interesting is with the BMP telemetry message, we are also defining now ways of an addressing concept for and keying for BMP. And we got on the mailing list interesting feedback there, so this will be probably also something we need to consider in the next iterations. Thanks.

Alex Huang Feng: Alex Huang Feng, Insa Lyon. I just want to first thank you for all this analysis. I think it is very useful for the draft. And also, I see that there are a lot of issues that are related to the XPath complexity, which in practice, to my understanding, it's not really widely implemented. And I wonder whether the project from Rob in regards to the YANG Path, I think he calls it, would also be solving that part, simplifying the XPath filtering for all YANG-related issues. So, that might be something to look for.

Maxance: Yeah, definitely. The XPath is too expressive for a YANG identifier.

Thomas Graf: Totally agree. And that—that would be a nice path.

Paolo Lucente: Yeah, this is Paolo from NTT speaking on behalf of the co-authors. We are presenting BMP YANG model for the message broker integration. I have a lot of slides that are very useful for context, but in the interest of time, I will focus on the idea, what is BMP, what are the challenges, the use cases, and the next steps. So, first of all, what is the idea? The idea is that we have BMP, which is the BGP Monitoring Protocol. and it travels information from an exporter like a router to a collector. And then at the collector, what we want to do is to transform these BMP messages, which are binary format, into a YANG so that they can go onto a broker, they could go on a data pipeline and verification and validation can be performed just like we did learn with YANG Push.

Since this is NMOP and BMP belongs to the GROW working group, for who is not familiar with BMP. So, what it—what it is about? So, we have traditionally been using BGP to monitor itself, which is probably not the best idea. And so we could, with that trick, we could—and a little bit of black magic, we could monitor like Loc-RIB. But we have a lot of other advantage points in BMP like Adj-RIB-In, Adj-RIB-Out when we apply policies and things like that. And in order to do that, we could only resort to screen scraping. So, with the BMP, essentially we have a monitoring protocol that allows us to monitor all of these advantage points and on top of that, being a monitoring protocol, we have also timestamping and all other features. Okay? So, I will skip a few slides here and I will go actually to this one. All the other slides are super useful for reference, okay? They describe the mechanics of this integration. So, essentially we have a message broker that sits beyond the BMP collector. Message broker, you know, it's like it has a channels, we call them topics in Kafka, for example. And then these topics can be further split into partitions, right? In BMP we have a number of messages, so we have the Route Monitoring but there are also Peer Up, Peer Down, and things like that. So, there is the problem of mapping messages to channels and then from channels to index these messages to partitions. And Thomas was referencing a little bit before the Message Key, essentially the Message Key draft essentially handles a little bit that problem.

So now, the use cases. Manual consumption, so from a network engineer. Of course, automation, closed-loop, and then of course, resolving applications like from network management, anomaly detection, policy generation, and things like that. So, now we have a number of open questions and this is why I am skipping the slides so to allow for Q&A. So, the first thing is that, like do you resonate with this approach, right? So, we have the BMP protocol between an exporter, so a router, and a collector, and then we transform this into YANG to go on a data pipeline. The second thing is that, you know, BMP belongs to the GROW working group, IPFIX in the OPSAWG, but all the Message Broker integration is being done in the NMOP. So, would you—so let's say that you think there is merit in this work, do you also agree that this work should be taking place in this working group? And then there is also, we introduce like this IETF-BMP-BGP-RIB-entry module and essentially like this is reusing some parts of the BGP module that is defined at IDR. So, we have a couple of open questions also there. So, first of all, we propose some improvements or some changes to this module and we are in touch with the authors of this module to see what is the timeline, the status, and things like that. On top of that, like what we are also trying to do is to extend—so the BGP module focuses on IPv4 and IPv6 unicast, but we would also like to go into Layer 3 VPNs, Layer 2 VPNs, and labeled unicast.

What are the next steps? So first, there is a lot of work still to do. So first is that, like I was mentioning before, BMP has several message types, so we have to flesh out all the different message types and how they map to the different topics. And of course, we have also to do work implementing all of this. We are already working on these topics for the past two Hackathons and I would say we have been learning a lot also from the YANG Push experience that then we are putting into BMP right now. And that's it. I have a beautiful slide that YANG loves Kafka and BMP, probably IPFIX soon. Questions?

Mahesh Jethanandani: Mahesh speaking as a contributor and author of the IETF BGP base module. The Thomas and I have discussed this along with Jeff and the other authors on the base model. I did start the work on trying to convert the BGP RIB attributes and RIB tables in a way to make it available for other documents to be able to include. It's a bit of a work. I just broke the whole model making that change. So, give me some time, I'll take a look at it after this meeting, not next week, but the week after, to see how much of a work it is. Just realized that there is a lot of pressure right now from BBF [Broadband Forum] and their liaisons to publish the module as is, because they have been waiting for it. So, we have some conflicting requirements on the model, but I'll say we'll do the best.

Paolo Lucente: Fantastic. Thank you.

Reshad Rahman: Yeah, so this is more a technical question than a procedural one. So, there was discussion on the list. I think Thomas replied regarding ordering of messages when you put the—when you split the messages on I think there's seven different types of BMP messages. So, I'm assuming there would be seven different topics. And Thomas replied saying, well, it's the same as in Quick. So, how do you handle the going from ordering when you as a consumer? Do you look at the timestamp or?

Paolo Lucente: Well, there is a few different things. So, first of all, we will figure that out. In fact, as I was saying, we have a lot of work ahead of us. One idea that is being floated in the GROW working group is actually to add sequence numbers to BMP. It's actually—it will be actually a feature of BMP version 4. So, looking at the sequence numbers could be, you know, the most intuitive answer I would give you.

Reshad Rahman: But if your messages are in different topics, that means you need to go hunting around for the next one.

Paolo Lucente: Yeah, on that one I agree with you. Like we have exactly the same issue with Quick and we are figuring out what is the best way to figure out how to map messages onto topics. Yeah.

Med Boucadair: Thank you, Paolo, for the presentation. So, as a responsible AD for the GROW working group, I have a preference, I think, to have this work done here in NMOP because the need is—starts from here and the expertise that will be needed is more, I would say, in this room rather than in GROW. Obviously, yeah, we'll be having people from GROW chiming into the BMP specifics and so on. So, yeah, please, if we can just simplify and yeah, and try to continue here if there is some consensus from this working group to work on it and try to include GROW when you have a need for that one. I think that for at least for the more technical aspect, I fully agree that there is a need to have means to ease correlating, I would say, between channels, have some common data model structured then and then we can anchor on them. Today it may be BMP and IPFIX, tomorrow it can be something else. So, please think again, YANG structure, YANG structure, YANG structure.

Paolo Lucente: Sure. Thank you for your comment.

Thomas Graf: Maybe just one comment on the conversation previously with Reshad. So, one option definitely is the sequence number. Another option is the message ordering is actually preserved within a partition. So, if we do the keying and also the naming concept correctly, basically we could leverage that. And I think we should definitely learn from Quick what they are doing because at the end, they are solving more or less the similar problem, right? And then on the other point, thanks Mahesh. As when we were authoring the document, we noticed a lot of work has been done on the BGP model and it's really nice that I mean, if we can reuse all that work. And this is also the—I think it's a great thing to do it this way because otherwise, defining all those BGP semantics, that would be quite a challenge for our side. So, thanks a lot.

Michael Mackey: Michael Mackey, Huawei. Just something occurred to me while you were giving your presentation. Has there been any work done to figure out the size of the YANG Push messages on BMP and IPFIX versus the existing way? You know, is it bigger? Is it smaller?

Paolo Lucente: No.

Michael Mackey: And why—just the volume of data. You know, so I know for instance, like with IPFIX data on Huawei devices, it has to be sent in-band because it's huge, huge volume. If you're making the message bigger, that might become an issue.

Paolo Lucente: Sure. Sure. No, it's a very good point. I'm not aware there has been any analysis on that.

Michael Mackey: Thank you.

Benoit Claise: So, we're kind of five minutes over already, we need to be mindful of the time. Yes. So, Matt, feel free to come and the timer is already running. No stress.

Med Boucadair: Thank you. So, this slot is, I would say, to try to have a discussion on the what we are doing about the update of the operator requirements to refresh what we used to have, I would say, in the RFC 3535 [draft-ietf-nmop-rfc3535-20years-later]. So, what we have done so far is that we have a stable version of a list of operator requirements. That one was gathered from various venues here in the IETF, from a bunch of operators. Thank you all of you, I would say, for the kind contributions and helping us to have that list there. We also included, I would say, from inputs from NANOG, RIPE, and also during the NMOP's workshop.

So, once we have gathered all that material, digested it, structured it, try to have some prioritization, because if you have all this digest of requirements, it's really difficult to say that, yeah, from where we will be starting? Because if you just, I would say, have this list unordered, we will be, I would say, losing focus. And there is really a need to have something which is really implementable and aspect—and also the focus on aspect that makes sense for most of operators. So, that's why with the help again with the input from various operators—I if I'm not mistaken, we have more than six operators who are really shared their individual assessment of the requirements. So, we ended up with a summary of—you can just move to the next slide.

So, we have the prioritization of that list. As you can see, we have 24 requirements with a level of prioritization that—that is agreed between the operators who accepted to do the job. That list is stable for some time now. And in addition to that, because we know how things are really moving. It's good and great to have the voices from operators. This is not happening all the time. It's great that we will be having this time. But in order to put this into effect, we need also to hear from the others: from the vendors, from the researchers, from all of you in this room. And for that one, what we trying to do here is try to find something balanced and filter the long list of requirements we are having here from operators and try to say, is there something that we can sketch as a set of very focused recommendations so that here in the IETF we can provide, I would say, implementation for those? And when we are saying that implementing those, that means that's not only NMOP that will be providing this solution. This can be everywhere in the IETF. This can be reusable structure. It can be new work group. It can be new work that we will be doing, or this can be just changing the way we are doing the work.

So, this is the status. So, but now we have to map this with the contract we are having with you as a working group. We have a working group charter and that charter what tell us is that the working group is missioned to give us an updated list of operators. So, that job for us is done. Is that mean that the stable list of the operator requirements is there, the prioritization is there. So, the question for the working group is, do you want us to continue in the other items that we are just providing to you as a bonus because we think this is important? But this is only us as authors. But you as a working group, do you want us to extend the scope a bit so that we can have that part of the work be done? And I will pause here to have feedback and some discussion from the working group.

Benoit Claise: All right, I'll give my feedback. Actually as an AD, what do you believe we should be doing? Because all of these are somehow creating new work somewhere else. It's maybe creating a working group, it's maybe having a BoF, it's maybe reaching out, and everything is on the table. So, maybe not as an author but as an AD between the two ADs, what do you think is the right way forward?

Med Boucadair: Actually, yeah, this is really important because we need to be really pragmatic and I would say, if we want to do something concrete again, we have this whole list. We need to have something really focused and that thing which is really focused, that we see that people here in the IETF, they want to put time and energy to work on it, something which is really concrete and actionable. So, that item for me is really important because this will be sketching direction for future transformation. We already started to do some of those, by the way, and they will be showing later on. But for me, this is really important. But this is me as an AD. But as an author, we have a charter, we have a mission, and then that's why I wanted to have this also feedback from the working group.

Benoit Claise: And I will just add, so we spoke about the first item and the experiment and how long we want to keep it and you have to declare victory, right? So, this is exactly the same thing here.

Dan Romascanu: The document explained a real problem. I already commented in the list. But Med, I wonder if you could have a few bullet of action items to make it obvious what's the next step. I think I'm summarizing a little bit what Benoit, but I was just trying to get to the mic. Maybe that's the next step here is really what should I do? What should we do? And where the work should be going. So, it's more tangible. Thank you, Dan.

Benoit Claise: I think Dan just gave me the segue. So, just wanted to give an example like the network-wide schema. We've been like in YANG Push, we have been adding the hostname, the sequence number, all that. You heard in the previous discussions that actually the sequence number we are also adding now in BMP. So, it's kind of like in that area, it's kind of already actually happening.

Mahesh Jethanandani: Mahesh speaking as the co-AD. I want to support what Med just said. All these are fairly well high-prioritized items, but really no work in IETF gets done without a contribution. So, it really will come down to who has the interest, who's willing to put the work behind it to make it happen. Med and I have only so many cycles we can spend in supporting and we are in some sense supporting some of the items coming out of this workshop. But really to answer Dan, your question, priority is what you decide to be your priority and bringing it to the working group based on the list that's already out there.

Med Boucadair: Okay, so what I'm hearing so far is that we need to work on this consolidated, I would say, list. So, that's really great to hear, so we will be continuing on this. So, yeah, let's start with a small list. It's one-third of what we have, I would say, from the list of the operators, trying to structure it a bit to have a story there. So, I won't be reading all the items, they are really there. But what I will be just doing is just to show you how we'll be mapping, I would say, the various items and the consolidation requirement that we have there with what we have already started to do. You will be see there for the point one and for point eight there, this is why we have started ONSON [draft-ietf-nmop-network-anomaly-architecture] at the first—at the first place is to solve exactly this kind of problems. Now, this is ONSON and so on. There is the second item, this is the velocity and one of—this won't be the only solution for that one, but this is under that objective. The one about focusing on implementing a minimal set of function rather than having something which is really perfect, complete, and so on. I'm really glad to see that Rob is trying to push the YANG Push Lite [draft-ietf-nmop-rfc3535-20years-later], for me this is an example of things that we need to do. We need to trim the complexity because many of the features we are having there are not really justified by operational need, but for operator, this introduce a lot of complexity in term of testing, validation, and so on, and even this is misspecified and there is a lot of bugs that are there. So, this is really important, that point three. I don't know concretely what are the list of items that will be implemented that one, but I am really glad that we are starting to do this.

At least for the for some of the working groups for Netconf and Netmod, for example, I would personally would really like that we will be having some profiling of the protocols we are having it. We have a lot, a lot of functions, features, and so on, not all of them are really useful and usable. If we have something to say, yeah, for the operator, for example, this is the common part that they really want and provide that as a profile, just a guidance for the others, this will be driving the vendors and the implementers and we know that this is the common ground that it will be really worth for us if we want to progress in this area. There are other items, the—for example, the number nine there. That means that, yes, we are doing something here in the IETF, but this is just one aspect of the problem. There are other aspects of the problem that are not done here, so we need to bridge what we are doing here with what is done in the outside. I am just providing the example of the work which is done here in the NMOP about opening the discussion about the Knowledge Graph, for example. This is for me really important because not only on the topic itself, but because we are acquiring new skills and new topics and also we are changing the perspective that we are looking into the network management. And this is really something that we need to done. It's not, I would say, something which is short-term, but this is something we need to push in, I would say, mid-term so that we can prepare that un-siloing of the issues. The same story about the all the expertise we are bringing, the work done by Thomas, for example, the Tamas [Tamas Boros] and so on. These are normally the skills that are not here present in the IETF and we need to bring that here. We need to find the home for it, nurture it, help it, support it, encourage it, and also be catalyst for that. And this is something which is not be done by only individuals but also be, I would say, by the leadership, but you also as a working group.

We have the work that we are trying to filter a bit. It's—we don't know if there is something to be done, but I am sure there are aspects and what we have heard, for example, this week from the operators during the OPS area about all this about AI network operation. There's a specific needs there. So far, they started to be vague, but there are some proposal on aspect that try to—that start to be resonating with me in term of concrete and tangible actions and we need to continue that one, helping filter down and focusing better on something that will be really useful for us. There are other items that are really procedural for us. Mahesh, we are already doing this and trying to push in many of the working groups, for example, in SIDROPS [Inter-Domain Routing Security] recently, we insist on the implementation. This is something that's, yeah, when you will be doing specification here for the network management, please make sure that we have something which is showing exactly what you are specifying. The code should be first and then the paper. Paper should not be a target per se. That's be good to have your name there and so on, but this should not be the end of the game and the purpose of the game. So, changing that spirit in the way we are doing and developing specification is really a change of the mindset of us. And collectively, we have to push for this. Value people that are coming here with the, I would say, software knowledge and try to push that to be a really part of our process and not just to say that, yeah, I am just producing an RFC and this is the end. No, producing an RFC is just to start. You have to go there, implement it, test it, and come back. The 'C' part of the RFC is a Request For Comment. This is not something which is frozen. That means that nothing is perfect there, it's just a start, play with it, you move it, obsolete it, base it, update it, whatever. And we should be really flexible on this, insist on it, and now with my hat as an AD, this is something I'm really trying push and we are pushing this in multiple of our working group and I would really like that the community for the network management and the operation are really endorse on this.

There are other items, I would say, there that are in the list. I won't go through them. Some of them we don't have, I would say, concrete path or a recipe to do this. If I say that, yeah, I have the vendors and operators work together. Yes, that's good, but we can—we can facilitate this in term of organizing meeting and so on, but concretely, it depends on all of you. You have to make, I would say, an effort to come to understand the requirement from the others and also the reality of and the challenges of supporting some of the products. Yes, nothing, all is just—is not for free. There is a cost, cost in term of re-architecting the product and cost also in term of the money that will be putting there. There is the item there which is really important about the compliance. This is not something we are doing here in the IETF because we say that, yeah, this is not compliance, it's for the others, but for me this is important for interoperability and we need to find some new ways to do this. I don't again—I won't be providing you an example to do it, but we need to do it and we need to find a way to do that one. I know that Ian, for example, behind there, he started in many years ago about having this list of all the YANG models, for example, that are really important. This is really an important exercise that we need to do because it is giving a signal that, yes, if I want to provide that service, this is the subset of tools that I know that are really important for there.

The point seven, this is exactly what Paolo presented. It's about correlating data that we can be, I would say, conveying in various channels. This is not just something which is specific to the keys that you are having there, but each time when we think about reusable data structure, that means that you are opening for the future and not you are not looking your own case. You are not specifying for your own case, but you are opening for the others. OPSAWG again, they provided an example for this when we have specified the informational models using YANG this time. This is the first time we are doing this. Why? Because we wanted to be open for various, I would say, interoperable, various data models, YANG, IPFIX, name it, and so on. So, this is the current list we are having. We think that it is just a subset. The question for the room here is this—should we trim it, should we extend it, is there something which is missing, should we change the approach, and we are really open for the discussion with the room. Thank you.

Benoit Claise: Any comment? I think I forgot to join the queue, but anyway.

Ian Farrer: Ian Farrer. I like the list that we have at the moment. I think all of the things on there are very worthy goals. The 'how' is going to be a little bit more tricky in this case and I think there's going to need to be some improvisation and some experimentation. I like the way you've mapped these to the different working groups, but there's three in the middle there that are notably not mapped to anything. Is this just a feature of how you—how you would do work in ONSON or the other working groups that you mentioned there?

Med Boucadair: Actually, I just trying to provide that this is not something which is a dream. This is something which is already happening. And I'm just trying to map it, I would say, to concrete action that we are already doing there to see that, yeah, that's examples for it. This may be inspiring others. When, for example, I'm showing there that the second item that this is velocity. This does not mean that this is already solved and even if we put velocity into effect, does not mean that this one does not apply anymore, because this one actually, each time you have to apply it. Velocity is just one mean, one tool for it and we will have other instantiation of this one. For example, Mahesh, he mentioned the example about BGP model. It's there for more than 10 years. We should not be continuing doing like this for the data models, for example, if we want to have something which is really usable and implementable by the others. This is—this is something I see that's again mindset change and the way we are doing the work. This will be really efficient if we collectively endorse this. That's the point.

Ian Farrer: I mean, I think you hit the nail on the head there with mindset change and you know, that's definitely what I want to see. Yeah, need to work on how we can do that.

Med Boucadair: Thank you, Ian.

Michael Mackey: Michael Mackey, Huawei. Just a—sorry, something occurred to me while you were giving your presentation. Has there been any work done to figure out the size of the YANG Push messages on BMP and IPFIX versus the existing way? You know, is it bigger? Is it smaller?

Paolo Lucente: No.

Paolo Lucente: Sure. Sure. No, it's a very good point. I'm not aware there has been any analysis on that.

Michael Mackey: Thank you.

Benoit Claise: Perfect. Thanks a lot, Maxance. I think that's a very good summary on all the issues. I think that was a really great effort in doing this and I like the conclusion side at the very end. It shows the complexity from the filtering side on the XPath and subtree, and I think it's the right way we should start reducing the scope there to—to simplify a bit. And indeed, the—I agree the keys, I think we're going to find a solution on the topics name. That will be a more challenging one. Also interesting is with the BMP telemetry message, we are also defining now ways of an addressing concept for and keying for BMP. And we got on the mailing list interesting feedback there, so this will be probably also something we need to consider in the next iterations. Thanks.

Maxance: Yeah, definitely. The XPath is too expressive for a YANG identifier.

Thomas Graf: Totally agree. And that—that would be a nice path.

Xin: Okay, good morning everyone. This is Xin from CAICT. I'm here to present my draft about the AI-based Network Management Agent [draft-ietf-nmop-network-anomaly-architecture]. Actually it is a version of 04. And I want to say again about the scope and goals of this draft. And we all know the background very well. The AI agents are very hot and the autonomous network evolution requires the agentic capabilities. So, this draft will not define the general AI agents, will not define the general agent-to-agent communication or such stuff. We are focusing on the Network Management Agent concept and we want to define a general framework of the agent collaboration with the existing SDN controllers. And we'll also discuss some interface new interface requirements after the introduction of NMA. Mainly about the interface of the controllers.

So, we do a lot of updates since the last IETF meeting. And thanks for the comments from Reshad, like Alice, Marcus, and Chris, and other advice from the WG chair and Med and Mahesh. And thanks for you. And we mainly do the updates including: firstly, we resolve several issues from the mailing list. We end a comparison of the two deployment modes. We end a appendix to describe the different levels in autonomous network. And secondly, we further clarify the relationship between NMA and SDN controllers. Thirdly, we simplified and refined the description of the whole draft. And fourthly, we did a small revision to the functional framework of the NMA to align to the close-loop defined in TMF, like Intent, Aware, Analyze, Decide and Execute. About the deployment modes of NMA, we received the comments from Reshad that what's the difference of the different deployment modes. So, we add more analysation of the advantages of different scenario. Like integrated mode is more suitable for single-vendor scenario and independent mode maybe more suitable for multi-domain, multi-vendor scenario.

And the interfaces are not changed, so I will not talk too much. And we mainly focus more on the interfaces to be extended on the SDN controller. There are two interfaces to be considered. The first is the Northbound interface, the NBI of the controller. We need to extend its capability to realize the capability discovery and invocation between the upper and lower layer NMAs, and we should expose NMA's capabilities as intent-based RPCs. And about the Southbound interface of the controller, because we believe theoretically NMAs won't directly operate devices, so there may be no very strong demands of the standardization of the SBI, so it's out scope of this draft. And I want to save more time for the discussion, so maybe that's all. And in the next, we want to continue improving the draft and mainly on the interface part and the use case part and to continue collecting comments and contributions from the working group. And last, we know that this draft is not perfect, but the content is quite stable, maybe we want to request the WG to consider the adoption of this draft. And that's all. And there is a appendix about the definition of different levels in AN, you may check for reference. Okay, that's all. So, any comments?

Chongfeng: Chongfeng, China Telecom. You have mentioned that this maybe an extension of RFC 8969, right?

Xin: Yes.

Chongfeng: Yeah. So, I'd like to know whether there's any implementations or tests of this framework right now? Yeah, I mean, maybe from side from operators?

Xin: Yeah, actually we I can't say I have any practice right now, but I know China Telecom have already did some agents like the RAN network energy saving agent and we did some test of their agent last year. So, their architecture is consistent with what we proposed in this draft.

Chongfeng: So my question is whether this follows this framework? I think maybe you can have a check or discussion with that team.

Xin: Okay. The details may not be totally same, but the framework is, I think, is consistent. Thank you.

Benoit Claise: Let's have concise feedback, please. We've got two minutes left.

Daniele Ceccarelli: Daniele Ceccarelli from Cisco. So, I'm speaking as a co-author of the draft. I would like to seek the chairs' and the AD's guidance on how to move this work forward. So, unlike a lot of work that is being done in these days, which is up in the clouds, etc., we tried to connect this extremely tightly to network management. This is the reason why we believe that this work could fit here. So, if you have—I see Med is already in the line, so probably he's going to answer my question. But what we would like to have is some guidance from the chair.

Benoit Claise: All right. So, yes, it's something that we discuss with the AD. So, actually we have the same issue here as chairs, because there is so much happening on AI these days: AI for Net, management of AI agent, you name it. So, yes, this is version 4. Yes, receive feedback on the mailing list. The question to the AD is, do we open the gate and telling NMOP is the place for everything AI and then we need like five hours per session of meetings, right? So, we need guidance here.

Med Boucadair: Okay, so I will be expressing as individual contributor, I will leave it to Mahesh as responsible AD for NMOP. I really like, I would say, what this document is trying to do here. They are trying actually this for us anchoring all this discussion. This is not perfect, trying to see that, yeah, we are just the start, the way we are doing network management. We don't know if we'll be changing all the components. There are some feature that need to be introduced there. Let's try to look into them, have a reference so that everyone working in that area came to hear and discuss in reference to this document.

The other work which is proposed today about the network management, this is not something which is proposed here to the IETF. All the list of the other proposals are submitted to NMRG. That means that we don't have a lot of proposal coming here to the IETF. And for me this is really a feature, that means that there is no a divergence in term of the documents that are proposing something with engineering mind. And this document for me, I really think that this is a good anchor for this discussion. And the same advice I have made to Michael for the Knowledge Graph, I would really like us to sketch a small experiment to see that, yeah, this is what we want to do and because for me this is really in scope of the, I would say, NMOP. We don't have the priorities, that means that we need to do some re-chartering if we endorse this work. But we need to come up with that definition of the experiment.

Benoit Claise: Okay, very good. Please hold on, we're out of time. Can you all send your feedback to the list? Except Mahesh, who is our AD for this working group. Sorry.

Mahesh Jethanandani: Thanks, Benoit, for putting me on the spot. To answer very specifically, the working group charter currently does not include work on AI, therefore this work as the charter defines cannot be adopted. That's to be straight and blunt about it. But this is a topic that IESG is well aware of. We are trying to come to a resolution on how best to deal with all the requests that are coming. There will be meetings following this to figure out how we want to approach it and have an answer once IESG has put one forward. Finally, I would say for now, use the Ops Area meeting to bring any new proposals as they relate to AI and discussing them for specifically for the Ops area. Thank you.

Xin: Okay, thank you.

Benoit Claise: Thank you.

Nigel Davis: Nigel Davis. You mean horribly late, you mean. But beyond time should not be during the meeting itself. I realize that now, I know, it was very late, apologies. So, I'll just give a brief update. So, this is on the framework for expressing capabilities [draft-ietf-nmop-rfc3535-20years-later]. We've—I've got a recap of the—Oh, have I got slide control? That's interesting. It will not let me see the slides. Select your slides. Oh, okay, right. Fine. Sorry, I'll do that quickly. Yeah, that's it. Right, the—So, at IETF 124 we presented this brief overview indicating that understanding what a component can do is a fundamental thing in any construction of any system, how detailed it need to be, how we get to a cohesive framework expressing those details and so on. So, we covered that at 124. The key thing is stating what a component can do from a particular perspective with whatever constraints have been applied to it as a result of security and views and so on.

Since then we've gone through the draft. We've completed the definition set. In the previous draft, there were some definitions left to be defined, so we've completed that set. We've especially enhanced the explanation of what the specification is and one of the key processes of moving from one set of level of detail to another—that's the pruning and refactoring process. We've detailed that a little bit in there. We've recognized, as everybody else has in the world, that LLMs provide a major contribution to any of this work and looking at use of LLMs to construct specifications and the specification language itself, which is in itself quite challenging. And also an introduction to LLM's use of specifications, so how that would work. We've put an example in—or it's still a bit light on a temperature sensor, so it should be something you can get your head around, so we all understand temperature because we live in—live in it. And looking at the progression from a generalized thing to component to specialized function to—and this is just an example—termination point to specific type termination point. We've tried to explain that progression using the recursion of or describe how that would be use recursion of specifications. And we're looking at the general application of specifications as well and try and explain that. So, the new draft's got more detailed around that.

As I said here, which is what I find I do, I collaborate with one or more LLMs to construct the language, as I said before. We're looking at—I put TR 512 in there as opposed to ITU-T G.7711. TR 512's freely accessible, no passwords, nothing, so it's the same material that's in G.7711 at the moment. So, that was one reference on the front, but the main document's 7711 TR 512 from ONF covers that and modeling boundaries, which is an obsolete or a dead draft, but there are some insights in that that are important. And then use that language as we construct it to put together examples and then explore how those examples can be reasoned over, so how the specs can be reasoned over. So, that's essentially getting towards working code, which I heard mentioned earlier and I think it's very valid as a thing to be achieved. We've been very poor on going to the mailing list. I know we got—we got told we should do that, we haven't done that properly. So, between now and 126, whatever it is, five, we'll—we'll be going to the mailing list and giving regular updates and inviting discussion on this. And that's all I had to say. So, any questions at all? Any feedback question?

Benoit Claise: Thank you, Nigel.

Nigel Davis: No problem, thank you.

Italo Busi: Hello everyone. I am presenting on behalf of co-authors the applicability of RFC 8795 for SIMAP. What is the motivation? The motivation here is to analyze the existing YANG model as defined in RFC 8795 to support the SIMAP use cases and requirements. The expectation is some of these requirements are already supported and some may need extensions. So, we don't believe that 8795 will do everything, but just some. Because 8795 is a topology model which is multi-layer, allows navigation and correlation between the layers and it is generic applicable to multiple layers, domains, and technologies. Which is exactly what SIMAP wants to be. And we have two drafts. One draft is in TEAS that says that the TE topology models can be used and if needed profiled for also for what people calls non-TE applications. But with this draft, is more focused on how we can profile the TE topology for the SIMAP specific application.

So, we think we just have an initial gap analysis. This is not new, so more work has to be done. But more meat is in the slides that we presented two years ago in an interim meeting and we can continue if there is interest to go into this analysis. What is the issue? Why I keep coming here and say there is 8795? Because there is a requirement, I've heard, that people wants to have simple data model for an application. After discussion, I'll qualify a simple as "my application requires data in a specific format." For example, application one requires to see the bidirectional link as a single entity. So, I want to get this data as I need from the controller A. And it works perfectly between application one and controller A. This works perfectly. But then I have another application that wants to work only which benefits from having all the links as unidirectional, so the links bidirectional is two links. Then you go and it works perfectly on a different data model specific for application two. It works perfectly over controller B. Now, thank you, we have two good silos of application and controller that works perfectly well between themselves. But if I want to port move application one over controller B, good luck, because controller B is not exposing the data model that you expect. So, who is going to change? Because all of them can claim, "Oh, we are standard compliant, we have everything, we are fine, you can translate, you can do whatever you want." So, what happens if we go into this direction? It will be a nightmare for the operator that has to renegotiate between all his application vendors and all his controller vendors how to make application work over controller or live as they are living today in silos. This application works over this controller, this application over a different controller.

So, my question is, after two years coming here and repeating there is a big elephant in the room. Do we really care about this big elephant? The big elephant is here. I see it, I stay here, and if you don't care, we don't care. But give an answer, okay? Do we care about multi-vendor interoperability and therefore try to reuse what already exists? Or do we don't care, we think that having something which is simple is the best thing to do, who cares about the fact that there is another solution and people will figure it out how the—how the two different solutions will work or will never work, they will stay in different silos? And simple is—depends. What is simple for me may not be simple for somebody else. Thank you.

Daniele Ceccarelli: Daniele Ceccarelli from Cisco. You're asking a question, so I think you are seeking for an answer.

Italo Busi: Mainly for operators, but it's good to have feedback.

Daniele Ceccarelli: Yes, I would say the answer to your question is—is yes, because I mean, that's an interoperability issue. That's also an implementation issue. Because as—as speaking as a vendor, I would like not to have multiple implementations to do—to do the same thing. As I told you at the next meeting the—the last meeting, have—the problem of 8795 is that it's bound to TE, and so everyone that is—doesn't care about the TE, and I understand it, doesn't want to deal with 8795. I don't know if it's possible to have—I don't know, a profile of that of that model here which is completely decoupled from—from TE. I don't know. The problem is the namespace and the attribute names. Yeah.

Italo Busi: That's—that's exactly. The other point is that people can say, "Okay, we keep the TE silos," and then when you have a network where I have TE and non-TE. And also non-TE is also hard to understand. It—the—the draft in TEAS is describing that also if you look at what is TE, the definition is very broad. And so there are some people that thinks TE is in a very strict sense is MPLS-TE. I can—I heard people say TE is MPLS-TE. Other people think, "Well, it's a little bit more than MPLS-TE, we have also OTN, WDM, SR-TE, and some people thinks, 'Oh, well, it's...'" I'm—I'm just an example I'm having is I'm hearing some vendors, especially your vendor, that likes to—to use SRLG to make sure that IP fast reroute backup path doesn't fail when the primary path fails. Is this TE or non-TE? But you need SRLG. SRLG where is defined? In TE. Which topology gives me the SRLG of the link? The TE topology.

Benoit Claise: All right. Reshad.

Reshad Rahman: Yeah, so I—I just wanted to point to what Med said after Olga's presentation on SIMAP. If anybody missed it, Med, if you're still around, you can repeat what you said then about having duplicate work and that kind of stuff.

Med Boucadair: I don't remember what I said, but the main, I would say, the idea is to say that, yeah, we need to decide on this early in the process. Yes, please have both, I would say, both of you, I would say, presenting the two approaches: starting from the TE and then profiling it or starting from the topology, adding what is missing, show that gap and please make the decision as soon as possible. I trust the chairs will be doing helping in this. Because it doesn't make sense that we just continue like this in two separate and parallel trends. It's not useful for nano—of us.

Italo Busi: I agree, Med. I'm not planning to continue it. I'm planning to get a decision because the—the information is there, is on the table since a long time. And figuring out, "this requirement yes, this requirement no," is not going to change the direction. Is the big direction is, do we want to reuse what we already have or do we want to do something else?

Med Boucadair: Yeah, what is different, Italo, right now is that before you were just claiming stuff and now you have a draft in which you are trying to do the profiling to show something concrete, so people have something to look into that. So, that's a good progress in my—my point of view.

Italo Busi: I agree. Thank you very much and thank you for the extra minutes of your time in this meeting. This is my last meeting of this week. Thank you.

Benoit Claise: Thank you. That's the end of the NMOP meeting. Thank you very much. See you at the next meeting. Bye-bye.