**Session Date/Time:** 21 Jul 2026 12:00

[00:00:13] **Kent Watsen**: Okay. Welcome everybody to the Netconf session. This is a full agenda, so let's get started. I'm Kent Watsen. I'm joined at the table with my cochair, Per. And, also, across from me is our secretary, Fonf. Fonf, do you wanna say how to quick? K. Yay. Thank you. As always, there's the note well. I'm not supposed to add any interpretive text or comments about it, but I'm sure everyone knows it by now. You had to agree to it when you joined the when you registered. But please be aware that it's important to abide by the comments. So for some meeting tips, if you're in person, obviously, you're in the room right now, please make sure to sign in to the data tracker using the QR code that's on hanging on the microphone or outside on the placard. You can use Meetecho Lite or the full version of Meetecho, but be sure to keep the audio and video off if using the on-site version. For remote participants, make sure your audio and video are off unless you are chairing or presenting. I don't think we have any remote presenters, do we? Yeah. If or and, please, if you wanna speak, be try to use a headset to get the best audio quality. And for all participants, when you speak to the microphone, be sure to state your name each time you begin speaking in the queue. Here's a number of links. These say are the same links that are also in the agenda in case you can't, you know, copy them quickly enough off of the screen. But all the access to audio and the notes page I think already posted the hyperlink to notes page in the chat window. Please help us take notes. That'd be great. The queue will be managed using Meetecho's whether you're not you're in the room or remote. If you want to speak, please enter the queue by pressing the hand button, which is at the bottom middle of the screen. And to speak, use the microphone symbol. And re please remember to remove yourself from the queue when you're done. As always, we wish to encourage participation in the working group. The IATf is a volunteer organization depending which depends on your contributions. There are several important actions listed below by level of engagement. The simplest, of course, is engaging on the mailing list. And next, of course, is com making comments at the microphone. There's draft reviewers, which we always need, you know, folks to review drafts. Running code, if you can implement the draft, that's excellent. And then shepherding. For active authors or I should say authors of active working group group documents are encouraged to participate ex to additionally participate in the review of other working group documents in order to increase working group activity slash participation, to reciprocate the efforts shown by others, and to illustrate broad understanding, interest, and thought leadership. And please be aware that the chairs are human beings that may forget and miss deadlines, etcetera, and reach out to us if ever you feel like something's been missed as Thomas did just an hour ago. Thank you, Thomas. Okay.

[00:04:03] **Tarekk Saad**: So my name is Tarek, and I will take the rest of the chair slides. The status of our documents with the RFC editor. So we have had two published documents, Netconf over TLS 30 1.3 and UDP client server. So there are now RFC RFCs ninety nine eight eighteen and ninety nine eighty four. Small round of applause. It's great to see work to progress. We have more in the pipeline. So RFCs to be we're in now in the 10 thousands of RFC numbers. So 10,009, ten, and eleven. And we have a few documents in the RFC editor queue as well. Super. So start status of other post working group documents is shown here. Few of them are submitted to ISG for publication. A few others are waiting for working group shared go ahead. And for trace context headers and trace context extension, they're waiting for me to review the last updates and for the others. Yeah. Thank you. For UDP-notif, and that's in transport review, I think, TSV art with with with with AD. And that's that discussion is ongoing. And notif envelope is waiting for the authors to clear Yang doctor's review. Status of our active working group documents shown here. HTTP notice has been returned to the working group and will be presented here. Other than that, there we have a few working group last calls and active working group documents and documents that have expired. So for now, we won't discuss the expired documents, but that will probably be something that we will need to take care of later and see what are we going to do with them. Thank you. So we have a column here named Shepherds as well. So the documents with a red question mark don't have an assigned Shepherd. The others do. So if you are looking for work to participate or contribute or just interested in progressing this work, contact us and become a shepherd. This this is the agenda for chartered items. So we will first look have a presentation of HTTP based transports, looking at netconf and risk of five candidates, YANG groupings for quick client and and quick servers, netconf over quick. And then we will have presentations for list stagnation, CBOR encoding for HTTPS based transports, and YANG push two. And this is the noncharter items with that have slots this time, error list and error identities registries for protocols, and then operational requirements for network state exchange in an agent assist and network operations. That's the agenda. Let's take this first if there's any agenda bashing. See Rob coming to the mic.

[00:07:38] **Rob Wilton**: Not necessarily to bash the agenda, but a comment on those the UDP notice draft, which is post working with last call. We've just implemented the d t d t l DTLS part of that, and we have noticed there's an inconsistent of how we've implemented versus what the spec says. There's an extra wrapping header that we've not included. And I think we've raised it with the authors and things that said it might be that the draft is the thing that needs to be fixed rather on implementation. So I think there's, like, one open issue that there should be some discussion on just just to make you aware of that.

[00:08:09] **Tarekk Saad**: Can you please send us a I was not aware of this.

[00:08:13] **Rob Wilton**: Can you I might have sent it just to the authors and things, but I will forward the email onto you on and then once this what discussion we can send on for this is what the conclusion is.

[00:08:21] **Mahesh Jethanandani**: Thank you.

[00:08:22] **Kent Watsen**: It's interesting you should say that because the next two slides are actually a first discovery of having trying to implement a document and needing us needing to make an update to the document. Same idea.

[00:08:32] **Rob Wilton**: Okay.

[00:08:35] **Tarekk Saad**: Any agenda bashing? Three, two, one. No. So we put this in in the chair slides because this is now post working group document. I think it's even in the r f c editor queue. YANG library augmented by. So when I implemented this, I found that the elegant way of reusing this grouping in augmented by doesn't work for module state because you have an inter inheritance of a deprecated node, and then you have a non deprecated node, and then you have a deprecated node again. That doesn't work. So the confd compiler, the d map compiler complains about this. P n and does not, I believe, or it did. I don't recall right now. Should have done my homework before this meeting. So I suggested that simple solution is to unroll the grouping instead. It's not as elegant. It's more explicit. The discussion on list from a few of the authors and also Andy, I know, said that let's just skip the module state augmentation. I have no strong opinion. So what does the working group think? Or the authors, maybe.

[00:10:14] **Thomas Graf**: Yeah, Thomas. So my comment was basically, my understanding of duplicated is that it should not be augmented. However, there is I mean, I would have expected in I think it's obviously ninety nine zero seven now that there's some guidance on whatever duplicate it can be augmented or should be augmented in in which cases, but I couldn't find any. So I think that would be worth clarifying also for the future.

[00:10:45] **Rob Wilton**: Robert from Cisco. I'm actually I think that I think augmenting into a deprecated space is fine. I think this is a bug in the interpretation of in yang, and I know there's sort of been two different reviews as to whether it hierarchically bubbles down or not. I hopefully, yang too, we'll fix this and do this sensible thing because it feels to me like the regional definition was is nicer that you just pick up the fact that it deprecates everything underneath. I don't if you if this is what makes people happy, I've got no objections to this either. I mean, whatever goes through, it's just

[00:11:14] **Tarekk Saad**: So it's actually yang next issue 27, which asks to clarify the inheritance of status.

[00:11:21] **Rob Wilton**: I think. But for this one, we should do whatever makes it go forward without making a fuss over it.

[00:11:32] **Tarekk Saad**: So Mahesh coming to the mic.

[00:11:38] **Mahesh Jethanandani**: Didn't put myself in the queue. So since the document is passed to Anna approval, you want me to recall it from the RFC editor queue, that means, to make the change.

[00:11:56] **Tarekk Saad**: As a contributor, I I don't I think we should do what's fastest to publish instead of bringing it back. So if they can if you opt for rolling out it, then the semantics doesn't change for the document. If you opt to instead remove the deprecation, the semantics change. But so as a as a contributor, I don't mind either way raising this complaint.

[00:12:23] **Mahesh Jethanandani**: Okay. So if it's not semantically changing the model in any way, maybe then we can handle that RFC editor level I think so. Where we will recommend to them the changes they need to make to the model. I think that's sensible. And

[00:12:45] **Tarekk Saad**: we're going you're next up to present. HTTP based transports for YANG notifications. Mahesh, take your way.

[00:12:56] **Maher El-Aawar**: Thank you.

[00:12:59] **Mahesh Jethanandani**: Alright. So this document was sitting in ICE well for more than a year, not because of the draft itself, but because of the fact that it was dependent on the HTTP client server draft, which was I ICU stay stuck for equally long period of time. Anyway, can finally unjammed that particular draft which allowed HTTPS notif to move forward. But then, even sitting in that state, I have a couple of questions that were raised in the working group regarding the draft, mainly coming from one of the drafts as you can be presented later, the HTTPS note of SIBO draft, which wanted to encode a new the encoding format that it wanted to support was not something that the draft this draft was supporting at that point. Sorry. Too many support words. Anyway, so that's the document history that I just talked about. So it's now back in the working group to make the necessary changes. And what we are asking is, I believe, we have addressed most of the changes that were requested. So we'll we can talk about what those changes are. Okay. So the first thing was the media type correction. The original draft had only support for application slash JSON. And the idea was that if we wanna support YANG format, then we probably better off supporting application YANG data plus JSON. So that was on same thing for XML. The original draft supported application XML. He asked us to move it to Yang data x plus XML. The second was the capability structure. Initially, it was more prose than normative text. So that kind of left it a little ambiguous. So the capability structure now follows as a structure defined in a Yang module. And, of course, it uses RFC eighty seven ninety one definition for that. The Yang module endpoints have been restructured. And then there was a question still left with what to do with the legacy support for fifty two seventy seven. So a new section was created to essentially move what was there in the original draft to section five and call it legacy support. The capability works URIs are both corrected and references were updated. Okay. So if we were to look at the actual changes, so in dash 15, we had the capabilities exchange, which talked about application XML and application JSON. That now will talk about application YANG data plus XML and YANG data JSON. Similarly, for the relay notification, we are we made the content type change from application XML to notification sorry, to YANG data XML. The change number two, formalized capability structure. On the left, what you see is kind of a loosey goosey definition of what that normative definition should have been. So now the in 16, we are actually talking about a Yang module that has an SX structure defined for what the list of receiver capabilities is. It's a leaf list. Alright. Change number three, restructured the Yang module endpoints. Again, each endpoint now carries an independent TLS and URI configuration on the right side that you see. Reliance with the updated ITF HTTP client server module structure that I mentioned briefly. And then, of course, the base configuration encoding has been added. Alright. The change number four, new section I talked about, this is the legacy stuff that we had. Alex recommended it that it'd be a dedicated section, And and that's agreed with it, so we moved it to its own section by itself. It's think of it as a purely additive thing. Doesn't change the behavior for younger publishers, really. Alright. So if if you were to look at the legacy support, it initially just did a get to learn the capabilities of the receiver. And then thereafter, it sent any notification with content types at the application XML. Same thing with relay notifications, but the notification would be posted and would get back more content. Alright. Capability, you are in references. So these these are corrected. And and in addition for the fifty two seventy seven Notif, That's a new capabilities that was added. The references that were updated are on the right side. To ask at this point is that we believe we have addressed most of the issues that came up and that we probably need a quick working group last call just to make sure we have addressed all the issues.

[00:19:01] **Kent Watsen**: And already received one comment from Alex before we did the working group last call. So we'll take that as into account as a part of the working last call comment.

[00:19:10] **Mahesh Jethanandani**: Okay. Yes. So we'll address that, and then maybe you can run the working last call. K? Any questions?

[00:19:22] **Qin Wu**: As a shepherd of this draft, I will also review the update and update the write up accordingly before sending to IST. Would Would that that be helpful?

[00:19:31] **James Cumming**: Yes. Thank you. K. Thank you. Thank you.

[00:19:43] **Tarekk Saad**: So, James, netconf-restconf private candidate data source.

[00:19:51] **Kent Watsen**: Thank you.

[00:19:52] **Tarekk Saad**: You're welcome.

[00:19:54] **James Cumming**: Alright. So this is a bit of an update. The idea here is to give anywhere on the recap of the solution and the problem, and then go through some of the outstanding points as we are we're aware of them when we did the slides a few days ago. So just as a recap, the problem here is that model driven networks provide a shared candidate configuration to make data to make configuration changes, but multiple sessions can edit that candidate at the same time. So you could have a situation and and often do without any protection mechanisms where you may end up committing changes from another client. So locking provides some solution to that, but in turn creates other unnecessarily kind of serialization, particularly for kind of automated interfaces. And particularly as often different sessions are editing different parts of the configuration anyway. So the solution provides a way to provide independent parallel configuration instances. They are actually all references candidates rather than separate data stores at the feedback of the working group, and they can be manipulated in isolation. And we've also provided definitions of what a con conflict is and how to resolve those conflicts. So the draft's been around for quite a while now. It was adopted in 2023. The latest version was from earlier this year, 2009, and it's had reviews from both ops director and young doctors. But some while ago now at, the 2006 version. And all of those comments, either have been addressed or will be addressed in this presentation. So it's been in working group last call for over a year now, and there were a few outstanding minor comments which we're gonna cover now. And I'm aware that there may be some additional comments coming in as well as, you know, we'll see the the meetings kind of bubbled bubbled it to the top again. So so our plan is to produce a zero ten, just to finalize all the decisions, ideally made in this meeting, and then we'll obviously confirm those with, everyone on the list. So comment one, there was a comment on the relationship to the shared candidate that it was unclear whether private and shared candidates can coexist and whether shared candidates was really a prerequisite for private candidates. So I think it's a two part question. The draft is written in the spirit of them not coexisting within the same session, but then being able to coexist across different sessions. So the the all the way through the draft, it's kind of written in that spirit. So we've we believe that that's that's covered well enough in the draft, but I think if there's an objection to that and we feel that it isn't covered, then it would be great to hear from you ideally in the meeting, but if not, straight after. The shared candidate as a prerequisite, this is kind of a yang issue. So we are using the RPCs from ITS netconf, which is yang one zero. It enables some of those with the candidate feature flag. And the private candidate feature flag, therefore, can't be added to that same base. We don't have the kinda and or or nomenclature in one dot zero, and we didn't wanna update everything to that effect. It also means that both NMDA and non NMDA clients can can utilize this as well. So that's question one. I guess we should Okay.

[00:24:01] **Kent Watsen**: Stay on that.

[00:24:02] **James Cumming**: Yeah. So I think, Kent, you were probably about to say, is there any objection to any of these updates? Exactly.

[00:24:11] **Qin Wu**: Thank you, James. I recall I read this comment a long time ago. So as I try to understand your response, so are you referring to that for the client that does not support the private candidate? The server will, like, still provide the shared candidate for the client to use it. Right?

[00:24:28] **James Cumming**: So a lot of the RPCs today are protected by the candidate feature flag. And in order to so in order in order to get some of those RPCs, you need to have candidate turned on. So we need that candidate turned on anyway, to get access to some of the RPCs, and we can't add another feature flag to the same statement, in a kind of or situation there. So it ends up being an and in one dot zero only. That was fixed in one dot one. So we could rewrite the entire ITF-netconf to one dot one and add those things, but we were trying to not be impacted to the main netconf spec, particularly as we know there's another netconf coming along at some point.

[00:25:14] **Qin Wu**: Go ahead.

[00:25:16] **Rob Wilton**: I was just gonna say, I think you got the right solution here. I assume that I think this is pragmatically the right path for now. And then when Yang two comes along and Netconf next comes along, that'd nice time maybe to get rid of shared candidates and to decouple these or something. But for the moment, I think this is sort of almost the only thing you can do that works.

[00:25:34] **James Cumming**: Yeah. It's the it's the it gives us a solution right now with the least impact to the rest of the infrastructure.

[00:25:41] **Qin Wu**: Yes. So another I not so why you say about the limitation on if features? So would the if a feature candidate also apply to the private candidate data store? I

[00:25:52] **Maher El-Aawar**: mean, do So

[00:25:54] **James Cumming**: so at the at the request of the working group, there was no private candidate data store. That was removed from the draft some while ago in replacement for the candidate data store being reused with the capability. So that was a change that the working group requested a few releases back now. And so we migrated away from the original discussion. The very first draft had a private candidate separate data store, but we migrated away from that following direction from the group to a a place where the candidate data store is the only reference data store. And whether or not your session is in private candidate mode or shared candidate mode is defined by the capability you you negotiate or send.

[00:26:37] **Qin Wu**: K. Thank you. I think that makes more sense. Yeah.

[00:26:41] **Kent Watsen**: I heard no objections. So

[00:26:46] **James Cumming**: the next comment was from the review, which is a little while back, so I know that the draft has changed since. But it was about the compare operation on private candidates relying on and I I believe it was more of a a suggestion, rather than a that something needed is changing in the draft. It sounded like it was more a suggestion of another alternative we could do, where we would create a checkpoint and recovery time stamps that you could roll back to a certain point, etcetera. We had decided that that wasn't in scope, which is why we had kinda taken the approach we had. Each session has the option to kind of update or discard their, candidate. So, ultimately, if you don't wanna have that candidate or commit it, you can discard it and start again. So I don't know, Chin, if that's sufficient to address your question.

[00:27:54] **Qin Wu**: Yeah. Or or, you know, I think, you know, you added these updated time stamps. It seems introduced, like, some kind of state for mechanism. You know? So, you know, I I agree this, you know, out of complexity. You can support these state stateless operation, so I agree this approach.

[00:28:17] **James Cumming**: Okay. Perfect. Thank you. Alright. Comment three. So metadata for an in conflict marker. This was, again, from yourself. It's a a suggestion that that does make a lot of sense, but it then has an additional requirement on the metadata draft being implemented as well. The the question I think you explicitly asked is, should we propose it as metadata annotation or declare it explicitly as out of scope? So we would like to say that this is explicitly out of scope, but I think if anyone has significant difference of opinion there, it would be would be good to hear. And I guess, Chin, that's that's you again. So I don't know if you're okay with this.

[00:29:16] **Qin Wu**: Yeah. I think that both comments actually really motivated, you know, provide a better observability. Right? But, yeah, I I have no strong opening up on this. I think you consider these out of scope. Should should make it as express explicit in the documents. Yeah. That's fine. Yeah. Thank you. K.

[00:29:35] **James Cumming**: Thanks. Is

[00:29:39] **Rob Wilton**: there is there a bit of ground alternative here of actually specifying the metadata annotation but not required to be used? As in saying, here here it is. You want to use it, but you you don't have to do it.

[00:29:52] **James Cumming**: Yeah. Yes. That certainly would be an option.

[00:29:54] **Rob Wilton**: Because I think the one thing I'm concerned here and, again, I think one of my comments here is about the errors not being too clear how they returned is that in the failure path

[00:30:02] **James Cumming**: Mhmm.

[00:30:03] **Rob Wilton**: It feels to me that that this the spec is a bit under specified in places, and you're not gonna get the interrupt you need.

[00:30:09] **James Cumming**: Okay. Yep. Sounds good. Alright. We'll we'll consider that as for for the zero ten as well. Thanks. Conflict resolution. Rob, this one was from you. You disagreed with the operation must trigger an automatic update and must fail, respectively, of the system wide resolution mode. You said that the commit should not fail if auto update is in effect. So this is where a system has, for some reason, decided that a commit to any from any session should update all private candidate sessions, automatically. And, I think our so I and when we hear the the use case for sure, I think the question I have is if so we have a a default resolution mode. But if you wanted the default resolution mode to be for almost everything fail on you know, so it would fail if there was a conflict. How do we deal with a different resolution mode for for this auto update behavior, and do we need to specify an entirely separate auto update default resolution mode? Or should we mandate that if you're using auto update, your default resolution mode must be one of the other two?

[00:31:45] **Rob Wilton**: So two thoughts, and they're separate things. So, yes, I think maybe if you're an auto update, possibly you have to mandate that the auto up the resolution mode is one of the other two. But, actually, I think for me, if you got auto update, you never the update that you do at this point has to be a no op because you've already done the update whenever the last change was made. So so there's update that'll ever occur here.

[00:32:11] **James Cumming**: I don't think that's the case. What? So if you are in one session and you've made a bunch of changes Yeah. And another session makes a bunch of changes Yeah. They commit.

[00:32:22] **Rob Wilton**: Then you

[00:32:23] **James Cumming**: they do the auto update at this point into the this session over here. Yeah. So at that point, that's where this applies. But this is on a commit operation? The auto update is not on a okay. Is that the piece you're I

[00:32:36] **Rob Wilton**: So for any commits

[00:32:37] **James Cumming**: Okay. I misunderstood your your particular use case here. Thought you're on the underlying auto update piece of the commit.

[00:32:45] **Rob Wilton**: That one, again, I think, again and I've that's some the comments I've made in the late my latest notes and links to you.

[00:32:49] **Bo Wu**: Uh-huh.

[00:32:50] **Rob Wilton**: Yeah. I think that that, it might make sense that you don't that you don't ever have the explicit failure mode that you force this auto update, you're forcing it to resolve one way the other, I think. And it's I I need to think a bit more. But for this one, it's specific for commit. I think it's always a no op, and the draft could be clear on that regard in the auto update mode. Okay. And then it the problem goes away.

[00:33:11] **James Cumming**: Okay. That's fine. We can make that clearer. That one that one's okay. It's easier. And then Michael had the comment about that we mentioned delete config, but the RPC only allows startup or URL data stores, and our young model doesn't augment it either. Good good comment. Well picked up. It's an oversight hangover from when we initially had the named private candidate data store where we would have augmented into different things. Our suggestion here is that we stick with what we already have for the rest of the protocol and don't augment into duly config, and we'll remove duly config from the draft. So, Michael, I don't know if that's sufficient for you.

[00:33:59] **Kent Watsen**: I don't think Michael's here.

[00:34:01] **James Cumming**: No. He's not, actually.

[00:34:02] **Kent Watsen**: I know he registered for

[00:34:03] **Rob Wilton**: On-site, but

[00:34:04] **James Cumming**: I don't see him. Maybe you're online, Michael.

[00:34:08] **Kent Watsen**: No. He's not.

[00:34:09] **James Cumming**: Okay. Alright. Then we'll we'll deal with that one on the list. They're the updates that we had outstanding. I know that Rob's just done another review and has some more comments, which we'll address after meeting. But we can address some of them now if if you want as part of q and a.

[00:34:32] **Rob Wilton**: Well, I was gonna bring them to the mic now.

[00:34:35] **Mahesh Jethanandani**: I don't I

[00:34:35] **Rob Wilton**: don't think it's fair on you, and I don't have my head. But I have to say during this week or this time for us to chat, if that's useful

[00:34:42] **James Cumming**: Yep.

[00:34:43] **Rob Wilton**: Then I can make some time.

[00:34:44] **James Cumming**: Perfect. Yeah. That'd be great. So then, the kind of going forward, there's some very minor updates for some of the language clarification pieces. I think we now know where we're going with, all of those from this meeting. There's obviously Rob's comments to now look at as well. Then, hopefully, a a 10 release pretty shortly after this meeting, and then a question to the chairs is what at that point is outstanding that we need to to unblock before we can move forward.

[00:35:15] **Tarekk Saad**: I think if you clear Michal's and Rob's things, then you're good to go. Right?

[00:35:21] **Mahesh Jethanandani**: Okay.

[00:35:21] **Kent Watsen**: And and just a comment about that chat you might have later this week. Can you please take a summary of the chat to the list?

[00:35:27] **James Cumming**: Of course.

[00:35:27] **Kent Watsen**: Yeah. Yep. Okay. Thank you. Alright.

[00:35:50] **Tarekk Saad**: Okay. So my name is, and I will present the work on the end groupings for QuickClients and QuickServers. Let's go. So the introduction to this. For a few meetings now, I have been presenting this work where you can where where it basically takes the TLS client server and UDP client server, puts it into grouping together with registry content from quick versions and quick transport parameters registries. And this work is used by Netconf over quick in a YANG module to augment into the Netconf client server YANG module to be able to configure Netconf clients over QUIC or Netconf servers over QUIC. So the updates so far have updated the initial Yang Yang Yang modules from the registry and actually added the quick versions to the groupings. It wasn't there. There was a typo where it said leaf instead of leaf list for the transport parameters leaf list using the security template from r c nine zero nine zero seven, using the yang modulating Yang Semi and Yang module file name convention work to put in the revisions on module file name and added operational considerations from their working group last call and some editorial fixes. So this document is now in working group last call. There has been one review on list and one review in private from Robert Varga. I don't know if you're here, but it would be good to have that review on list

[00:37:32] **Kent Watsen**: as well. He's not here.

[00:37:35] **Tarekk Saad**: No. But that the next steps are I mean, the raised issues are closed, so suggest to close the working group last call.

[00:37:53] **Kent Watsen**: Any comments, questions, concerns, objections, tomatoes?

[00:38:03] **Rob Wilton**: I can't I can't remember the stock. I might I think I've reviewed an earlier version of it, but and I apologize you haven't done a a last call review. Did you say you've had one review on this and one not? Yes. Yes. I'm wondering whether it's worth just trying to chase to get some more reviews in because because otherwise, it feels a bit weak. Is there any any thoughts?

[00:38:20] **Tarekk Saad**: I agree. So do another review, please.

[00:38:22] **Mahesh Jethanandani**: I will do.

[00:38:23] **Rob Wilton**: I will do. If the working group last was still open.

[00:38:26] **Tarekk Saad**: It is. It is. It is.

[00:38:31] **Mahesh Jethanandani**: I can't see the queues. Mahesh, talking about reviews, that private review that you did receive from Robert, do you without necessarily disclosing the email, do you agree with the comments? Is that something you can

[00:38:46] **Tarekk Saad**: address still? So I didn't disclose it not because it's sensitive or anything,

[00:38:51] **Rob Wilton**: but it

[00:38:52] **Tarekk Saad**: was forwarded from a review of HTTPS Notif, I think. So it was difficult to parse what was actually the the thing for quick client server.

[00:39:02] **Mahesh Jethanandani**: Okay.

[00:39:03] **Tarekk Saad**: And I if I recall the comments, it said that you should be able to not have these enumerations from the quick transport, but just be able to put whatever bytes you want there. And I don't think that was the what the working group decided on. Okay.

[00:39:20] **Kent Watsen**: We did ask him a couple times to repost his review to the list, but he didn't.

[00:39:26] **Mahesh Jethanandani**: Right. So yeah. I I understand that we we can't if he does and doesn't want it public. My question was more if we agree with it, then the change can still be made if

[00:39:38] **Tarekk Saad**: Yep.

[00:39:38] **Mahesh Jethanandani**: The work group agrees with it.

[00:39:40] **Tarekk Saad**: Yeah. So I don't the working group previously did does not agree with it, and he was going to publish it but didn't have the time to put together the mail. So but I'll reach out to Robert again.

[00:39:52] **Kent Watsen**: Mhmm.

[00:39:56] **Tarekk Saad**: There's someone else in the queue? Yes. Mark. Mark.

[00:40:01] **Marc Blanchet**: Mark, I did the review. Thank you. So am I the only one that's in that you were referring to? Okay. Well, I guess I'm not a good guy too. I actually review Netconf because I'm not a Netconf expert. But, anyway, I think I wrote this, but it would be good, I think, to have really quick guys, you know, experts, implementers to review that. You know, I guess, formally, you could ask a TSV, you know, review or something, but I don't know. You know, we're we're touching inside the state of the quick stack, and I wonder if people will say, you know, this parameter and this one, you know, don't touch it or I don't know.

[00:40:51] **Tarekk Saad**: So process wise, how should we do this? Should we raise for an early TSV art review, or should I post it to the quick working group? What do you recommend? Let's share. We should

[00:41:02] **Kent Watsen**: do an early TSV art review. Okay. And and I completely second that comment because the HP client server draft got stuck in the for two years because we basically didn't do this step. So

[00:41:17] **Tarekk Saad**: k. So the next step is TSR review. Mhmm. Maybe young doctors as well.

[00:41:23] **Mahesh Jethanandani**: I don't know.

[00:41:26] **Qin Wu**: Yes.

[00:41:30] **Kent Watsen**: Next slide.

[00:41:31] **Tarekk Saad**: Yep. Yes. That's it, Doug. Thank you.

[00:41:34] **Kent Watsen**: Right. I think you're presenting again, aren't you?

[00:41:37] **Tarekk Saad**: No. It's

[00:41:39] **Kent Watsen**: okay. Okay. Okay.

[00:41:47] **Tarekk Saad**: So let's come forward quick for with in the agenda, or did you move?

[00:41:56] **Rob Wilton**: Sorry. Did

[00:41:56] **Kent Watsen**: I do it wrong?

[00:41:57] **Mahesh Jethanandani**: Yeah. I think so.

[00:41:59] **Tarekk Saad**: Go next. No. Not now. No. No. No. So it's not coming forward quick. We're watching.

[00:42:16] **Bo Wu**: So hello, everyone. I'm from China Mobile. And here, I will report the update since meeting about the that come for over quicks draft. And for the section five, we end one sentence. You know, we have a lot of discussion on the call home. But, of course, I will raise some discussion later. But from a co author's perspective, we think now the detailed description of the call home, we would like out scope of this draft because we need more investigation on that. And for the section nine, we modified the young model text because in version seven, we introduced some mistakes, and we restore the text about the model. So now the latest version, that is correct. And about the security considerations, that is section 11. We add the second paragraph. You know, we the for the n q, that is based on the quick, and we end the quick's access information. And about the discussion, you know, for the call home function, that is really important. So we have two options for next step. The first one is we prefer. So, you know, currently, the netconf over SSH and the netconf over TRS in the they did not include the call home features. You know, this draft, in fact, is technically equivalent to the both. I think that is reasonable we don't include the call home functions in this draft. And then the second factor is that, you know, for the quick, if we wanted to introduce the call home function, in fact, we don't have the mature solution this moment. If we want to end it, we need evaluate several candidate solutions. We list some here, but that maybe we need a more implementation test to verify that. So the solution now is not mature. But for operators, from my point of view, you know, the and we'll queue now is important. And if we can use it this moment, that's good. And the call home, we can add that function later so we can separate it. This is the option one. And then the second option is that we now decide which solution for call home, and then we verify that. When it's mature, we let this draft go ahead. So this is the basic our options, and we can talk about the options.

[00:46:50] **Kent Watsen**: Yes. We we have the queue, and I'm first in queue. So Kent as a contributor. So just to to rephrase this, so when Netconf was first published, there's the Netconf specification. There's a binding to SSH specification. There's a binding to TLS specification. And then r c eighty seventy one, which was the call home, came out later. And I think your idea is, well, let's just do the binding to a quick specification and then perhaps do an eighty seventy one biz that or not. It could be a different document, but it could be an eighty seventy one biz that then tries to explain how the call home can be implemented. So that's my first comment. Just making sure I understand it correctly. Right?

[00:47:36] **Bo Wu**: Yeah. Got it.

[00:47:37] **Kent Watsen**: Okay. And secondly, I have been running around talking to quick folks and whatnot. And to be honest with you, there is no light at the end of the tunnel for quick like, reverse quick.

[00:47:49] **Rob Wilton**: Mhmm.

[00:47:50] **Kent Watsen**: I I mean, it's probably years away. So if we hold this document for that, maybe we could be waiting for one time.

[00:47:58] **Bo Wu**: Yeah. Maybe we need to take a long time before that and righty. Yeah.

[00:48:10] **Mahesh Jethanandani**: Mahesh, so thanks, Kent, for laying out and clearly giving us the state of where quick is today. So if, clearly, there is no reverse quick option, then I I feel that we don't have option two that he's suggesting. So we only left with option one. And I guess the advantage of that would be that whenever and if Quik ever implements reverse, some way to do the reverse communication, that's when this work can be picked up. Is that a fair way to look at it?

[00:48:51] **Balazs Lengyel**: Mhmm.

[00:48:51] **Rob Wilton**: Yes. Based on on Kent's Kent's comments and your comp saying that we can deploy this now, I think option one seems the obvious choice, so I support this.

[00:49:02] **Bo Wu**: Yeah. Thank you.

[00:49:04] **Tarekk Saad**: So full disclosure, I'm a coauthor of this draft as well, but I there there are not defined well defined options to do the you do connection in one way and then do the reverse authentication. There are several as discussed on the slide options of and guesses. Can this work? Or you just cut through all that and do authentication in the netconf layer. So, I mean, it's software. Right? So it's just it's possible to bend it to your will to make it work, but I'm also starting to lean towards let's do a proper solution later on when when it's available.

[00:49:48] **Kent Watsen**: Okay.

[00:49:49] **Tarekk Saad**: So defer the the call homework and publish publish this as it's useful now.

[00:49:54] **Mahesh Jethanandani**: Yeah. Either way, just close on this. This has been going on for a couple of meetings. Yeah.

[00:50:00] **Kent Watsen**: So, hi, this is Kent again. I'm putting myself back in queue as an individual contributor. So currently, with the RFC editor is the h t p sorry, the netconf client server and the rest of client server drafts. Both those drafts define mechanisms for configuring call home. And I don't think they apply to either RESTconf or to Netconf. So even though those model those Yang models suggest that you could configure call home over QUIC, it's probably not true. Just throwing it out there. Some sort of errata may appear later on.

[00:50:46] **Bo Wu**: And maybe we need need some new contribution, and then the call also can contribute or something. Yeah.

[00:50:54] **Kent Watsen**: And it it may be something that we could look to do in those documents. For instance, we could specify what version of netconf it is or what transport's been used and and only allow the configurability of the call home mechanism if it's not using a quick basic transport.

[00:51:12] **Rob Wilton**: My suggestion is is don't touch them. I I wouldn't open the can of worms or anything. I think you've identified this is a not a issue. I would just ignore it for the moment, pretend that you didn't know about it in a sense, and then spend the time to to come up with a proper solution and things like that. I've tried preempt it.

[00:51:30] **Kent Watsen**: Yeah. Just to respond to that quickly, there is light at the end of the tunnel for doing RESTconf reverse RESTconf call home over quick. There actually is a something that's being discussed earlier yesterday, I think. It was the PTTH buff session. And so PTTH is reverse of HTTP, and you can see where that goes. So there's light at the end of the tunnel on that

[00:51:56] **Bo Wu**: one. Yep. I have still two slides left. So

[00:52:04] **Kent Watsen**: Yep. Go ahead.

[00:52:05] **Bo Wu**: Yeah. So I think the next step will improve the draft, and then we would like a call for the working group last call. Yeah. Thank you.

[00:52:19] **Kent Watsen**: Okay. Great.

[00:52:20] **Rob Wilton**: Thank

[00:52:20] **James Cumming**: you. Thank you.

[00:52:26] **Tarekk Saad**: Now, Qin, for Dressconf-netconf.

[00:52:37] **Qin Wu**: Okay. I gave a update list pagination for young driven protocol. We have a three draft and list pagination based draft, list pagination netconf extension, list pagination, less computation. So first, list pagination based draft, the current version is 13. And just before this meeting, actually, we also get together and to address our all the remaining comments, especially from the younger review. So for some of our standing issue, we come up with some proposal and also engage Lara and Andy to review the the the change review the proposal and get agreement so incorporated into this latest version. So several update that we made. Firstly, is allow using undefined prefix in the expression based based on comments. And, also, we also based on suggestion, we support optional conditional node identify and also specify some default strategy. For example, for some entry for, you know, the the for specific, you know, sort of by value that will be placed after the the entry with sort of by value default value. And another change, we actually replace the extension with the live in the system cap capability because, originally, we use the extension to document the several capability for domain index support or constraint and and other. But we don't use this, so we think there's a mistake. So we fixed this. I actually replaced with the leaf in the system capability. And in addition, we for the where leaf, we define the default for where filter, and we we also use a union for this where leaf, we support x pass one dot zero or unfiltered. And we also change the feature name into sort by and add the when statement for the local leaf and and further define where feature and and where feature for this where leaf. Another important change is error information. We have three draft, and the error information, you know, has to be distributed in since in three draft, actually, there's some redundancy. So we move these error error information from the this presentation, restconf job and thatconf job to the base job. And we also add cursor offset in the choice statement and, you know, support of both. And last day is only allow the query parameter in subsequent query by using the cursor are naming sublimit. And other change, actually, is some housekeeping change and most are actually editorial. The second draft, the netconf, we're extending draft to the current version is 12, and we just post this draft, know, when the submission don't open because we forgot to, you know, post this version before the ITF submission cut off. So you you can see the the training we made, actually, based on the any comments, actually, for the netconf draft draft, you know, we use the query parameter. This usually define in the draft, so we it caused some confusion. So we replace this query parameter with RPC input parameter. And in addition in addition, actually, based on any suggestion, actually, add a a specific rule actually to evaluate the WER based on the validation rule defined in the net netconf proxy in section eight nine one. And we also declare prefix in the where standard as a XML namespace prefix. Is it based on discussion with. And, also, we, yeah, try to move all the error information from this netconf extension job to the base job. RESTconf extension, actually, we made a, you know, small editorial change, but one one change is based on the young doctor review is apply the prefix bounding to all the young model and highlight the perfects is module name based on the data's input. So and similar to the netconf job that we move the error information to the list page engine based job. All the other change are editorial, and we believe, actually, for this three job that we resolve all of the issue, but we forgot to, you know, merge in one RPR, actually. This depend on one of our author to review the the change. I think it already merged. Right? Yeah. So but we we think we still need to spin on this cursor related part. Actually, for example, do cursor all always or sometimes or never embed a page size, so we need to find a solution. For example, you know, the parameter. The second is for, you know, the the cursor, we support both offset and cursor. And so we want to add a feature to both these, you know, offset and the cursor. So really make a choice mandatory too, and we want to sort of say some feedback for people whether people have different sort or we can, you know, resolve the remaining this cursor related part and close this issue. So for the list pagination based draft and also maybe including the record retention, so we make a substantial change if you take a look at the ID differ. So probably it's a shorter what can we last call for this one? After that, I think we are ready for publication. So that's it. Any comments?

[00:59:18] **Kent Watsen**: Yes. As chair, we have time in our agenda or schedule. We can discuss this. I think it's important for us. This is a a a working group adopted document, and we're supposed to be progressing documents. So let's spend some time here. It's sub bullet points two and three and then major bullet point two that we want to fall into right now. And I think from let's first talk about major bullet point number two, Mahesh. Per and I, both authors, we have to recuse ourselves. So you have to make the judgment call as to whether or not a a secondary working group last call has to occur. I mean, there may be some additional changes when we start talking about sub bullet points two and three, which will make the ID diff even larger. But be aware that there's some substantive changes that have been made, and you may want to have another word. Okay. Now as a contributor, I think I'll help Jen talk about sub bullet point number two. I guess okay. So with with cursors, when you I'm I'm not sure how many people here have implementation experience with cursors and databases, but, typically, you know, you you do your query. You you have a where. You have a sort. You have the directionality of the sort and and get back a cursor. Now, also, when you create that cursor, you might also pass what's your page size. Right? You know? And then when you say next like, when you create the cursor, you say, I want my page size to be 10, and you say next, and you just automatically get the next 10, next 10, next 10. You don't actually pass the limit parameter again and again. That's one possibility. That that's the the never option. In but in other implementations, I think database implementations, the cursor doesn't embed or encode the page size, thus enabling dynamic changing of the size of the page. So for instance, if it's in a web browser and client changes the size of their web browser, now their page size is different, and it allows them to so the so the limit parameter is not baked into the cursor. We're unclear what is the best. I asked Gemini AI, and it seems to suggest that the dynamic paging is more common. But then PER did some follow on investigation, and it became unclear.

[01:02:01] **Tarekk Saad**: Yes. I checked database document for SQL databases, and they seem to support both or be their only limit, I think. But you're you're again, it's software, so you're able to do whatever you want in your database layer and create a pitch. So my experience personally is that I've always been able to put the limit on the subsequent request. But yeah. Does anyone have a strong opinion on this?

[01:02:44] **Rob Wilton**: Roberson, strong opinion, no. I mean, I it's been a while since I reviewed this document. I haven't reviewed it again. Just think of my overall comments. I think the whole their whole solution has a fair amount of complexity in it, I think. It's not trivial or simple. So I would urge towards going towards simpler bits rather than so having choosing one rather than having both options is what my my gut instincts would be.

[01:03:09] **Tarekk Saad**: Yeah. I can say that cursor based pagination for SCIM, RFC ninety eight sixty five, if I recall correctly, they include the limit in the you actually have to send it, and it has to match the initial query. So if in in your initial query, you say that count is 10, then you have to also produce that is seems like unnecessary but you have to always produce it in every query that you make. And it has to match 10. If it's 11, it's invalid error. You you'll work.

[01:03:38] **Rob Wilton**: So that just makes you wonder and, again, I need to think about this is if you don't include it, does that mean that you you have to maintain some context, whereas you do include it, you can be context free? I

[01:03:50] **Tarekk Saad**: would say so. Yes.

[01:03:51] **Rob Wilton**: Then then in my mind, having the context free one gives you more flexibility as other small amount of pain for the client to include the extra fields. It would mean, I doubt, that many clients might not check that it that it doesn't maybe that's why having a flexible value is actually then easier because you don't have to check it's the same as the original one. And

[01:04:11] **Tarekk Saad**: So it's a bit of a different use case. So either you do, say, offset or offset and limit, and then you sort of have an easy way of paginating the stuff

[01:04:22] **Rob Wilton**: Yep.

[01:04:23] **Tarekk Saad**: And random access, basically. That's the, like, main use case. If you do cursor based pagination, you instead do a, like, a sequential load of paging it. Yeah.

[01:04:36] **Rob Wilton**: And and this is just a comment. Actually, you're talking about working with Oscar, which is obviously Mahesh's decision. I just said to him is that it was a long time since I reviewed this. If another working with last call came up, I would review it again with fresh eyes and then and just see if that's helpful.

[01:04:51] **Kent Watsen**: I'm not sure if I got a clear answer for that. Did you? Like, what to do?

[01:05:00] **Tarekk Saad**: Yeah. So your suggestion, Rob, was to not include limit in the cursor, but instead because that will put context on the server, but instead keep it for the client to be able to or who who would you who want who should keep the state, client or server?

[01:05:20] **Rob Wilton**: I I what I was trying to think of is when the server and I I can I had to think about the draft and how the cursors would be implemented? I don't know whether you have to mains maintain state in the server for that cursor. Or when you respond back to the client, there's enough context information that when the next request comes in, it can pick it up and carry on. But I don't know. As in if it internally holds a reference to the next item or something that's encoded.

[01:05:45] **Tarekk Saad**: Yeah. There is next and previous links to or cursors to the next cursor. But there is in in in the scheme pagination, there is also, like, the number of items account. I don't recall it. I think it's in the results set, right, for this as well.

[01:06:07] **Rob Wilton**: So I think I have to look at the draft and then think about it. I can't give you a useful answer here. I think it would just be nice.

[01:06:12] **Kent Watsen**: Okay. And and as an author, I just wanna when we talk about this server containing the state, it's not well, yes, it's the server, but it's actually the persistence layer inside the sir inside the server. Like, when you create the cursor, your the persistence layer is creating the cursor. And and do do some databases, you know, remember what the initial limit was? And so we're bound to like, if any implementation wants to use that database, then they have no choice. They the it's it's a server bound limit. And

[01:06:43] **Rob Wilton**: for us, where when we have certain states up, there's no there's no separate formal, like, SQL data to the back end. The it's just a data store storing that this information. So we'd be implementing it at the time. And I don't know whether we would create store state for the cursors that you then have to have a timer to clean them out over a period of time if they had been stale or whether you're able to effectively have the the cursor state ephemeral as part of the request, like HTTP almost is effectively that you just get the extra context each time you'd have to maintain these maintain these sets session state for this particular cursor. I don't know.

[01:07:20] **Kent Watsen**: As a author again, I I know a database expert, but I can ask her what she thinks about this. Unfortunately, she is only expert with SQL based databases. So if anyone wants to use a non SQL based database for their back end persistence layer, I wouldn't be able to help guide the decision for that.

[01:07:39] **Rob Wilton**: Yeah. I don't think we should rely it being SQL.

[01:07:43] **Kent Watsen**: Alright. Thank you. And then for sub bullet point number three, the adding of a feature statement. I think, actually, the idea of a feature statement on cursor came up a few sessions back, didn't it? And the working group felt at that time that we should not have a feature statement for it, that both cursor and offset should be equally viable, and both should be implementable by the server. However, given some of the complexity that we're running into trying to understand how to do cursors here, how to define them, it seems it might behoove us to you know, only expose the ability to do cursors for, you know, when a server actually says it can do it. And then and then but if we do that because right now, if you look at the the top level list pagination draft, there's the yang module, and there's a choice. And then inside the choice is the cursor and the offset. So it's mutually exclusive. Currently, that choice, don't believe, is mandatory true, but we could put a feature statement on both those two options, cursor and offset, and make the choice be mandatory true. So the server has to support one or the other. Well, I'm sorry. It can support both, but it has to support at least one. So then the question becomes, you know, what's the trade off? The trade off is either the the server a server that wants to support cursors does not have to support offsets. It gives the server some flexibility. Right? Cursors are more performant. And, I mean, we should guide implementations towards doing cursors, but they're complex. So but if a server does do cursor, then you it it's doing it's implementing that on the hope that the clients will use it because it's more it's the most performant. It wouldn't want anyone to have to do it off that. So so that's that's option that's trade off a. And then on the flip side, you got the clients, which if we force all servers to implement offset, then you know how it goes. The yes. It's maximum interoperability, but then no one will implement cursor because they know that everyone all implementations will support offset. So it's kinda like x what is that filtering, what we do in Netconf with XML? It's like yeah. No one implements it. Right? Because it was optional. And and sublist filtering is always there, so everyone implements sublist filtering. So but then so the option the trade off b is that all clients would have to support both cursor and offset. And so that's the trade off. Do we do, a, you know, put the onus on the server, or, b, put the onus on the client? And these two authors have differing opinions on what that solution should be. So I'll speak to my preference, and you can speak to yours. Okay. I think we should put the onus on the client. And the reason why is because it's really not hard for the client to do the math to use offset or cursor. It's just very simple for them. It's not much of an onus is what I'm trying to say. It's pretty easy. So I figure it's better to skew that way and then allow those servers that want to be having maximum performance have that ability in the future.

[01:11:26] **Tarekk Saad**: Okay. So I have the opposing view. I think every implementation should support offset. It's almost trivial to include and implement. And I was also of the opinion that cursor should be mandatory as well a few meetings ago. Yeah. So that's where we at. More opinions. You realize you are now the arbiter, Rob. Welcome to the mic.

[01:12:05] **Rob Wilton**: I don't have not sure I have a useful opinion on this. One thought is that you said this the offset's less performance because normally that would get more expensive for us, I think, in our database. We would have to iterate through and count. So I think it where we're using, like, a name key value lookup in various places is significantly worse if it's a large list iterates each time over large relevance. So the one thing I'm concerned about, if you make offset mandatory everywhere and cursor's optional. You're sort of encouraging clients to do the thing that's much worse for servers, and clients wouldn't necessarily care. They'll they'll write some code. It just works. They come they come deploy it, and they're hitting the server in a in a far less efficient way than you might want them to be doing. So I guess I would almost feel like the other way around of maybe using, like, cursor without the offset should be the mandatory thing. I don't know. Maybe cursors are harder to but I don't know.

[01:13:12] **Tarekk Saad**: I think he's favoring your solution.

[01:13:14] **Kent Watsen**: Well, okay. And in part, so one is do all databases implement to support for cursors? All back end systems. We that's a you know, we don't know about that.

[01:13:26] **Rob Wilton**: I I don't know. I'm I'm finished when I reviewed this. I my concern was there's a lot of stuff in this, and there's bits of it, not so much just in the options, but in terms of the extra flags and things and limits and things. And we I was thinking we might implement some of this, but not other bits and be nonconforming with spec where it says you have to implement all these options. Right.

[01:13:45] **Kent Watsen**: And but going back to the performance thing, I just want to speak to why cursors are more performant, because you can almost think there's like a stream or many streams. So inside the persistence layer, it's creating a cursor, but it knows what's the sort, what's the where. And so when you pull on the next page of data, it kinda streams all the information up and only returns that chunk. And so it's it's very quick for the database to do that, whereas you're using offset, it basically has to recalculate, you know, the full WER filter, the full sort filter, the full all of the WER, and then it does the offset jump. And and it throws away the the whole dataset, the result set.

[01:14:21] **Rob Wilton**: Well, it depends. It could cache that result set and then do it efficiently, but it that's the same issues. And internally, for our thing, we what we've implemented is something close to a curse effectively that when you internally now, iterating over these back end data structures, you give it the name of the last thing and say, I want to return the next thing. So that is a n log n lookup to get that item and then return the next things rather than its value through number. So I think it's the offset of one that I've been looked at for. Oh, I don't like this. This is expensive. Whereas the cursor one is pretty closer to what we would do want to do. Does that help?

[01:14:58] **Tarekk Saad**: Yes. I think so. I have another question. You mentioned in passing that do you think there's a lot of things and that you might not implement everything? So I have been against more feature feature flags because I think you should implement all of it. But do you suggest that we should have more feature flags? And if so, now we're actually on time on the schedule again. So So could you if so, please send it to the list what you would like to be able to toggle support for? I I can't remember. I think in

[01:15:31] **Rob Wilton**: my my last review comments, would have potentially said on some of these things, but I can't remember. But I could say could probably just tell you off list on what things we would say, yes. We'd implement those and those. Like, probably not.

[01:15:44] **Tarekk Saad**: That would be valuable. Okay. Yep.

[01:15:47] **Kent Watsen**: Okay. Great. Thank you. Thank you, Jim.

[01:16:00] **Tarekk Saad**: So, Maher, are you ready? You're presenting remote.

[01:16:03] **Maher El-Aawar**: Yes. Am I audible?

[01:16:06] **Kent Watsen**: Should have slide control now.

[01:16:08] **Maher El-Aawar**: Yeah. I do have am I audible clearly?

[01:16:12] **Kent Watsen**: We can hear you. Thank you.

[01:16:13] **Maher El-Aawar**: Great. Cool. Hi. So we'll be presenting the Cboe encoding for HTTPS based transport for notifications. So this draft is an extension to the base draft of HTTPS notice, which was authored by Mahesh and Ken and which the first presentation is also based on. So what they're trying to do is basically define a protocol for asynchronous event notifications, very similar to Netconf event notifications, fifty two seventy seven, but over HTTPS, and they've defined it for XML and JSON media types. And we wanted to extend it for CBER data types based on the previous presentations and experimentation we've done showing how CBER is more efficient in bandwidth constrained networks and sort of trying to standardize CBER as well. So the updates we made since the last idea for mainly to align our draft with the changes that have been made in the parent draft and also wanted to mention some implementation progress. So the main like, as it was presented already, the main few updates were the correction in the young media data types, restructuring the endpoints, and formalizing the actual capability structure to encode by a young schema, which was not defined before, and also separating out the legacy fifty two seventy seven support. And this really helped unlock our implementation for CBERD data type as well because especially, the applicate because according to 9254, when you try to encode a young data CBAR data pertaining to young schema, we have two possible ways of doing it using named identifier keys and schema identifier keys called SIDs. And the only way to communicate it would be to have an additional parameter, like an ID parameter telling what sort of encoding it is using, and that would be only possible when the content type is application slash young data plus c board and not just application slash c board. Now that the base draft has been updated, we can follow the same consistent media types now. We've also updated all of our draft, improved the examples, made some editorial fixes to and also to reflect all the changes that were made upstream. And, yeah, regarding implementations as well, we updated the implementation. We've also been trying to work to include c bar named identifier support in Libyan, which is a young young language data parser and schema verifier, which supports JSON and XML. We've we made an initial PR. We got support from the Libyan maintainers and reviews. And with the help of open source community, we're able to, like, close the PR as well. Yeah. Here are the links to the drafts and the changes that have been made. We basically addressed the previous question and the last idea of regarding the application content header type. And, yeah, we're looking for more feedback and reviews to progress the document. Yeah.

[01:19:42] **Mahesh Jethanandani**: More a question to the authors, really. Is there anything materially left to do in this document anymore? If not, then any reason to wait?

[01:19:57] **Maher El-Aawar**: Nothing in the document so far. Everything's updated. And, yeah, that the document is up to date.

[01:20:08] **James Cumming**: Okay.

[01:20:10] **Alex Huang Feng**: Alex, So well, Ken already said that I sent an email on on for HTTPS Notif. I was asking asking to unbind, let's say, the application message from the transport itself. I think that's important for for YANG push because, otherwise, we are let's say, when we are using HTTPS Notif as a transport, we are defining one different namespace, and that transport couldn't be couldn't be used for, for example, YAMPush two or or other protocols. Right? These may have a few impacts on HTTPS Notif. In regards of the working Roblesk call, I agree with Maesh. Maybe the working Roblesk call on both drafts could be together as a cluster. This might be something to think about.

[01:21:04] **Kent Watsen**: Yes. That's a good suggestion. In fact, we could go ahead and do the working request call on this one if we wanted to, and then become a misref, but doing them together makes sense. It does bring to mind a thought that I've been having with yang push two. And I know the HPS Notive Draft defines augmentations into the subscribed notifications data tree, which only makes sense if you're using yang push one and disappears with yang push two because it's part of that data model, which makes perfect sense. But yang push two would still want to reference this HTTP note of draft in order to pick up the protocol, you know, how to transmit messages, HTTP based notifications. And so there's the protocol bit. And I don't really want to make changes, but would it make sense to I mean, how would you do that? Like, would you I'm speaking to Rob. Would you would you reference the part of the HPS Notif draft, or do you think we should factor out that part and make it be something that then is isolated and easier to reference?

[01:22:15] **Rob Wilton**: Okay. I need to look at that. I I think so that UDP Notif has a similar requirement where it's augmenting the structure, and it's the structure it's augmenting today is the yang push v one version effectively. And I was just expecting that once we get that published, we'll pop publish this version of that document is what I was thinking, and then it would augment into the Ampush v two one as well. So a very simple change to that document, do both. So wondering that's that's what I was thinking. So keep still keep the the independence of the transports, but they just need to have an update. But, I mean, it's another pop publication cycle, but it'd be, like, a small

[01:22:59] **Mahesh Jethanandani**: Mhmm.

[01:22:59] **Kent Watsen**: Change. Yep. I I hadn't thought of that approach, but it makes perfect sense. Thank you. I'm sorry. Can you say your name again? You're not in queue, so I don't know.

[01:23:09] **Tarekk Saad**: I

[01:23:13] **Michel Veillette**: want to ask the authors to edit the examples because the usage of young seats is invalid. They are using allocated seats that are not yours theirs. So I want to emphasize that.

[01:23:28] **Kent Watsen**: Thank you.

[01:23:31] **Mahesh Jethanandani**: Thank you.

[01:23:34] **Maher El-Aawar**: We did mention that we're using an example allocation and not the actual allocated seats, but we'll take a look again and try to revisit it. Thank you. We

[01:23:45] **Kent Watsen**: can always ask for early allocation.

[01:23:52] **Alex Huang Feng**: Alex again. Yeah. I I just this week, I got in touch with the seat experts, they told me to whenever we are using seat files and the working group is has a detected adopted the documents, we can already talk to Ayanna to all reallocate those SITs. So I just wanted to, yeah, give an update on the working group whether every everyone wanting to to use SITs and the document is adopted and stable enough, let's say, we are encouraged to actually go to Ayana and reallocate those.

[01:24:27] **Kent Watsen**: Okay. Perfect. Thank you. Any any last comments on this document? Great. Thank you.

[01:24:42] **Tarekk Saad**: So Yang push two.

[01:24:43] **James Cumming**: Rope. Okay.

[01:24:49] **Kent Watsen**: Okay.

[01:24:52] **Rob Wilton**: So let's go through I'll just do Yank push two. So on behalf of the authors, just a quick recap. I think most people who know what yang push two is we're trying to there's yang push. Lots of people have implemented it or we've put something very close to yang push, but not quite that close in various places. They deviated from it. YangPush had lots of complexity in various places, and what we're trying to do is create an updated simplified version that all the different vendors are happy to implement with a bit more alignment to GNMI in places as well in terms of that. And we're working with the operators as well to try and get to what's needed for these sorts of telemetry protocols. And what about the existing subscribe notifications and yang push? They're allowed to coexist with this implementation, so I'm not doing anything with those. There's some sort of expectation maybe over time that if if this goes forward, gets published, and and there's adoption in the industry that maybe those get deprecated over time, and this is the only implementation around. But this document is not deprecating the old one or older versions. And what about GNMI? GNMI is entirely separate effectively from this effort. Although we are trying to align in some places. And as you'll see later slides, some of the issues that come up here actually could exist in GNMI. And I think the efforts, I hope, between the vendors and the other operators is to try and find common solutions that apply in both cases rather than getting different answers in different, different telemetry protocols. Also, not we're not starting from scratch. Not really making the wheel. It is a refinement to what's there. We're not trying to say, oh, well, the heads up. We'll do everything. So we're trying to keep, things aligned where possible. The document is quite long, because I've pulled in a lot of text. I've started existing documents and pulled in the stuff that we need. So I'm afraid it is a longer document, but, in defense of that is it's because it's including more stuff rather than it just being more complex as in it pulls in lots of options and extensions. So what's changed? So the main thing, obviously, is we had an adoption poll, and it's been adopted. So that's great. And thank you everyone who had a chance to look at that and and to support that option. Appreciate it. It's a long document. There were two main comments that I sort of got through that adoption poll I wanted to speak to now. I don't know Rashad's in the room. I think it might be. I can't see can't see him, but made this comment about he doesn't want to stop the energy or progress of the existing Yang push adoption. And, again, there's no plan or aim for that. We're all progressing the existing drafts, getting those published. But it is clear that, actually, a lot of the implementations aren't really following Yang push that closely. So it is important that we actually get this this published and specified and get much sort of stricter performance to what we're doing. So so that is important. And then the other one came up from Chin was about wide path. So if I remember the complaint or comment, it was like, wide path is not specified really yet. Wide path, what what suggested in this is a bit more complicated than the very basic x path of just identifying a path, including the reg extra keys. So that's something else. And he said, perhaps y path should be deferred to yang two. I think that we want we want to do something like yang yPath or some basic set of it now without doing the com all the complex stuff to make a complete equivalent to xPath. I think just in terms of at least identifying paths using a JSON like thing is important, much easier than xPath. And and James has sort of started a a draft and working on this and things. So I think that we will try and get that going and progressing. But I I think I would like to see some level of base wide path definition. Yes. Thomas.

[01:28:40] **Kent Watsen**: By the way, we're just a little ahead of schedule, so take time.

[01:28:43] **Rob Wilton**: Oh, fine. Okay. I'm not sure I'll need fifteen minutes. Keep your time.

[01:28:47] **Thomas Graf**: May may Thomas, yeah, maybe one comment on the wide also while discussing also with Evan and also with with with Jeff. I think it's probably not only something we need to consider for Yankpush itself, but also for for Netconf and Resconf. So it should be guy a generic way of filtering data.

[01:29:05] **Rob Wilton**: Yes. I mean, this is going off topic here, really. My vision is that we can get something that replaces x path completely. I don't know if that's a yang two thing or yang three thing. As in, I I think that these bigger these bigger changes and things, and I don't think why the part why prospect we're talking about is that. It's like a subset of it. It's a simple bit. But if you do the complete thing, I think that then you should do that separate as a separate extension and then bring it in future when it's got more traction in the industry.

[01:29:35] **Thomas Graf**: You exactly read my mind. I was checking just a few a few minutes before on the yang 2.0, whatever there is a requirements on on bypass or something, and I didn't see anything. So

[01:29:47] **Rob Wilton**: There's a there is a in the the Yang two issue tracker, there is an issue for tracking this, but I think it's my list of things to and my suggestion is to defer it, the Yang But that's we're going way off

[01:29:58] **James Cumming**: on this. Thanks.

[01:30:00] **Kent Watsen**: Come to Netmar on Thursday. Yeah.

[01:30:03] **James Cumming**: Just to comment on the yang path side of things. It is applicable, I I believe, in many different places. So the plan was to pull it into a separate draft so it could be dealt with entirely separately and then then utilized by whichever drafts needed it, whether it's now or in the future.

[01:30:20] **Rob Wilton**: And and to James' point there, YANG packages has the same requirement of doing a path, and it wants to it wants to do a y path, not an x path. Okay. That's great. So what else has changed since the ITF-one hundred twenty five? The the zero zero draft is the same as the one that was adopted. So it was the same that was published last year not last year, part, published the last ITF. So, we haven't published a later one. I've got working copies of some of these changes, but, actually, holiday got on the way, and other ITF work and other work got in the way as well. So we had some meetings and things earlier on. It slowed down a bit, but the I expect, the pace will pick up again after this ITF meeting. We'll go back to regular k cadence. There are a couple of things we did get to discuss and change. So those aren't updated here, but I am and one of them was covered a bit last meeting, but we will cover those quickly. And there's quite a lot of issues to open stuff. So one of the key ones that we discussed was the existing draft currently has a separate merge and replace by operation in terms of notification. So it had these semantics that when the publisher is sending the data, it could indicate whether that block of data should be merged by the the consumer for the given path that it's relating to or whether it should replace that. But the sort of feedback we got from other vendors and also from the operators is that this complexity is not worth and not needed. And the semantics you expect always for it to be a merge operation. And I think if I'm on I thought to misrepresent the other authors, I think the the the implication would be is any fields that are included in the message, any in that subtree will overwrite what's there, and anything that's left out that's not specified. So if that if that's not included in the dataset, it means it hasn't changed in any way. So so that's what I think. James, is that your yeah. So James James is nodding. So, yes, that's our understanding, and that's what will go into the next version of documents. I think at the same time, possibly, the merge might be renamed to something else. I don't know if that's the right name for this. And this is and what I'm talking about here only actually applies to the unchanged notifications. So if you're doing a periodic notification, you just send the data that exists automatically, and anything that's not there is implicitly deleted. Yeah. Nice to see you back

[01:32:43] **James Cumming**: at the ITF.

[01:32:46] **Balazs Lengyel**: Thank you. On some similar debates in 3GPP, merge with merge, it is difficult to indicate that I up added three items, but I also removed one. And that at least in the current merch and that many people are missing.

[01:33:09] **Rob Wilton**: So you have also this delete flag there as well, so you can send a separate delete on the item that's been deleted. And in the discussions that we had so our implement our implementation today, when it sends the unchanged notifications, it it sends a larger bag of information up. So it sends you the fields that's changed plus an extra data. But in the discussions that we had between the authors, it was like, no. And and we've had it from other operators as well. It's like, no. We want those unchanged notifications to be stripped down to the specific fields that have changed. I I like, it's a minimum set of things that changed. And I think as soon as you get to that point of it being like, this field's been changed, this field's been deleted, you end up with those sort of semantics, like, anything that's included, here's the new value with this value, it doesn't exist, is gone. So

[01:33:58] **Balazs Lengyel**: From the j JSON community, I always get that that they have this null indicating that you actually removed something. Did you consider something like that that that could be part of a merge with an explicit statement that, yes, this thing changed, but the change is actually a delete.

[01:34:18] **Rob Wilton**: So the we did I know we didn't discuss that idea, but the other thing, and I I might pull Thomas up, yeah, to confirm this is I think one of the issues that we're thinking about this is in terms of consuming these messages, we're trying to make them such that the message brokers that the this the description of them behaving as close to how the message brokers work in it and and expect it to work. And I think those semantics often have, like, the merge semantics that have been described here and separate delete messages. Whereas if you commingle, like, the merges and deletes in the same thing, I think it just makes more work on the on the consumer to then split that out into separate updates to go into the message bus. So I think that, again, was another reason why, there's this encouragement to not have that. And then the last comment on this, I think, that was pushing this behavior is is, again, it's a little bit more alignment towards what GMI specifies. So we're trying not to get too different have too many different options. And if it's if that's good enough and sufficient, then we'll go that way.

[01:35:19] **Balazs Lengyel**: At least this merge delete by merge is what I got from other community that they would like it. A completely different comment just looking through why part very fast. One other thing that in 3GPP I always get for filtering is depth parameter. So I don't want to go through the full subtree. I don't know five levels, just the first two. Wouldn't that be useful in the y path?

[01:35:50] **Rob Wilton**: I I don't think that will be part of y path itself. It might be part of the subscription, like a separate field. I don't I don't know with these. I mean, the one I have heard that's not in the document, but I think it's an issue tracking, is where people say, I want you to subscribe to this subtree of data, but prune out these other these other these other subtrees that are that are underneath that. So I I think it's a balance of trying to get this such that it's performant from the producer without being too complex. And the depth thing, I worry whether implementations will pull all that data up and then filter the last point. So they're doing a lot of work internally, reducing the the load on the on the network and the consumer, but I'm always concerned about, like, hidden expensive operations that you don't see as a as a client.

[01:36:42] **Balazs Lengyel**: If the consumer is not in interested in the level three, four, five, then sending it out and us and letting him prune the the extra data doesn't help anyone.

[01:36:54] **Rob Wilton**: But they could just ask those fields that they want.

[01:37:00] **Thomas Graf**: Yeah, Thomas. So I just wanted to mention it's not only the message broker consumers because it's consume message broker is basically also kind of a database. But in general, we wanna make it as easy consumable as possible. So that's why the merchant replace. Yeah.

[01:37:15] **Rob Wilton**: Mhmm. Merchant, no replace. Yep. Just to check. Okay. Thank you. The other one, I covered this one a bit in I t f one two five. So we had the discussion and the agreement of the direction from that. So this was the observation that originally when this document was published in the current version, it was having y p sorry. ITF- y p notification envelope as a separate document and depending on that. But we found that because of that, there was an issue. I can't remember what it was as to why it's causing problems. But, hence, the conclusion was that it's easier just to pull that the specification envelope into this document, and then everything was resolved. So and I think, actually, by putting it into this document, it'll end up being quite a lot shorter anyway. As in, I don't think it's like having to pull a large document in. I think the bit you need in here isn't particularly big, and we can reference it. So that was the direction agreed at the last meeting. I've started writing that up. I haven't got all the way through, but I think that's fine. So and this is what's left to do. There's still quite a lot of work. The the draft, I think, is quite well progressed, but still there's still loads of other stuff and issues and things to do and open issues, which we'll work on. I think that it is again, there's various vendors and operators that wanted to move relatively quickly, so I need to pick up the pace for this again. I think the key bit that we're really trying to get to is agreement between the people who are likely to implement this to get the sort of key bits of the protocol tied down, the message formats, etcetera, all agreed because then we can start progressing with the implementation. And the bits around the corners and those edges, again, they're not quite so critical. So it it sort of tried to do the code dev at the same time. A couple of these open issues on a golden last slide, and this is in terms of I talked about this whole behavior with other telemetry protocols. There's things like this atomic flag that GNMI has. Do we need something like that in in YangPush? What does that actually mean? What it what should it mean? Other issues related to this, I don't know if I mentioned them. Yes. I do. Things like how statistics are handled, that's coming up in the open config forums and operators where your operational data is different between, like, your applied config and your routing tables and forwarding tables versus statistics. And you they are sort of commingled in the data models where they live as subtrees under interface statistics is is a subtree under the interface. And some people want us, like, an unchanged subscription to the interface data changing, but they don't necessarily want an unchanged notification to the statistics. Because what does that mean? And, again, there's questions about whether you even have an unchanged subscription to a statistic. If it's like the interface counters are going up every every single part time packet comes in, you're not obviously on a notify every single time that that that happens. But you might read those coming out of the hardware on some cadence and then say, well, that's your that's your on change interval. But that but those automatics need to be worked out. And, again, if you then consider, like, an error counter, which is up updating on far less or slower cadence or would be on the mainline case, then maybe unchanged makes more sense for that. So I think as a as a community, we need to work out not tied to this draft, but more but more generally what those semantics should be, and we should try and get alignment on this document. And this should this document should try and specify and give guidance if it needs to or another draft and also try and align it with what the GNMI modeling behavior is if we can. That might be a tricky thing to do, but we'd like to do that. So, Per, you've got a question. So

[01:41:02] **Tarekk Saad**: Yeah. I have a question. So regarding on change on statistics, for instance, or counters, do you you've removed dampening period from this

[01:41:10] **Mahesh Jethanandani**: Yank push two. Right?

[01:41:11] **Rob Wilton**: Yes. It's gone.

[01:41:13] **Tarekk Saad**: So are you circling back to including it? Because that is what you would like to have maybe on

[01:41:17] **Rob Wilton**: I I think what the document probably says is is the server's allowed to dampen these values and choose what it it does. So what we would do is dampen it to the to the info that we read the statistics from either the hardware or the components of a component that's managing those. So it end up being we'll read them every ten seconds or thirty seconds and then notify the value has changed.

[01:41:40] **Tarekk Saad**: But you don't you don't want the client to tune that or No. You don't want to show how often it is done?

[01:41:49] **Rob Wilton**: The showing how often it's done, that

[01:41:51] **Tarekk Saad**: I mean, it's evident. It's implicit from when you get the update, of course. But

[01:41:55] **Rob Wilton**: I I think that that might come in, like, the capabilities model that Thomas has been talking about and trying to advertise it. So I think that's a better way of advertising what you support. In terms of clients being able to control this, no. I think it's too much complexity. I think it's these things, you could potentially ask for a lower cadence, but, actually, it's probably harder work for the for the the routes to manage those. So

[01:42:20] **Tarekk Saad**: And I have another question regarding I forgot to ask Benoit for the quick telemetry protocols in, I

[01:42:33] **Maher El-Aawar**: think.

[01:42:35] **Tarekk Saad**: Do you distinguish between the the delivery guarantees for, say, statistics and and operational states? Or or say I mean, say alarms and counters.

[01:42:50] **Rob Wilton**: So the I think I'll say is no. So so I I think it's just you take whatever the semantics for the subscription is. So that's not something we I mean, maybe that's something we should discuss because it might be that's useful. I think it's more between there's this desire. Maybe that specifies it like an unchanged subscription. You want more more guarantees with that versus a periodic subscription where it says, actually, if you lose some of the data, you'll get it next time around. The go?

[01:43:19] **Tarekk Saad**: Yeah. If I recall correctly, it says that if you're interested in it and don't want to miss out, then you put it on a quick stream. And if you don't care, you put it on a the quick datagram.

[01:43:29] **Rob Wilton**: Yeah. I think that's the sort of thing, and I think that we want to tighten that into the specification. The this draft also allows, unlike Yarnpush, to have a subscription that's both on change and periodic. So you can say, I'm gonna turn my on change notification by a period of one hour. So if I miss anything, it will definitely converge over time. So that's also possible here as well.

[01:43:53] **Thomas Graf**: Right. Thomas, I just wanna mention on the dampening. So exactly, it should be through the capability visible to the client, basically, what the dampening is. And I agree. I think it's not really necessary to be configurable because in most cases, the dampening should basically protect the router itself so that it's not overloading. So if it would be configurable, it's more about the client side, like how much notifications you want. So that is not really a requirement in my opinion.

[01:44:27] **Rob Wilton**: Yeah. I mean, we may the only thing I'm thinking about is I don't know over time whether and I don't if you want to do with this draft at this time is if you get if the implementation start going to generate these notifications at high cadence, then that might be a problem for clients that you're now sort of dossing the client with the notifications. But mostly, I think my reasoning is the the service should choose in a sensible sort of period. And when we have these things for, like, interface flaps so a hardware interface might flap, I don't know, 10,000 times a second, but you don't you don't wanna generate those events through the system, but you very quickly dampen those internally. So you would do, you know, fast down, slow up, or something so that you don't do it. So so I think naturally, you'd get that same sort of thing is that you'd say, okay. Actually, we need to make sure we don't pull this too quickly or something.

[01:45:20] **James Cumming**: I agree.

[01:45:22] **Rob Wilton**: Simpler is better where possible. Yes. So we're gonna have some discussions with those, I think, hopefully, and try and get some resolution. So the plan is to continue working through these issues and try and update it. I mean, as I say, getting getting agreement on the core bits of it, I think, is what we we want to do as much as possible. Our backup sites, don't really need this. So what did I say? This is where you can find information about it if you want. Probably this GitHub will change at some point to be under the Netconf working group. So this is my current my my personal one at the moment. And just to justify, this is slightly out of date in terms of the pages and things like that. So that shows you what we were doing. We're saving how many pages. 135 compared to compared to 223. Alex?

[01:46:18] **Alex Huang Feng**: I read the document a few weeks ago. So Okay. And it is well written, so I thank the others to put up to put up all this work. So reading from this presentation, so you still have some core issues to be solved. So my comments, should I wait for new iterations to send out to the list? No. No. Or because most of my comments, as far as I have checked, my notes were details here and there that may not be super important.

[01:46:52] **Rob Wilton**: And so just Please send them now. That's great. We will create issues for them. We'll track them. We'll incorporate them, emerge them now. That that just improves their report to the documents. So so, yes, it'd be appreciated if you could send those. And it also shows that other people are actually reviewing and progressing the work. It's not just a small set of authors, so that'd be really appreciated. Thank you. Any other questions? I think I've gone through everything that I had. So

[01:47:17] **Kent Watsen**: Oh, while I'm switching slides, late question. Why the ants?

[01:47:20] **Rob Wilton**: I don't know. I started with ants, and I've carried on. I hung up the new ant animations because it's a bit late in my slides. Sorry about that. Sorry.

[01:47:36] **Tarekk Saad**: K. Venturing into the non chartered work. Presented this at the last meeting, I believe, error list and error identities registries for Yang driven protocols. My name is, and I will take you through this. So the idea was conceived when I was talking to Rob about doing the Yank push two work, having to fit fetch all the different error and error identities and including them in Yank push two. I don't know if they are included in Yank push two or how do you anyway, the idea was to create AYANA registry so you can possibly create AYANA Yang modules for them and be able to help out in referencing the different errors that exist a lot. Yes. So it was called let's see. No. It doesn't say. It was called netconf error list and identities, but the feedback from the working group last time was that it should not only be for netconf but for younger than protocols and also look into restconf. But we could find nothing extra that needed to be identified for RESTconf in particular. So there are basically these two registries that would need to be created, I believe. And, yeah, that is it. Next steps. If the working group thinks this is valuable work, we should adopt a document and gather feedback to define a thorough solution. Yes, Rob.

[01:49:19] **Rob Wilton**: I think I've said this before. Yes. I think this is useful. I think we should do this. I think this is just a it's a nicer way to manage these things. Yeah. So thank you for still doing better cleanup.

[01:49:30] **Tarekk Saad**: Exactly. So we would request an adoption at this point.

[01:49:35] **Kent Watsen**: I'm preparing a show of hands, Paul.

[01:49:55] **Tarekk Saad**: So that I can talk to the poll. And do you think the error registry document should be adopted? Yes, no, no opinion. Clear enough. So a real good live commentator would say that, yeah, it's going up for yes. No is still zero, and no opinion has three. What does that mean? Don't you don't you care or don't you know? And no. There's no toggling as there was in, I think, There were no. Okay. There we have it. One no. What does that mean? Could you come to the mic, please? Great. I have one one friend in the audience that knows how to handle user interfaces. Talk to me later. You don't have to disclose who you are. I would like to know if it's the same person that was in ops and did the same thing.

[01:50:42] **Kent Watsen**: Okay. Okay. Well, that's a solid response right there. Almost 50% of all the members that are joined in the call participated in the poll. Thank you. Okay. Next presentation.

[01:50:57] **Tarekk Saad**: I think maybe Balazs has a sorry.

[01:50:59] **Balazs Lengyel**: Balazs, then question. Is will this is this planned only as an INA registry, or will you make it an INA handled Yang module? I would say both. I I like the Yang module as well. Thank you.

[01:51:17] **Tarekk Saad**: So I I can say that leveraging the the Ayana registry to create a yang module is the is the idea.

[01:51:28] **Kent Watsen**: Okay. Thank you.

[01:51:29] **Tarekk Saad**: Thank you.

[01:51:32] **Kent Watsen**: Last presentation. And we're only one minute behind.

[01:51:53] **Presenter**: Okay. Hello, everyone. I'm from. I'd like to introduce our our drafts that submitted to the m m mobile working group titled operational requirements for network state exchange, agent assist in network operation. I think this topic is closely related to the network network management protocols, so I present here to to cover some comments and feedbacks. Okay. Let's start from the background. The network network operation is moving from the traditional human driven workflow to the agent assist in that workflow. So the traditional management requires the operator to manually inspect into the alerts and telemetry and write some can pass the changes scripts. It's very very low efficiency efficiency on the on the labor intensive. So the agents assist on network management to kind of invoke the CRL or API tools and correlate to the topology and the logs and the traffic and the as a configurations to to to support some specific network management tasks including the root cause analysis, configuration commands, and so on. So this is new question. Is that how in the world is the network state should be exchanged between the network devices and the the agent? Okay. So so I was saying that that the agent does not need more telemetry. Well, natural force of reaction is that we can't just feed all the the full and now what time train to the agent about the this does not mean better reasoning because it would would bring some problems as a first day is a cost. Like, the token and cost will go with data volume. And and the second is a semantic gap as a routing image data may not be aligned with the query and those specific task. Now the the third is the reasoning errors as in missing some scope, and then we will cause the agents to be over over overconfidence or or hallucination and other other problems. So the agent need to have a of the of the net network and multidimensional evidence and the faster correlation that is reasonable reasoning. But the fact is that transfer the full data will create a major analyze pressure and and and it's supposed to some sensitive issues. So we post the core the core challenges that how to spot agent to to perform and compliance reasoning while meeting the bandwidth, the privacy, and the real time constraints. So so this is short concrete example of the d of the DDoS defense, but it can be expanded to other scenarios such as a traffic engineering or or automatic configuration. So in this case, the agent need to answer some questions. So the first is which source IP we're domain into the traffic, and is the traffic oriented from multi demand? Should the the full spec filtering rules be generated and deployed? So if we we just feed out all the raw flow records to the agent, you do will will lead to the data scale overload and some privacy issue and the policy violations and then some noise from the data. So in the agent, you're always seeing the communication has been shifted from the data to state evenness. In the traditional data communication, it's a which is a device centric. The device the operator need to answer what data or configuration to retrieval. But in the agent in Europe, it has has been turned to the questions in creator. We we need to answer the data can can answer what kind of questions, how confident can I get it? So we post our abstraction of the of the data that need to be transferred from the network devices to agents. That includes the three elements as a payload that can has can test on the accountability. As a payload that comprises the network data, whereas the scope indicates that I can test. That's a topological scope and a and a device scope. We also need to provide the error bound and the tolerance to support our accountability. So the of this draft is that we propose seven requirements for the agent network. So there is change, including the compact under the scopes and the multiple upon the error increment for privacy aware and auditable. So it's a it's a mapping table of the requirements for the draft for more for more details so you can just read our our draft. And we also launched the Hexen code code implementation. In this project, so we use our sketch as a reference solution. You saw that with a probabilistic data structure, and it's designed for the has to be the streaming streaming data, and then you can compress the network observation into a very small summary. The way we simulate our net selling the flows and it achieves a compression ratio of 443. And in this project, we demonstrated that sketch may be a reference solution to satisfy the requirements including the compression, the the provider error bonded and the and the user auditable. We also wanted to emphasize that we need to keep the human in the loop. It corresponds to another drafts in IMRT. Oh, okay.

[01:58:16] **Tarekk Saad**: Oh, okay.

[01:58:19] **Presenter**: Oh, so it's No.

[01:58:20] **Kent Watsen**: Wait till the end for my question.

[01:58:22] **Presenter**: Oh, it's it's a fun period.

[01:58:23] **Kent Watsen**: That's You have 44.

[01:58:25] **Presenter**: Oh, okay. Our key point is that we don't replace the existing protocols by just adding the streamer's data is there. So the netconf-restconf- is also is still responsible for collecting data from devices, and and the semantic layer compresses these data and and the formal state artifact to the agent. Okay. That's on my presentation.

[01:58:54] **Maher El-Aawar**: Thank you.

[01:58:54] **Kent Watsen**: Okay. So I'm first in queue. I think as chair, I'm we we allowed the presentation to be part of the agenda, but I struggle to understand how it's part of the netconf charter. Can you help me understand why this working group might wanna, you know, adopt this draft ever?

[01:59:15] **Presenter**: Yes. I I I think ASR is more correlated to the to the to the telemetry of protocols management. We can we can just collect the or or or or use the use the same protocols to collect this data. But maybe we need inside agents or assist the network management in Europe. We need additional, like, the status management layer to compress this data and give them the amount for the agents to to have them to perform the better reasoning. I think maybe it's it's necessary for the existing protocols.

[01:59:57] **Kent Watsen**: I'll leave the queue. Mahesh?

[02:00:00] **Mahesh Jethanandani**: Yeah. Mahesh, I had actually a similar question because I was looking at it and trying to the name of the draft mentions NMOP, and I thought it was more a presentation to both FII to this working group to say this is what an experiment maybe that we're trying to do in NMOP. And so as an information drive, as a presentation, it's fine, but I would agree with Kent that I am struggling to understand why netconf with its charter would adopt this document. Maybe that clarification would be helpful.

[02:00:39] **Thomas Graf**: Thomas? So I think I'm the outlier in the room. I have a different opinion. So the reason I think why this work should be shown here is because, like, before we had the discussion about bypass, We had discussions about merge, replace, and yang push. And, basically, there are reasons why we we are needing these functions, and here is explaining some requirements and use cases. But what would have been good in the presentation to actually bring this up towards the netconf protocol, and that that would have been useful in my opinion.

[02:01:12] **Maher El-Aawar**: K. Thank

[02:01:17] **Rob Wilton**: thanks for presenting this, and thanks for this work. So I think lots of what you do here is very interesting, and I think it's good to be doing this as an experiment. The bit where I personally fall down is I'm I'm never very keen on requirements documents, certainly not being published, is that I'm not sure these requirements are more than just sort of generic requirements for anything that's doing AI and and using other lens and things. So I'm not sure how tied they are to this particular thing. And in terms of needing to define, I can't recall it, a package of information effectively. Again, I'm not sure with LLMs and things you need need to have that standardized. So I think it's like an inspection draft is like, these are things you might want to consider and include. Okay. But but I I think it's okay, but probably not that useful. As to having something that says we need to define a structure to contain this, again, I'm not I'm not sure I see the value in terms of an RC, particularly as how quickly LLMs move forward in their capabilities. But thank you for bringing it away.

[02:02:19] **Kent Watsen**: Richard.

[02:02:19] **Benoit Claise**: Thank you for your presentation and following up on what Mahesh has as NMOP co chair. I forgot. Did you ask to present this in NMOP, and did we say no? I don't remember.

[02:02:30] **Presenter**: Yeah. Yeah. Our president is in Denmark on Thursday on Thursday.

[02:02:35] **James Cumming**: K.

[02:02:36] **Bo Wu**: Yes.

[02:02:39] **Kent Watsen**: Okay. With that, thank you, everybody, and enjoy the rest of the week.