Session Date/Time: 23 Jul 2026 07:00
[00:00:15] Lou Berger: Good morning. It's time for the session to begin. I am Lou Berger. Kent Watsen is here with me as is our secretary, James Cumming. We have looks like some good participation both in the room and remote. Welcome. This is the netmod session for IETF 120. We're going to start with some of our usual advisory messages. The first is our note well. I suspect people are familiar with it given how late we are into the week, but if we're not, Please keep in mind that everything you say here is part of our permanent record and governed by the IETF contribution guidelines. Please feel free to scan it. Also, we are being recorded. We also ask you to be respectful of each other in our conversations. Good arguments on technical points are always welcome, but be respectful. Keep it professional. Generally, people are aware of this, but sometimes energy can go the wrong way. Just please adhere to our code of conduct and be respectful. If you are in the room, please scan in. This allows us to get appropriately sized room. It also allows you to participate in comments at the mic. We use an integrated queuing system between both local and remote to ensure that everyone can participate equally. We also I think we have some polls. We have at least one poll coming up, think, and you'll want to use the app to participate, and we very much like you to do that. Similarly, we'd like you to help contribute to note taking. There's a link on the in in MeetEcho. The link is posted here. We have collaborative note taking through Hedgehog. It is very important to cap make sure that the discussion is captured appropriately. If you make a comment, go check to see that your name is in there correctly and that the your comment has been appropriately captured. And if you wanna help out by capturing other people's comments, we would appreciate that. Kent, would you like to take over?
[00:03:06] Kent Watsen: So we've published a couple documents since last time. RFC 9507, also be known as BCP 216. Let's get a round of applause for that. In the RFC editor queue, we have the system config draft, which I believe is RFC to be 10016. So we are in the 10,000 draft number of drafts now. We have a number of documents that have been submitted to the ISG for publication, but they're still being looked at by the ISG in varying as as, you know, conditions of progress. And let's see. Oh, I need use this one.
[00:03:52] Lou Berger: Just to mention, when we made the slides, there was an open action on December. Thank you, Joe. Thank you, Mahesh, for taking the action and pushing that document beyond that step. So thank you very much.
[00:04:12] Kent Watsen: A number of documents are not on the agenda. Again, packages, version Yang version REX, any new data validation, yang version selection, yang solutions, no tags. Some of these have expired, and one actually had been expired for such time that the church felt we it was time to move it to the dead state. If from a liaison's perspective, we have had no incoming nor outgoing liaisons. Yes, mesh. Previous slide.
[00:04:53] Mahesh Jethanandani: Mahesh, I guess you know the question that's coming. Yes. For those documents that have either expired, do we have an update from the authors? Are there work group documents?
[00:05:10] Kent Watsen: Two of them are.
[00:05:13] Lou Berger: So the only one I think that we did not get an update on that we were sort of it'd be good to get an update on is packages. The other ones we could run through why we're not getting updates, but I think maybe just we could hear from Rob on packages. Unless, Rob, you're coming up to say something else.
[00:05:32] Rob Wilton: Package is is on the agenda.
[00:05:36] Lou Berger: So that's a mistake.
[00:05:39] Rob Wilton: So of the other ones, version requirements, I think we're not planning to ever publish that. Right.
[00:05:48] Lou Berger: It it that that's actually appropriately reflected on the slide. We got packages right, but we wrong, but we got requirements right on there. So
[00:05:55] Rob Wilton: Yeah. So that one, I think, will end up you need we'll kill it off of the get end of its work. The yang solutions, again, I don't think we actually need that one. That would yang solutions. Is that the one related to versioning? I don't what that one is.
[00:06:09] Jan Kundrát: The different
[00:06:14] Rob Wilton: bits. I I
[00:06:15] Lou Berger: suspect that yang solutions might fade away. Yep. I would expect versioning requirements to be when we we're done with versioning, we'll we'll we'll make sure everything looks good and publish that. Any data we discussed the last meeting, I don't think we had any update on it. So if we wanted to hear from authors on it, that would be great. Where else are we?
[00:06:42] Kent Watsen: I think any data is actually currently expired on data tracker.
[00:06:49] Rob Wilton: And and the last one from our side is version selection, which is the word we expect to pick up after we've done the current stuff. That's it's like the last one, I think. Yep. I have got a bit more update in my slide deck as well.
[00:07:02] Ahmed Elhassany: Alright. So as co author of any data, so this one, you know, we couldn't have the time to do all address all the feedback on time, but we hope
[00:07:12] Kent Watson: Can you point the microphone up? So
[00:07:15] Ahmed Elhassany: we couldn't get all the
[00:07:18] Kent Watson: can I use
[00:07:19] Ahmed Elhassany: this? We couldn't address all the feedback on time. So, hopefully, in the next ITF, we will have an updated document for it.
[00:07:26] Lou Berger: So I think Mahesh is was playing to our final slide where we ask that we get an update at every meeting. And if you're not presenting, just send that update to the list. So I think our AD is reminding the working group that we really want this to be done. So thanks, Mahesh.
[00:07:52] Kent Watsen: Okay. So we already did the liaison slide. Let's go to the next slide. On the agenda, we have a number of chartered working items being discussed today. YANG packages, guidance for managing Yang modules in our system, the IANA registries, Yang schema comparison, Yang next agreement, XMon coding for data model with Yang, and the Yang two data modeling language. And there's a number of
[00:08:17] Lou Berger: We're we're versing three.
[00:08:19] Kent Watsen: Oh, that's true. Reversing three and four. Right?
[00:08:26] Lou Berger: We're gonna we're gonna do the IANA update first. That was the request from the authors, and we
[00:08:36] Kent Watsen: briefed. Okay. And then some non targeted items, including YANG templates and enhancement to the YANG language for capturing subtree replacements, which is actually a second presentation. I think it was presented in 01/23. Extending normalized forms for string derived types and YANG library feature comparison, which is very cool. And the YANG coverage presentation. If you're working remote well, we have this we have this is primarily an organization that works remotely. We utilize the mailing list heavily, always to judge consensus and to resolve issues. So please become active on the mailing list. We do have virtual meetings. If there's a desire or need to have a virtual interim, please ask the chairs to set one up for you. And we can always make Webex available for you as well if there's a design team or anything like that that would like to have a Webex. Lou already spoke to this slide, so I don't think I'll go over it again. And that's it. We're fighting each other. Okay.
[00:10:03] Lou Berger: Thank you.
[00:10:05] Rob Wilton: Okay. So this is my update on guidance for managing yang modules and RFCs and higher registries. That's fine. I'll give a quick update before that. I'll just highlight again where we are with the versioning stuff. So, and I'm presenting on behalf of all the authors on
[00:10:20] Ignas Bagdonas: this work.
[00:10:23] Rob Wilton: So this is just a reminder of all the versioning work that's gone on where it is. So, the solution over after, we said that that's gonna disappear. We discussed that earlier. Then we have three that we're post working group last call. We're gonna state update with those. I think they're now pretty much post IESG, so that's good. The one I'm talking about here, number four, is guidance for and the RC editor. So that's this one, and we're hoping to get that one into working group last call soon. And then yang package, I'll talk about next, and we've schema comparison as well on here. And then the final ones that marked as IDs are the ones to do the yang version selection. So that's been adopted work, but I expect it will change quite significantly, which is why it's sort of up it down at the bottom there. And then there's potential work for doing, like, packages. And at the moment, I think we would want help ideally with people, helping with that if they're interested. So so if you're interested in trying to define packages for the ITF YAM modules, then reach out to me or ask, please. So, onto the, these guidelines, of YAM modules for I and the the ArcCeditor. This is the abstract. The aim is to provide guidance to both of those two bodies for managing the Yang-wadgets in general. And it was it initially came out of the fact we had discussions with them about the versioning work that was coming on and what we're hoping that that they would then do in terms of the publication process and checking that the version numbers are right and things like that. And they asked for some more formal guidance and things, that they could follow, over time. So that's the purpose of this draft. We met with Diana in IETF 124, and that's when we started doing this. They asked these documents. Then the RTC editor said, well, could you cover our stuff as well? So it increased its scope. And the goal is to move quite quickly because those other three documents I mentioned first, the semver, not sure what the filename does, we wanted those to have a reference to this document. So the idea is to get this one going quite quickly. So the aim was to be to publish or be in the queue the other three version drafts. I'm not quite sure we'll get there, but we might do. And then they also we've reduced some of the text in in the other draft to now reference this document. So, again, that's the encouragement to get this through the process quite quickly. The OA version was generated before Christmas last year, and that was mostly by an LLM, and then I did some edits and updates to it and things, and then we had the OA1 version published for IETF 125 with more updates and cleanup and things like that, some fixing mistakes. Since the last staff meeting, again, we've had feedback reviews from, from various people and things, including from my analyst and the RC editor. Some of those have been incorporate well, hopefully, most of them have been incorporated in the last cycle. So we're in fairly good shape with the o three, but not quite there, but close. So next step steps is hopefully working group last call shortly after this meeting, so that's what I would like. I did hopefully, that's for you. There's no open issues in the draft, but I didn't miss some minor updates from Chin's review. I don't can't see Chin's in the room. So, again, I've looked at his, and I'll reply back to his email, but there's a few small comments and things to fold in there. I think there's an email from Amanda I might have missed again, so I need you to check that I've incorporated those comments as well. I said it's Bill still checking with Sandy. Actually, I'd sent you an email and had a reply back last night, and I responded back to her. So I think, I think, again, she's happy. Ayanna's happy with this version going forward, so is Sandy. So I think the next version will be good from their perspective. And given they're the main, audience for this document, I think that sort of says in quite good shape.
[00:14:06] Lou Berger: I'll note while we don't have anyone from Ayanna coming to the mic, we see I see a couple of representatives in the back nodding their heads. We appreciate your contribution and your, concurrence on this. Thank you.
[00:14:17] Kent Watsen: When we do the working group last call for this document, if Anna could participate in that as well, it'd be great.
[00:14:25] Rob Wilton: The proposed plan Mahesh, do want to speak now? Probably good to in interlude.
[00:14:36] Mahesh Jethanandani: Mahesh, you first of all for helping put the guidance together. I'm sure it's helpful to both I and I and the RPC. I just had a question that I want to get a confirmation. I believe, Amanda, you had raised a question about identities versus enumerations. Did that ever get resolved? Okay. So she did not say yes. So other than that, I'm getting a confirmation from the RPC. I didn't see myself read an email from her. You're saying essentially we are should be good to go for a working group last call?
[00:15:14] Rob Wilton: Yes. The the email came in I think it was last night, it came in just to me actually copying the RFC editor as well. So so it hasn't gone to the list. Okay. But but, yes, effectively, they've they confirmed they're okay. They had some further questions, but I've clarified those. There might be some minor clarifications to the document, nothing that that I understand in terms of changing, the process or the text in there. So I think it's just a matter of tweaking some bits and things to make sure it's clear.
[00:15:39] Mahesh Jethanandani: Excellent.
[00:15:40] Rob Wilton: So so the proposed plan is to do a few small updates after this meeting, but they they should only take me, like, a a few hours or something to do, hopefully. I think we already heard from Sandy, RPC, and also I know that they're happy for this to go ahead. So the number two is what should be done, so then request working blast call on that next version and things. Okay. That's okay. So and any questions or comments from anyone?
[00:16:08] Kent Watsen: Yeah.
[00:16:09] Lou Berger: If you haven't read the document, please do so. If you have an objection, you do not need to wait for the the working group last call, bring it to the list immediately so we can get it addressed, and then move this document towards submission to the ISG.
[00:16:22] Rob Wilton: And it'd be I think it'd be good if we can get this one going through quite quickly. I think we should try and that'll help us. I'll help you.
[00:16:29] Lou Berger: So I just heard you commit to an update by the end of the day or the end of the session maybe, and then we'll do the working group last call by tomorrow.
[00:16:35] Rob Wilton: I'm not sure I could do an update by the end of the session. That's quite tight. Yes. Okay. And that's everything, Rick.
[00:16:43] Kent Watson: Go to next slides. Should go. Brilliant.
[00:16:59] Rob Wilton: Thank you. So this is my update on yang packages. And we are now at dash o nine. I think it was o seven in the last IETF, and I published eight to nine just before this meeting. And nine incorporated some suggestions from Joe, I think, at the end. So this is exactly the same slide as you've seen previously. I won't go over the same over over the same slide as before, but this is now talking about the Yarn packages part. And you can see we're getting quite the way long way down the list. Schema comparisons coming up next, I think. So we are getting there. We're making progress. So recap about what yang packages is. I've presented this quite a long quite a few times. It's almost like a hierarchical version of yang library, so you can split it out and they can sort of include different bits, come in different functionality. It's also designed to be more useful off the box and things like that. So a key part of whole packages use usage and solution is to allow these things to be defined off the device and then just referenced on the device. So rather than, the existing flow where clients come and connect the device and download a load of yang modules, they can still do, yang libraries to be there. The idea with packages is you can just pull down, potentially just even the references to the packages already know that you have the definitions for them and either rebuild the schema locally or use prebuilt schemas and things like that. So the aim here is to try and simplify that that flow into device. They're also useful in terms of, like, schema comparison and things. And, hopefully, when people, like, version sets of yang modules together, which we're hoping that ITF might do in an open config, again, you've got a construct that says, okay. I've got all these yang modules together. I can version these and give them description of what they what they what functionality they mean and apply. And you can also define within it, like, a set of you can include deviations, as you'd expect. You can include features, segments as well like that. So, again, it's the idea is to define a schema. So summary of where we are. The the hope before the last the last item of the meeting was a stretch goal to be ready for working with last call before this meeting. And we haven't quite got there, but we've made a lot of updates to the document, a lot of progress. So there's some minor updates to the solution that hasn't really changed very much, a few tweaks and things like that. There's been a lot of updates to the doc. I said 48 git commits there, and a lot of that is either adding examples at the end. There's still one set of examples need to be added. But and then improving the text. So I was asking LLM to implement some of this. Already had some code, and also to review the document for implementation. So it's found various, either discrepancies or bits that aren't clear. So, again, that's helped update the documents and improve it, various things. And fixing that nits and all sorts of things, so the document's much cleaner state. Resolved 13 issues that we had open before. There's another 15 issues that the document that have been folded in, but just needs the authors to sort of meet and agree to close those. So that and and more reviews in the authors as well in terms of the changes and links. So the six issues open or remaining, I think quite a few of them fairly small, actually. And there's some nits and things to tidy up as well and add some comments, but I think it's getting closer to being complete. One thing I would say, this this version of the document has increased by 40 pages from previous ones. It's gone from 70 to a 110 pages, and it's mostly adding examples at the end, which is probably good. But, again, was using the LLM to help construct those examples. My question to anyone that reads or reviews it reviews the document is, have it has it become too verbose in terms of the examples at the end, or are they useful and it's fine? So that's that's the sort of feedback I think would be useful from the aspect of how the document's changed, plus just reviewing the overall solution. As it said it says here, I think now would be a really good time if you haven't reviewed this document to actually give it a review, and I think most of the stuff should accept the expect to be addressed. There's just one section on examples of handling mount points that's missing at the end. So that's anything that really needs to be added. So latest package tree diagram looks like this, and I've added in green. The bits have been added in. So along with this description field, we added in, a version description. So you have a description describing what the yang package is for, and then a version description sort of describing, how it's changed if you wish to add that in, and that's optional. You'll see and this is slightly strange that the includes package list now is keyed by both name and version, and this allows you to include, two different versions of the same package. And that's quite an odd thing you might want to do, but you the way that YANG packages work is that you don't replace versions. You can't remove them. You basically add them together. You you're like a you collect and and have all the different package versions available. And we wanted to be able to update the metadata, like the locations of where you might find the package definitions. So that's why that's come in there. So it allows you, if you have a package that's included deep down the hierarchy, to say update the metadata, so it's associated with, say, you can also find this package from my vendor site as well as as well as where where it's been originally published. We added on added in the new depends on so this is something that I think Joe was asking about, and this has to do with when you've got, like, bug fix packages on a device. So the the overall idea here or the one the idea I have in my mind is that a device for a given software release will advertise a base package of all the functionality. But if you then want to modify it and have some sort of bug fix, hot fixes, and things like that that are then separate, then you can sort of package those separately and advertise those to the top level schemas. You get the base package plus any of these fixes, and you resolve those into one complete schema. But the the problem that Joe was mentioning is that for those bug fix packages, they don't define the entire schema. They're just like small fragments of what's changed. And he was saying that it'd be useful to have this sort of reference back to how do you find how do you, you know, make the complete package. And that's what this depends on allows you to do. It it allows those bug fix packages to say, I depend on this base package version, and hence, I don't need to, but it's not included in the definition. So it allows you to build the scheme if you want to, and it's a relatively minor addition. And, again, all of the things in here are sort of optional to implement. Under the mount points, and, again, you'll see somewhere else in the schema, we've changed it from my account has been added in additional features here. So when you mount packages and when you define package schemas, you also can define the set of features that should be enabled as part of using that package set. So if you implement BGP, for example, there might be some optional features that you say, whenever you're implementing this package, you always have these features enabled. And hence, you can include that in the package definition to say these are sort of mandatory features that any implementation must turn on or deviate them away, if they're going to implement this package faithfully and correctly. And, again, so when you're doing mounts, you have the same thing. You've got a schema down there. So, again, it sort of folds in. You need to have the same ability to turn features on there. So that's been added in. My click's still working. So the changes and there's and there's quite a lot to change. So the the significant changes since o seven and o nine, and it depends on actually, I've talked about that already, so I won't go over that one again. We tweaked the binding of how you map packages to yang schema. So one of the key things was before is that the the package definition on the device so these things exist both as files, like instance data documents, JSON files, and they also on the device, they're advertised as part of just regular yang data. There's a packages tree that has all the local package definitions that are available. And that was containing the the locations of where you found those packages as long along with the package definition. But that differs from what you see in the file. The file doesn't tell you where to find itself. The references or location pointers are all external to that file. So so we then aligned the, like, the Yarn packages tree to match and marry up to what will you find in one of those files effectively. So, again, make it easier to take that tree definition and to be able to generate your own file if you want to, instance data file and wrap it. And then that means, obviously, that when you reference these packages, you also include the locations of where to find them, because you've now moved that information. So everywhere that you'd expect to repackage to be referenced, you'd expect to say this is where you need to find it from, which is a list of list of places. Additional features, I sort of mentioned those. I think that's changed. We had a list of where when we're listing these features before for the schema, it would list all of the features enabled, and we changed that to just listing the additional features enabled on top of what's already defined by those packages. And that was done, a, to make that list smaller and also to effectively mean that you can't give wrong information because you can't say this feature is enabled by the package, and yet you then don't declare it at that point. Lou, do want
[00:26:27] Reshad Rahman: to ask?
[00:26:27] Lou Berger: Yeah. I was just looking through the diffs. I think you added version as an index, and I thought it would be good to
[00:26:36] Ignas Bagdonas: Yeah.
[00:26:37] Lou Berger: Oh, okay. It was there, not the or I thought it would be good to for you to talk about that for a moment. I did. I I can Oh, then I apologize. I spaced out.
[00:26:47] Rob Wilton: Yeah. So I'll just recap. The re it's No. No. Don't. Just move on. Okay. Fine. Yes. So that was that's two of the bigger changes I pulled out. The rest of these aren't so significant, so I ask, again, an LLM to summarize all the changes and things. And this is just a summary of what they're out what the significant changes are. I'll talk through them briefly, but not in much detail because it's not worth it. So we sort of fixed up, like, the package identity reference hammy. I've just described that in fact. The includes package amount, package now keyed by name and version that I described is so you can update the metadata, which is what it says there. The package resolution has been rewritten to be clearer and more correct and things like that. So, again, that's through the review process and things. We've, tweaked the definition of location of where you find packages to say that the, the first entry in that list is, like, the canonical location, of where to find it. And, we've tweaked the merge algorithm of the locations to make sure that you always keep that first. So so if it is an ITF package, for example, I would imagine these might be published by Anna, these package definitions or Anna registry. I would expect that to be lurs first. And so if a vendor puts other locations on, they can, but they keep the con canonical one first. The mandatory feature has been renamed to enable feature. I've talked a little bit about how that's changed. And then the amount of package behavior we've I think some of this was described in the last IETF meeting as well, but I think we got to a final point where we're happy with what we have in terms of any additional features and also be able to manage the schemas that are mounted as well. Some more ones. The package instance data files have been made much stricter in terms of what fields you have to populate in that instance data header, and that's so that you can generate these things more easily, so there's less variation between the two. And, again, the idea, again, is you take one of these package definition package definitions in yang off the device, you can generate the instance data file. I now define a yang this we confused to explain a yang package instance data schema to be used for instance data documents. So in an instance data document, you say what the schema is for that instance data document, and the instance data document has a choice that allows, like, a simple list or a yang library reference, and now it also allows a reference to yang packages as well. So we augment that. And, again, so this is the definition that that fits that all together. Update the security considerations. And I actually need to chat to Mahesh and Med about that as well. Added in the operational considerations section, and we tweaked the INA registrations and things. I think that was some feedback from the INA, so we've incorporated that. And the appendix examples have been expanded and fixed a lot of those things like that. So that's all good. A few things that we've removed. So it used to be that the package the names of packages had hyphen package in them. I think Joe one of Joe's suggestions was that we define a file name type, the dot y p k g file. And hence, then you don't need that in the name, that cleans those up as well. Goldyang library supported feature complete list. Yes. So this is about only using additional features rather than reporting them all. I'm not sure that's an old Yang library thing, but that's fine. I think these other things are fine. The placeholder hotfix appendix text. Oh, fine. I don't think that's a significant removal, so that's okay. Other minor changes, I won't go through these. So, again, there's a load of other minor stuff and things. Have a look at the slides, but or have a look at the documents. I don't think that we need to discuss these. They're on the slides if you want. So what's left to do? I said the mount point examples is the last set of examples we've added in. Close remaining six issues. I think they're all relatively minor, but sometimes these things turn out to be. The one key one, actually, is that the document currently has a dependency on the ypath thing. So that's the one thing that might trap us that we ideally, we don't really want to redefine it in this document. It'd be better to have a a reference. But I we can work that out. And I think that's okay. I think the other key thing that, again, Joe's mentioned is is, like, having open source compiler to support this. I I have some compiler code already. It's not complete. I I hope that I can open source under Cisco. I need to see to get through the hoops and links to do that, but that is my plan. But that tooling needs to be effectively finished, I think, because I think we'll also have a reference in not like, an annotation that people can use at the point that we publish this. So that's coming. And then I expect in the process of doing that, I'll get more AI reviews and things and clarification of the document. So that all makes it better and makes it easier through the latest part of this process. Further using the authors and things like that, I've driven quite a lot of these changes, so getting those more reviews through. Reviews and work working group, always welcome. I might have mentioned earlier on, good time to review if you haven't. And then it says, hopefully, work group last call by IETF 127. I think, actually, the two things that are going to hold this is gonna be the ypath dependency, which might not stop the working group last call, but might stop it from being published, and making sure that the tooling is sort of there and available. And I think that's everything I've got to say. Oh, this is where we're meeting our still regular meeting on Tuesdays, 9AM east eastern time. Don't necessarily meet, actually, every week, but we do for most of them. And that's just the stuff we're doing. So people are welcome to join those calls. We should probably send out another reminder to the list. I need to ask Jason to do that. We can do that. Hope somebody can do that. Reminder in case people want to come along to those, but we're pretty much closed on this stuff, getting close to the end. Any questions or comments? No. Awesome. Thank you for the update. Thank you. Sounds like?
[00:33:12] Kent Watsen: Actually, it's Michelle.
[00:33:15] Ignas Bagdonas: Yeah.
[00:33:19] Kent Watsen: You know, he didn't show up at nightclub either.
[00:33:23] Lou Berger: Interesting. So the presenter is not online, and I haven't seen him in the room.
[00:33:32] Kent Watsen: He was registered to be in person. And he's not. And I haven't seen him in week.
[00:33:37] Lou Berger: One of the coauthors. Yeah.
[00:33:40] Kent Watsen: He was
[00:33:40] Joe Clarke: supposed to be here in present today.
[00:33:43] Lou Berger: But he's not. So maybe we'll give him a little time, and he'll show up. And if not, think about who else wants to present that. Right. So rather why don't we skip him until the end of the the drafts the the working group drafts, so just a couple slides below a couple slots below. And so he'll go after Kent or Joe, thank you. You'll go after Kent. So, Rob, you're back. So, Yang next.
[00:34:18] Rob Wilton: No rest for the wicked. Okay.
[00:34:23] Kent Watsen: Sorry. I just passed away.
[00:34:24] Rob Wilton: Hello. Working group again. Yang next agreement. So this is, this is past the work that that Kent's been driving in terms of the next version of Yang. So, he's done a lot of the work, and he'll talk about this in terms of getting a a base draft updated and going. Base up a base draft update and going for that and in terms of what the tooling or process for up to putting updates into that document is. So he's been doing that sort of thing. But as part of that process, there's a lot of issues, and we want to try and I wanted to try and specify or get a get some more concrete agreement from the war consistently work as to what this sort of update should look like. And hence, I wrote this document, just to the middle of the last ITF meeting. It was too late to sort of get it on the agenda to publish, but it has been adopted, since. Abstract. Purpose of this document is to discuss and hopefully find agreement on scope and shape the next version of yang. So this is not a fake complete. This is my initial stab at where I think these issues are, which ones should be included or not. I didn't spend that much time doing it. Nope. It's all good. And so so I mentioned this. Kent's leaving the new version of yang. Great. Yay. The process and updating that yay is good. There's a 150 issues at least on the issue tracker. I think some of those are closed. Some of them were closed when we had a different way of evaluating these. There's probably some more. I didn't actually check the exact number. We probably only want to implement a subset of these for the next version of yang, and we need to agree what a subset is. There's also some of these issues that we may want to defer to a later release potentially, like these things are too big or not in scope. And there's some that we may want to close and say, we don't ever do those, and, and we looked at those. And previously, there was an effort to classify these across three different axes, how important it was, what level of complexity it was, low, medium, high, and whether it was backwards compatible or not. And then I think that initial review, if it wasn't backwards compatible, and that's a slightly nebulous definition of what backwards compatible means, I think, for these things, then they then those issues were closed. Whereas, actually, I think in the subsequent years since that process, some of the issues reflectively, I think, would now fall in the scope of yang two potentially because we are proposing or I think it's gonna be proposed as that could be a non backwards compatible breaking release. So it's take some things away. But I think, for me, that didn't ask the key question as to whether we should include them. So when I looked at these issues, I had some of that in my mind, but also it's like, do I think the next version of Yang should include this change or potentially include this change? Because sometimes those issues, the description is fairly vague until you understand what the solution's going to be for that particular change, then you can't really decide whether that makes sense to include the language. But, certainly, should we consider this? And the thing that, for me, that I came to avoid is like a second system syndrome where everything gets thrown in, and Yang-two becomes a a language that's twice as size, twice as complex, I think that that would be a mistake. And if you look at, say, xpath1.o is really 1.o, one .one, comma, the first version XPath is really small, and then the next version has exploded, the third version is even bigger. I think that was why, like, in discussions ten years ago, like, do we move to a new version of XPath? Said, well, that's gonna have a big burden on vendors or implementers to, to implement implement a much larger language. So so I think we need to be careful there. So as I said, I went through. I classified them. This was a classification I used. I have, like, the proposed changes that should be made to yang two. So these ones, I think, should be included. I was fairly strong on these, and I split these into clarifications, minor enhancements, larger improvements. Then I had some proposed issues that we should consider. So ones that I said that, I'm not sure. Maybe they should go in the next version, yang. Maybe they shouldn't. I think we should evaluate those. I then had a list of open issues that I said that, I think these ones shouldn't go in. So I was leaning about away from them, like, don't put these into the next version of yang, but maybe down the line, they should be something we should consider. And then finally, I had a, like, a letter list of issues that I thought we should just close and say, look. We never at the moment, there's no intention to ever implement this, so it should be closed. It doesn't mean it can't be reopened in future, but our current consensus or or understanding is this is not a change we think should be made to yang. I know all these are tracked on GitHub. I should have had the link to the GitHub issues tracker yang next issues. I've got links in particular issues to them, but that should be on there. So and what else this should this draft do? So I think it's important for the working group to come to consensus as to what's the broad direction of yang two, as in is it backwards compatible or not? Is it like a yang one dot two or two dot o? And do we allow small small small backwards compatible in backwards incompatible changes? Is it a small update to the language, or is it medium size? Was it large? As in what's the scope of what we're trying to build here? And I think we need to try and understand what that should be in terms of the size of this. And and and not to completely fix it, but just know the direction that we're going. And my proposal here in terms of what I've classified is that it should be like a smaller update to the language. Amit, do you want to come and speak now? Okay. Fine. So in terms of what I came up with, so I had I wanted to allow Numbuck's password changes because I want to remove some things, take away some things out of yang. And then I had issues like clean up the the base spec, and this is the sort of thing that Kent's been driving, take XML out, take the NetComp dependencies out, all that sort of stuff to make the document better shape. I think we should do all those. They're right. They're good. I said we should apply all the clarifications. So 13 issues say, clarify this, clarify that. So I think by and large, those should go in, or we should evaluate those clarifications if necessary. Some of them may some of them may may be that when we try and clarify them, we find there's not consensus as to what a clarification is. Well, that's a different issue. But if there's consensus, we understand what the clarification is, and then and we agree the document's unclear, we'll fix those. I had, some things we should deprecate and remove, so a couple of issues there. And, also, fold in some of the existing extensions and updates, the structure extension, the yang versioning things, tie those into the document. It doesn't mean necessarily to move all the text over, but make yang two dot o sort of require these things rather than being extensions. And then I had a long list, well, 25 potential enhancements to the language, which I characterized into minor and large ones, so about half of each as well. So now's a good time. Brilliant.
[00:41:38] Ahmed Elhassany: Ahmed Alhysen in Swisscom. So I really appreciate the work you have done. It's massive to go over all these issues and try to make sense out of them. One of the things I would like to see, which is probably the emphasis the same point you're raising in the slide, is we need to define the purpose and the scope for the next language. Yep. For example, like, simple example. When I looked back in the old discussions for adding float, not adding float, there was, like, a clear statement from the working group. This is a configuration language. You don't configure floating points. Yep. For example. Right? And this is no longer the case as we see. It evolved. The use cases evolved. So we really need to understand what's the purpose of the language, what we are aiming for, where we want to grow, where we think we should like, okay, this is not part of the language. In in the early days, configuration was the target, and anything outside was excluded out, which is good at that time. Now things changed. The second thing is we have to have some kind of precision and correctness on top of this to make sure that what we propose is accurate and precise and will not lead to some misconfiguration in the in the devices. Right? Because now this is being used to configure many networks and if the language is not precise enough to describe what you want, it might lead to some catastrophic events. So these are
[00:43:02] Rob Wilton: two things I want to add. Thanks. Yeah. It's great, Lois. It makes sense.
[00:43:07] Reshad Rahman: Roshad- Raman, so a couple of things. I agree with what you said as to I mean, I don't want Yang- next to become a kitchen sink of new features. So basically repeating what Ahmed was saying. On the 2.0 and not 1.2, so if you look at between one and one point one, there's a small number of backwards incompatible changes made, if I remember. When we decided two dot two, my concern was always that that meant that we're going to do a large number of backwards incompatible. I don't think that's the case, but that's impression it gives, in my opinion.
[00:43:43] Don Fedyk: So is there
[00:43:45] Reshad Rahman: maybe a question to you and Kent, is there any way this could come back to yang1.2 after we've gone through all the issues?
[00:43:56] Kent Watson: The document was adopted as a two
[00:43:59] Ahmed Elhassany: Okay.
[00:43:59] Kent Watsen: Yang two document. I'm not sure if we wanna reopen that discussion.
[00:44:03] Lou Berger: But the repo is called Yang next.
[00:44:05] Kent Watsen: No. So Yeah. Two repos.
[00:44:07] Lou Berger: There's Right. Right. But the the one he has with the issue tracker is called the yang next. Mhmm. I I I think we shouldn't get caught up in this. Let's let's not get caught up on it. Let's do the technical work, and we can always change the name at the last minute if we we want to. Let's just focus on the work and then worry about naming at the end. Yep.
[00:44:29] Marek Laco: Maria from Bert. Looking at the sheer amount of the of the issues, it looks like it's gonna take five more years to get Yang-two or whatever else. And I'm asking a question. Does it make sense to propose parts of the issues which are more more painful and like more pressure pressing as a separate drafts? Or is it expected to get all of these things postponed into the yang-two? Because, for example, with the three different codings now emerging, the problem of transcoding is getting quite quite hard. So whether it's a an idea worth drafting and and pushing before yang two or whether we should wait with it and deal with the consequences so that there would be some incomparabilities?
[00:45:21] Rob Wilton: I think that's an interesting question. I I think my theory is that even you try and take a smaller set of key pressing issues, that, it still take quite a long time to get consensus. So so I don't know. I I do feel about the what the timeline should be on this. And, again, I think that's part of agreement of the scope of it is that if we're saying we want it to be shorter and quicker, I think that says you do less stuff in it. So so yes. And and I don't think the I think the one thing to be aware of is is I don't think we can publish a yang one dot two and then a yang two a year later. I think that actually because of the industry that that probably publishing a new version of yang every five years or something is about the right cadence. So that's the one thing I'd say that's against just doing a smaller release because it's not the same as software release, I think. But all the tooling will have to change to pick these up, and it takes time to roll this through the industry and time for, like, modules to be updated to use this stuff. So so I think I'm feeling like I I think we should just try and do one release, and we should try and maybe scope it to be smaller if that's more important to get leasing sooner.
[00:46:32] Marek Laco: Yeah. So if I understand correctly, the pressing issues could be pushed separately while the work on the bigger draft is moving on.
[00:46:40] Rob Wilton: Yeah. And, I still think it's a good point is that yang has extension mechanisms and as part of that. So the really big things that we do, I suggest that doing those as extensions, like the yang versioning work is the right choice. I think some of that is good. And then they can be folded in as, like, yes. Now this new version of yang says this extension is, like, mandatory. Everyone does this.
[00:47:01] Marek Laco: Yep. Okay. Thank you.
[00:47:02] Lou Berger: Yeah. I I think it's a great topic. And as a working group, we have not said that we're not going to do other work. We're not saying everything has to stop waiting for YANG-two, and we are contribution driven. If you have something that you'd like to bring forward, like the versioning work, we can consider it. But as a group, we have to agree to do the work. And as a group, we may say, yes. This is worth doing. Or we may as a group say, let's wait for yang two or yang next.
[00:47:33] Rob Wilton: I'll ask this question. I might then move on to I got a couple of slides I definitely want to cover. There's a load of extra stuff, backup stuff, but I think it'll be good to cover in terms of the next process. But yes.
[00:47:45] Marek Laco: Minor comment. If you want to include the packages as a mandatory dependencies, wouldn't version two be more appropriate?
[00:47:56] Rob Wilton: Maybe. I don't know. And I'm not sure yet whether packages definitely gonna be a dependency of Yang two or not or whether packages is too new for that, so I I don't know yet. I I think this is sort of thing is we need to work out what's in the next version of language, and then we choose the number at the end. I don't think we should get I'm making a bite shot on on the version number very quickly.
[00:48:16] Lou Berger: Yeah. Personally, I would not I don't think it's a good idea to take work that is in flight and we've been doing for a while and say, oh, now that we've started the Yang-two discussion, we're gonna table that work. Oh, no. No. I think that that it would be a bad precedent for the for the group speaking as both a contributor and the chair. Now that said, as chair, I follow the group. So if everyone in the group disagrees with me, even though I'm chair, the group wins. So
[00:48:44] Rob Wilton: I hope that wasn't a suggestion. Maybe it'll be some such. But Jay?
[00:48:46] Joe Clarke: Now, Michael is here, so, I wouldn't have been able to say this later. One thing that he pointed out to me is part of the yang versioning work is actually the move from yang one to one one is non backwards compatible by definition. So I guess I'm saying, in short, I support two dot o since it doesn't seem like it matters much at the version level of the language.
[00:49:11] Kent Watsen: Yeah.
[00:49:12] Rob Wilton: Yep. It's just Naomi. Okay. So this is this is the next slide, I think. Yeah. Fine. This is the one I wanted to definitely cover. So what the the plan I proposed haven't discussed this with the chairs. Probably should have beforehand. We can discuss it now. So the aim of the draft is just to get consensus. I don't think we have a plan to publish this document. It's a working document to try and help the the working group come to consensus. So don't publish it. It's just a starting point. This is just my views. It's been adopted as as a method to go forward, not the the what's in there currently in in those two particular categories is correct. It's just like we should try and do some classification and specification and agreement, consensus on what it is gonna be. My expectation is that mostly we'll track these issues through GitHub as we are today, so we're kinda doing that. And then, I will update the document on or kindly LLM will update the document and publish it for the IETF meeting so people can see what the issues are and to summarize them. Sorry. And then and then yes. So use GitHub issues and have some more labels. And then the plan is to have, like, regular meetings, propose, like, a two weeks cadence for having these meetings to discuss and get consent on the issues. And then I what I propose is if there's strong consensus that some things are going into yang2.o, like the restructuring stuff or the clarifications, we should do the clarifications, then there's no reason why we have to wait for this work to complete before we do changes to the yang2.o. If the consensus on as to whether we include a change is weaker, then maybe some needs to write up a bit more, and maybe we need to hold off merge until we get to, like, proper consensus. So we need to figure that out in the process. So but I think a lot of these things, people will just say, yes. We should do this, obviously, and then it's fine and it's clear. Where some are if there's some sort of disagreement or consensus is more rough, then I think we need to be more careful about folding those things in. I may enact some tooling to help, evaluate consents on these on the issues. So I asked an LLM. Again, you can see my, my my fan to generate, like, some, interactive web pages discussing these issues and tracking consensus, allowing actually people to vote and see what people's votes are. Now, the henchmen are like, oh, it's horrible. You're not allowed to do voting in an IETF. But that's not, in my mind, as part of consensus call. It's about is it the process of trying to evaluate and see where the consensus lies? So, I will see if people are interested in doing that, and we don't have to use it. But the aim is for, like, more efficient than using the Meetecho show of hands tool. I can show it to you afterwards because it allows you to hopefully see people's views more quickly than doing show of hands for every single one of these 150 issues and all the discussions and things. So that's the aim.
[00:52:00] Lou Berger: Yeah. I'll point out that authors and particularly editors have a lot of flexibility in how they judge consensus on the document. Yeah. And whatever process you take is great, and we'll bring it here and confirm the consensus. Yes. So you have a lot of flexibility on how you wanna run the document.
[00:52:15] Rob Wilton: Okay. Fine. And we can see see if it works, and and if it doesn't, then we can go and use different methods and things like that. But that was the idea.
[00:52:23] Mahesh Jethanandani: Mahesh, I was when the document was initially submitted, it sounded more like a suggestion. This is how we could do things. And I think if I get the sense now, we move to a sense where Yang-two is saying that we need to make we are kind of dependent on this particular document. Maybe my sense is wrong. Maybe Ken can correct me. So my question really is, again, from a process perspective, do we are we saying we will we have to agree on these set of issues, whether they need to go in, they need to be closed, they need are folded in before we make the decision? Or is this document still going to remain as kind of a guidance? I'm a little confused to what the proposal is, really.
[00:53:15] Rob Wilton: Can I answer first and then then I'll let Kent say? So my thoughts of this is it's a it's a living document that lives alongside the updates to yang2.o. So as we as we are confirming what's going in and it will change because some issues people work on and get more more understanding, and some more issues might come in, and those sorts of processes may change at the time. We could be updating yang2 to o yang two at the same time. I don't think this should be happening before, and then we do yang two. I think we could do these two things in parallel. But it's I see it as a way of trying to track those issues, make more sense of them, get consensus, and to let the working group know what's being agreed, what's in scope, and it's a living document in that sense until we finish yang two, then we kill it, delete it. Yep.
[00:54:01] Kent Watsen: I agree. And furthermore, to add to that, the what we the yang next issue tracker will be the source of truth. So as this document is being updated, the hope is to actually update those issues to capture what is the current feeling on issue by issue basis.
[00:54:16] Lou Berger: Okay. Additionally, from a process standpoint, one of the things that has hurt many pieces of large work is having to come back and have the same discussion over and over again. So for me, capturing that we've had the discussion and what the results of the discussion is really important and a really helpful thing to speed the work along. Now, that's not to say that we can't discuss an issue that we decided on. Let's say a year goes by, we say, oh, we've learned some new things, let's revisit the discussion. That's okay. But having the same conversation over and over again is not. And from my standpoint, that's one of the big wins of this document or this work.
[00:55:00] Rob Wilton: I'm out of time. And there's no more questions.
[00:55:03] Lou Berger: It's a significant enough thing. We can steal time if you have more you wanna talk about.
[00:55:07] Rob Wilton: Well, I all I'll say is I don't think we should talk about now. The backup slides have proposals. So in there, if there was time, was gonna do consensus checks in the room, but I'm not sure. I don't think we should rush this now.
[00:55:20] Lou Berger: I I agree. The this might be a good candidate for an interim. Yes. And we've, used interims before when we've had good and and used them to really help move the process along. We should think about that. Yes. Maybe after the summer, though.
[00:55:35] Rob Wilton: Yes.
[00:55:35] Lou Berger: Not in August. And with that, we have a couple of presentations by Kent.
[00:55:40] Kent Watsen: I I I was gonna get it set up for you. Okay. Pass the light control. Didn't mess with the k. Good morning, everybody. I feel like I'm gonna do a hot RFC topic, lightning talk. I originally allocated fifteen minutes for two presentations. I'm gonna squeeze to five. Alright. So the yang two document has been adopted, which is an incredible milestone all of its own. The current status is that the apply errata branch was merged and as well as the make baseline branch. So all this means is that all the verified and held for hold for document update errata have been merged or applied. And as Rob mentioned, the xml and .com specific bits have been removed. The document is now in great shape to start accepting pull requests. So anyone who has a GitHub account can try to make a pull request. If it's one of these obvious things that we want to do, as Rob just mentioned, then it could get merged quickly. But if it's one of the things that we're still concerned, then we'll probably go through a lengthy discussion process. How is the process going? So I did I discussed last time the idea of having a pool of codoners to self volunteer to review PRs, that a PR could be merged after three such approvals. Current result is that the reviews didn't come quickly. For both of the two previously mentioned PRs, we received two explicit approvals and there was one implicit approval. I had to force merge those PRs, but deemed it okay since the edits were mechanical in nature. The takeaway is that we may need to schedule some regular meetings to review PRs. Possibly, that would be a good thing anyway. Next steps is that we'll wait for the PRs to be submitted, reviewing them in turn. Many PRs would likely take will be gated by the Agnix agreement document. And that said, there's a number of obvious items that can work on now. Any
[00:57:50] Lou Berger: comments? Questions?
[00:57:57] Reshad Rahman: So I forget whether we discussed this, but how do you intend to cross reference I mean, there's Rob's doc. There's the issues in GitHub. I mean, if I come with APR, I mean, you want some you need to know some minimum information, what issue it is in the GitHub tracker and stuff like that. Right?
[00:58:16] Ignas Bagdonas: So Mhmm.
[00:58:17] Reshad Rahman: I think you should
[00:58:18] Kent Watson: When when you open when up you create a PR, there's a PR template. Okay. And it automatically initializes with the sections. The first section says, identify which issues it closes. Okay. And you can close issues in the other repos in the other repo, and it shows you how
[00:58:32] Reshad Rahman: the syntax for doing that. Okay. And then how do we check Rob's doc? Is that in the workflow? Or
[00:58:40] Kent Watson: Check what?
[00:58:41] Lou Berger: Oh, Rob's Oh,
[00:58:42] Kent Watson: Rob's doc.
[00:58:42] Vivek: Yeah.
[00:58:45] Kent Watson: I could add that to the template as well.
[00:58:48] Rob Wilton: So this, have a thought about. I think that probably we want a build script that automatically updates that document. So, like, as these issues get updated and things, we just regenerate new versions internally and we publish them for each ITF. So that's and I think the tooling can do that.
[00:59:15] Kent Watsen: This presentation's even faster. Again, the document's been adopted. It's a good milestone. Current status is there was no updates since IETF 125. We just simply renamed the document for the adoption. Next steps are to update the document as needed to reflect changes in the dank-two doc draft and such as, for instance, removing the anyxml node. I don't know if there will be any other updates to this document other than removing the anyxml node, but we'll hold this document open and then progress it with the Yang-two document together. So there'll be plenty of time to discuss if there's a need to make any other changes to this document. Yes?
[00:59:56] Ahmed Elhassany: So, Ahmed, so for the XML document, is the purpose of it to redefine what's in YANG or just to focus on the encoding?
[01:00:07] Kent Watsen: Sorry. Can you repeat again?
[01:00:08] Ahmed Elhassany: For the XML document, the YANG encoding of XML. What's the purpose of that document? Is it redefining what is in YANG or just the encoding only?
[01:00:16] Kent Watsen: It's not redefining it. It's it's it's moving the where is the definition normally defined? Okay. So that becomes the normative definition, kind of like how RFC seventy nine fifty one does the normative definition for JSON encoding. Yeah. And and then in the yang two document, there are still XML examples, but they are truly just examples.
[01:00:35] Ladislav Lhotka: Right.
[01:00:36] Kent Watsen: And what I've done, wherever there's an XML example, there's a JSON example as well right next to it.
[01:00:42] Ahmed Elhassany: So That's great. So for the current version of document, at least for the any data, it's kinda redefined again in a weaker language than 7951. So we'd like to please take a look at this and make sure that this document doesn't add confusion on how the the containers is defined there.
[01:01:01] Kent Watsen: Okay. Thanks.
[01:01:04] Rob Wilton: You have another one?
[01:01:07] Marek Laco: Maria from Bert again. Considering that we are expecting to remove the NEXML thing and probably more more other, it looks like we should else also update 7951, and we should probably look at updating YANG CBOR. And with that, I am thinking whether it wouldn't be a good idea to have all those four drafts in the same in the same repository and actually check that a one pull request not only changes one document, but does the change in all four of them if it applies. Because if we don't do this, I'm quite expecting discrepancies. I don't know whether it's a good process, but I am looking for the potential problems before actually happening.
[01:02:04] Rob Wilton: I think actually that we might not need to do that because those encoding still need to support the older versions of yang, so they still need to have the definition of any XML, I think, in them. I am not sure about this one. This one might be exception because you are publishing it later. The other ones, I don't think they need to change. Okay.
[01:02:21] Kent Watsen: Right. I mean, there could be a number of documents that will have, you know, collateral impact. Rob mentioned earlier this morning about NMDA and if there'd be a need or desire to update the NMDA document as well. I don't think I think that's orthogonal work to this and what doesn't need to be impacted at this time. But at some point, the working group should think about maybe rolling in the factory default and the system data stores into the NMD data.
[01:02:49] Ahmed Elhassany: Alex, coming back to the question from Maria. So the plan here is to work on XML and JSON and Cboard later, or what's the plan there? Or how how do we deal with JSON encoding for YANG two?
[01:03:08] Kent Watsen: Well, I think Rob mentioned before, the actual current RFC 7951 is accurate. Just because yang-two removes any XML doesn't mean that 7951's wrong.
[01:03:24] Rob Wilton: Rob Bolton. I was going to I was gonna say that there's any change to those documents, but I suspect there might be. So if we add in, for example, float or double, which I think is one of one of the things I would like to see going to language, then there may be minor updates to those documents. But I think that I'm not I'm not expecting big changes to the encodings for yang too. I think more it's gonna be more about other parts of the language, is my gut instincts here.
[01:03:49] Kent Watsen: Agreed. Thank you.
[01:03:52] Lou Berger: Okay. Now we're gonna go back to the skipped Yang schema comparison presentation.
[01:04:09] Jan Kundrát: So hello. Here from. Yes. So first sorry for for being late. Yeah. It's my planning plus the train was late that I
[01:04:21] Ahmed Elhassany: Got it. Yeah.
[01:04:23] Jan Kundrát: Sorry. Yeah. So I'll go quickly over the changes since the last IETf in the schema comparison draft. Yeah. So first, some some background of this work. The goal here is to define an algorithm for comparing two revisions of a young module in the sense that, like, the additional goal is also to define or to generate an explicit list of all the changes between these two modules and also to classify every change as an editorial, backwards compatible, or non backwards compatible.
[01:05:18] Mahesh Jethanandani: Currently,
[01:05:22] Jan Kundrát: there's one standard YARM module, which is actually quite small and includes only a few extensions that allow for precise classification of certain changes of statements that are impossible or like next to impossible to classify automatically by tooling. So it allows for authors of the modules to add this information if they if they want to. And then there's the other large normative yang module, which defines the exact algorithm output in the form of a Yank data tree. And all of this work is in sync with the Yank semantic versioning team and and the whole work. And the idea is to use all this information then to suggest or check the semantic versions of young modules, essentially. So the specific changes that occurred, we have added editorial change support, which was not there initially because the current RFCs are not exactly clear on what editorial changes. But yeah, I think we cleared all that. So now it's supported. Then also the text explicitly defines, not in, like, completely exact terms, but it's a definition, at least, of an editorial of backwards compatible and also of a non backwards compatible change. Yeah. And the young modules were a split before or like the state during IETF 125 that there was a single large young module. But, yeah, now it's split into two young modules, only the small one being standardized or like the other.
[01:07:45] Michael Richardson: Then
[01:07:49] Jan Kundrát: also example was added to better illustrate the algorithm output, which can be quite convoluted. And there are also some improvements in the wording of the text of the draft. Now, yeah, regarding tooling, like the main implementation, it was done in Libyang. And yeah, it's it's pretty much follows all the changes in the draft. So, yeah, it's like anyone can try it if they if they want to. And it generates the full algorithm output. Then there's Bijang that Joe Clark worked on. And it detects all the changes in the modules, but it does not generate the full algorithm output. But it suggests the young sample, yeah, for the new revision of the young module. And, yeah, naturally, the idea or the goal is is definitely for all the tools ideally to classify all the changes in the statements in the same way, which is currently not the case yet fully. There are some some corner cases that we are still still working on. But, yeah, when the draft is finished, it will definitely be the same. Yeah. So what next with this draft? Yet the idea was to have the other members except for to at least briefly look at this document and provide some some feedback. And, yeah, after that, unless some some other someone else comes with with their reviews, it may be ready for the last call. I I hope.
[01:10:02] Lou Berger: Just to be clear, do you need another version, or do you think this version is ready?
[01:10:09] Jan Kundrát: Well, I think this version is ready pretty much. Or
[01:10:14] Lou Berger: Do we wait for you to do another version, or should we move forward with a a last call?
[01:10:20] Jan Kundrát: Ah, it's it's not yet in the in the in the last call.
[01:10:23] Ignas Bagdonas: So No.
[01:10:23] Jan Kundrát: But okay. Yes, sir. I I don't exactly understand the the process maybe.
[01:10:27] Lou Berger: Are you planning to do another version at this point, or are you done with planned changes?
[01:10:32] Jan Kundrát: With the draft, you
[01:10:32] Reshad Rahman: mean. Correct.
[01:10:33] Jan Kundrát: In the draft, I'm done with the change.
[01:10:35] Lou Berger: Perfect. Thank you. Yeah.
[01:10:36] Rob Wilton: So I've got on my queue of things to review. This is one the other, authors of this, document. So I will review, shortly after this meeting, and then maybe based on that might be a good indication as to whether we think it's done.
[01:10:50] Lou Berger: Okay. So, what I'm hearing is everyone in the room, feel free to do a preread for, before working group last call so you don't have to wait for working group last call to make comments. We should expect one more version, and on that version, we will do a a a last call.
[01:11:06] Rob Wilton: Yes. Okay. I want to make one other comment, so thank you very much for coming and presenting. I'm sorry for your train issues and things. That's actually fine. I'm just going to say, on the first slide, you said we have a nominative output module. I can't remember what we came to a conclusion with this. So, effectively, we, it defines a YAM model of how you could Tony how Tony could generate the output. I think we weren't saying that you had to follow this, but it was like, here's an example of what you can do. So, I think it's just a question of whether people think that having that as an informative thing or actually a strict output of how we format the the the data. I think it'd be an interesting discussion. I don't have a strong view either way.
[01:11:48] Ladislav Lhotka: Just a clarification. When you said it's in Libya and implemented, is it in the Yaenglind already? So can we review the output of Yaenglind?
[01:11:59] Jan Kundrát: Yes. And it's mentioned in the draft exactly how you can try it. So feel Thank you. Feel free to. Yeah.
[01:12:05] Kent Watsen: Thanks. Yeah. Always reaching. We're No. I'm actually good.
[01:12:11] Lou Berger: Alright. Well, thank you so much. We're gonna move on to the next.
[01:12:16] Kent Watsen: Okay. Thank you, everybody.
[01:12:19] Vivek: Thank
[01:12:22] Kent Watsen: you. Okay. So Kent Watsen presenting on behalf of
[01:12:25] Lou Berger: the other Just to be clear, we're moving now from working group documents to individual documents. We will be doing time out on these. Thank you.
[01:12:36] Kent Watsen: Pass. Slide coder control.
[01:12:39] Lou Berger: Oh, sorry. I thought I did. Yeah. But now
[01:12:48] Kent Watson: Okay. Perfect. So quick recap. We've been working on this for a long time. The zero three update at a very high level view, the diff itself isn't huge, but it's everywhere. There are many small tweaks and a few big tweaks. Big tweaks include improving section three, overhauling examples, updating appendix a, and updating the authors, editors, and contributors section. By the way, I'm presenting because I'm now an author, co author. Rob Wills felt like he didn't have time for it anymore, the authors asked if I could help him out. Work remaining. As discussed in the up there's a number of items, sort of three items that will be discussed in upcoming slides. And but before IETF 127, I hope to have reviewed all the requirements for accuracy. At the in the appendix, there's a requirements matrix, and it's there was an issue found there, which I'll mention in the upcoming slide. So that cause causes me to want to re review all of them for to ensure accuracy. Also, I'm thinking to that there we we may wanna have a third virtual interim to score the new template requirement issues added since the last virtual interim. I think about 10 new issues were added and those should be reviewed. And also to reconsider the requirements section. Currently, three in the document, I wanna re review that and maybe re characterize it. So those are some changes they might wanna make. Okay. So for the three issues I mentioned, the first, probably the most important, is that templates must be validated when defined. So this is as opposed to when they're applied. Because when they're applied, then, of course, there's a commit which gets validated, the full validation. So that's not what we're talking about. We're talking about just when they're being defined and not yet applied. At IETF 125, there was consents that early warning is goodness and that best effort yang validation would have to take place because, of course, the actual template itself may not have a mandatory leave even though you think it should be there. It's actually allowed to not be there. And likewise, that that anydata is the appropriate yang type for the content node. The questions remain for how implementations would do the validation as a template may be an instance of data anywhere in the schema tree. One thought was to use the AnyData validation draft, which is currently expired, but but there were some problems found with it. For instance, specifically, we as just mentioned, we don't we wouldn't actually want full validation with the any data validation draft. I think it's leaning or leaning in towards trying to do full validation, but here we wanna do sort of a template validation, which is a subset of full validation. Likewise, it seems unnecessarily heavy involving yang library. We really need something like yang library to support this work. And it doesn't support validating inner nodes, which may be important here. So the proposal is to add a new leaf called schema path of well, here it says YANG XPath, but I'd love to use ypath if it becomes available to to identify where the template is rooted in the schema tree. So you can kinda see the update of the tree diagram on the side there. Any comments, questions, concerns on this slide? No? Okay. Oh, that's one. Okay.
[01:16:30] Ahmed Elhassany: So just a clarification as a coauthor of the AnyData validation, the complete validation is not required by the AnyData. There are two option. You can choose whether you wanna do complete or candidate validation. So these options are, like, open in AnyData validation. Right? So it's not only about complete. Just to clarify that point. Yeah.
[01:16:53] Kent Watsen: In any case, it's more than needed for this work. The second item or second issue is actually no longer an issue. This, in fact, turns out to already been resolved. There was a mistake in the minutes for the virtual interim. The minutes which were used by the draft incorrectly show strongly in favor, while the actual show hand pulls show unanimous objection. So we thought that this was something that we had to work on, but now we don't have to work on it. So problem solved. And the third item is to enable non MMDA servers to return the expanded data. The issue here is that the current draft defines that the template expansion is returned via get data from intended but remains unspecified for servers not implementing NMDA. So how do we support the NMDA servers? The proposal is to define a new expand template flag for the get and get config RPCs and likewise query parameter in the rest conf. This would be consistent with existing implementations. I'm familiar with a number of CLI. For instance, you can do this show interfaces pipe display inheritance as an example, and so that would be reflected in in basically passing a flag in those RPCs. Any comments, questions, concerns with this item?
[01:18:24] Joe Clarke: Joe Clark. On the previous slide, a resounding meh from me. I would have said yes. So I I I would have raised my hand in support. I I'm using a template a yang based templating system in in a product, and I find the basic programmatic elements to be useful. Loops basic loops and conditions are extremely useful. I get that that's added complexity, and I get that maybe that's for implementation. But I I'm shocked that it's unanimous objection since I'm pretty sure I would have raised my hand in support of this. I I think it's I think when you actually start to use this, you find it's pretty useful.
[01:19:05] Kent Watsen: And it could have been that the objection was not so much it's a bad idea, but we don't wanna do it in the first go.
[01:19:12] Joe Clarke: And I'm happy to be in the rough, but I think this is gonna be used.
[01:19:18] Rob Wilton: Rob will turn on the next slide, please. So I think you asked I I don't think I have concerns to this approach. I did just wonder in my head is another solution here is to say that, if you're supporting this solution, you have to support get data on, one of the name intended date intended data store might be another choice, but I'm happy with what where the direction you're going. It's just occurred to me that it might be another another choice.
[01:19:45] Kent Watsen: Well, if it's a non MDA server, then they don't have an intended data store. I thought you were gonna say, what happens for an MDA server? Would it make sense for them to also support this fetching from running? And I would not think so, but it it could be, and perhaps that's a
[01:20:01] Rob Wilton: product decision. No. I mean, I I I thought the whole purpose of Intended was that you therefore mitigate this, so you don't need to do that. But yeah. Okay.
[01:20:13] Reshad Rahman: Richard, so on the I haven't read the doc in a while. Just so when the client does it get with an MDA or get data, does it get back expanded config or non expanded?
[01:20:25] Kent Watsen: From intended, yes. If you do a get data on intended, it's expanded data, and the unexpanded templates are removed.
[01:20:32] Reshad Rahman: Is there any way for the client to get non expanded back? No. Okay. Because we we do stuff like we do what's the right? Sanity checks that what we're pushing, and then we read the config back to make sure that nobody has done any changes. So if I understand what you're saying correctly, we would be pushing something, but what would be reading back would be different? Or did I misunderstand?
[01:21:02] Kent Watsen: The clients interact with running, so they read and write running. And then running is merged with system to create intended. The templates are expanded in template and right in intended, but that's what NMDA says to do.
[01:21:18] Reshad Rahman: I'll read the doc a bit more because I think that if I understand correctly, that might be a bit of an issue for our use cases. Yep.
[01:21:32] James Cumming: So James going. Just sort of agreeing with with Rob, really. I don't know that we need to provide this to a non NMDA. You know, the whole intended and operational is NMDA only. Get data is really an NMDA only. So it feels like maybe this this could be an MDO in your solution as well. And in terms of Richard's question, then, yeah, we would be able to read the unexpanded one back from running quite happily and then compare it to the expanded version. But I can if I understand correctly, your proposal is to remove the unexpanded template in intended in the expanded version, which I agree
[01:22:14] Kent Watsen: Well, that's correct, but it's not just my opinion. It was the consensus of the virtual interim.
[01:22:18] James Cumming: Yeah. Absolutely. Yep.
[01:22:22] Kent Watsen: Okay. And
[01:22:23] Lou Berger: By the way, I did go look back at the notes. I don't see, unless I'm missing it, I don't see the decision that you say was here and Joe didn't remember. Just looking at the notes, it it was, I believe, issue eight, and I don't see it in the minutes.
[01:22:39] Kent Watsen: Which issue? Well, I mean, which
[01:22:41] Lou Berger: A couple slides back. The one on the the the programmatic.
[01:22:46] Kent Watsen: Mhmm. Oh, well, we'd have to go to the show hand pull, but I can I don't Okay? Have the data over here.
[01:22:54] Lou Berger: No. No. That's fine. I I just went back in the minutes trying to find it, and maybe it I didn't
[01:22:59] Kent Watsen: Oh, did you follow the hyperlinks?
[01:23:01] Lou Berger: I no. I went to the one on the on the website.
[01:23:03] Kent Watsen: Share the report. Mhmm.
[01:23:05] Lou Berger: So all I'm saying is that it we should consider it still open for discussion. Mhmm. And, of course, until we go to working group last call, they are.
[01:23:15] Kent Watsen: As I said, at the beginning, I found an issue. I am going to thoroughly rereview all of the show of hand results and ensure that the requirements matrix at the end of the document, the appendix, is correct. So significant effort has been extended to this effort already. The authors believe the current draft is a viable work in prog work work in progress working group effort. Like Yang-two, we feel that the effort doesn't need to be complete in order to
[01:23:43] Ignas Bagdonas: be
[01:23:43] Kent Watsen: adopted, only an assurance that the requirements will be satisfied as needed. So we were wondering if it would be interesting to get a show of hands for adoption interest.
[01:23:58] Lou Berger: Alright. I'm gonna start two polls.
[01:24:01] Kent Watsen: James, are you on queue? If
[01:24:07] Lou Berger: I can find the there we go. This one should, I'm hoping is pretty quick. Are there and is there anyone in, in the room online who objects to the work working group working on templates? We've had interims. We've had lots of discussions. I'm expecting this to be, all nos, but it's always good to check.
[01:24:41] Rob Wilton: Excellent.
[01:24:44] Lou Berger: And the second one, it's a pretty standard one, is what is the what do people, participating think about using this draft as it stands as the starting point for the work in this working group? Well, great. I think this poll shows that we have pretty good support. The most important thing to me here is that there's no objections. If, of course, we'd wanna hear from the person or people who objected, maybe they are just reluctant to come to the mic. But no matter what, I think this shows pretty agreement that we have a a good foundation for our work in this area. Thank you all. We're gonna move to the next
[01:25:42] Kent Watsen: Okay. Thank you very much.
[01:25:43] Lou Berger: Presenter. I think it's Rajesh who is going to be remote. Give us just a moment. I actually didn't confirm that Rajesh is online. Excellent. Give me a moment. I'll pass controls to
[01:26:09] Kent Watson: I got it.
[01:26:14] Balaji: Hi, everyone. Sorry I couldn't make it again another time, but let me just quickly go over the AI enhancements to capture some training, please. I've presented this in IETF 113, year or so back. Go to the next slide, please.
[01:26:33] Lou Berger: You you should have the control.
[01:26:37] Balaji: Well, I did see it for a moment. It does show up now.
[01:26:41] Kent Watson: Let me try. Let's pass it on. Yes.
[01:26:44] Balaji: Now I do. Thank you. So just to recap the problem statement, the yang yang models are, of course, evolving, and definitely, the notes often have replaced some guidance. But today, the guidance is is usually out of band. It's pros. It's Excel sheets. It's literature that engineers have to read to understand in order for us to do or migrate it to the next version. Okay. Right. So it's not machine readable, and it requests manual migration. So this this is the problem we faced at our work, but it is not. We were not the first to identify it. It's part of Yang-next. It is good to see a discussion on what we propose to do for Yang-next, but we're not entirely sure how soon this might be available. So what we're trying to propose here is yang one one dot one extension that could achieve this. Just just I just did a quick scrap of the yang models, yang we have repo just to look at what kind of deprecations are happening on real yang files that are posted here. This is just for the last couple of years, and what we have actually done is to look at valid experts that then were deprecated in the subsequent version. And we have a fairly significant number of them. This is definitely a lower bound because there's weighs so much for Yang out there, and I've only taken a small sample from one of the records. Again, I've not covered all all the companies, out there either. This is representative from some some vendors. The solution itself is, obviously, authored more detail in a more detailed manner on the draft, but it's essentially if you had an old leaf whose status was deprecated is being deprecated in this version, we have an optional opt in extension that we call as a deprecation info that should point you to the new node that has to now be the new leaf that has to be used now from this version. We handle different kinds of situations where it's a straightforward, absolute new leaf. Then you have groupings, things are a little different. It's a relative part. One note, one lead could now map to multiple leads. Multiple leads could come down to one. All the all those scenarios, you could even have cases where you do not have a replacement for a leaf of moving on from this version. So we had a good discussion in the last meeting. This is what essentially, what it is. And what we did since IETF 113, and this is not an exhaustive list, I'll talk to some of them. We had I think Kent had some questions about why would we handle it for both observations as well as deprecation. So now it's been emailed to just deprecation info. We do not have it for, observations. Lou, And, you you questions on making sure that the problem statement was very clearly defined. We did go around the room. We agreed there was consistent problem. Rashad, our email had several questions about where this deprecation enforce applicable to what kind of leads. So we've made that both in a, b, and f and clarified where it's allowed, where it's not. Deepak had questions on using instance data and problem balance did clarify that this is a design time knowledge that will be useful to both machines and other tooling that could use it. Here at Cisco, we have a we do have a prototype of the implementation, which we rely on heavily because we have to keep our network management systems in sync with changing yang versions on the I o x e and I o x r releases. And as as those change okay. I'm sorry. Maybe I should pause there. A few questions, I didn't notice that. Let me take do I take questions right away?
[01:31:30] Lou Berger: Balajdan choose whether you wanna take it at the end or take it in line. You wanna take it now? I
[01:31:37] Balaji: mean, it's just a one more slide. I'll I'll just wrap it up, and then I can take all questions.
[01:31:42] Ladislav Lhotka: Balajdan- Balajdan-. Balajdan-? I think in Yandex, there was already a proposal to add a substatement to status. And I think that's this is where it belongs to indicate, for example, what is the replacement. So, I think that your proposal is good, just it should be a substatement under status and it will be good to fold it into the Yang-next effort as well.
[01:32:12] Balaji: Okay. Okay. Sure.
[01:32:19] Kent Watsen: Sorry. Ken Watson as a contributor. I think it's RFC one twenty three that you presented this work, and it was a string. Can go back to slide number five, please? It was a string. And at that time, I had suggested instead of it being just a string, there should be a structure of some sort At a in the YANG next issue that Andy Bierman filed, he shows that there's a description statement also. Like, why did it get deprecated? And there's other information that could be, like, when did it get deprecated? And there's and and in the future, we might even have, well, for instance, like an XSLT that could actually do the migration step into the structure statement. I think these things are important, especially in the age of AI, agentic work. We want to enable the tooling to be able to understand what how to manage the devices better. Thank you.
[01:33:16] Balaji: Qiufang Sheng from Huawei. So I don't think we should wait till the young next step. That would take long time to be published. I think it's a real problem. We have already implemented this in our products. So I support adoption of this. Okay.
[01:33:36] Kent Watsen: Go ahead.
[01:33:37] Lou Berger: No. The queue is locked.
[01:33:38] Kent Watsen: Oh, sorry. I thought we were ahead of time.
[01:33:43] Lou Berger: Please go on.
[01:33:47] Balaji: Yes. So I here are all your points. I mean, we just want limited to not move to the semantics part of the migration, but to the syntax part. So we have an ABNF.
[01:34:03] Kent Watsen: And,
[01:34:04] Balaji: yes, so just just wanna summarize here the I think the problem is real as we just acknowledged. The proposal is narrow, and it's deployed with the YANG 1.1. And more than happy to work with the working group to fine tune and make this unacceptable proposal.
[01:34:21] Lou Berger: So I've started a poll asking the working group if we if we think we should be working on this topic. I didn't introduce the word now, but I I I hope that's implied. But I should have said, should we be working on it now as opposed to waiting for yang next? Give it just a moment more. Again, that shows, I think, some pretty good support and no objections. Now we'll move on to whether or not this document is a good starting point. So, basically, are we interested in adopting this document? While we continue the poll for we have one person who has said no. Would they mind joining the queue and giving us the rationale?
[01:35:28] Kent Watsen: That person would be me as contributor. Well, as mentioned, I I mean, I do support the work. I I I said yes in the previous poll question, but I don't think it should be just a string. I and since I made the same statement two IETFs ago and it hasn't progressed, I I don't understand why we should progress the document at this state.
[01:35:47] Lou Berger: You don't think we can fix that as part of normal working group processing?
[01:35:53] Kent Watsen: We could. Okay. But I haven't heard back from them. Or
[01:35:56] Lou Berger: Well, that's the interesting thing is is that when it's an individual document, the individual controls the content. But as soon as it becomes a working group document, we control the content. So the only way to enforce changing it is to make it a working group document.
[01:36:12] Ahmed Elhassany: Alright.
[01:36:15] Lou Berger: So I think we show some pretty good support. I would expect that as part of the adoption call, you're going to get a comment at least from one person on a change that they would like to see made during worker group processing, which I think is quite reasonable. Okay. Oh, go ahead.
[01:36:33] Ladislav Lhotka: I didn't say that I didn't want to say that I don't support this for now. I'm just not interested that this is something that is going on now, but it would also be good in Yang-next. How will will we start a new issue for Yang-next on this?
[01:36:48] Lou Berger: It's already an issue in Yang-next. Okay. Of course, anything that we if we're going to remove something as part of YANG-next, that will be subject to, I think, significant discussion. Mhmm.
[01:37:03] Ladislav Lhotka: I think for anything that new we are doing today, it's a decision that should will it stay as a separate draft or will it be folded into yang-next? For example, templates, will it become part of yang-two, or will it stay separate?
[01:37:19] Lou Berger: I think that's great discussion for yang-next, and I'm really appreciative that we have energy for it. With that, we're going to move on to the next presenter. I think that's Don. And thank you very much, Rajesh.
[01:37:38] Balaji: You're welcome. Thank you.
[01:37:41] Don Fedyk: K. Hi. Don Fedyk. Yeah. Do I have the clicker? This is a long story, but we'll we'll go fast. A a long time ago, people decided they're gonna do yang, and I came into this story a long time after that. And I was taught to validate Yang here. So I took it to the I triple e. And I asked people, hi. Why do we have multiple formats of MAC addresses? And it turned out we had these two formats, and we said, wow. We should fix that. And a lot of time passed, and we didn't do anything. So the situation was that one group defined them with colons and one group defined with dashes, and we had uppercase and lowercase. And that causes problems if you wanna use them as indexes somewhere or if you wanna compare them. And everybody agreed that there was a problem, but nobody agreed on the solution. And I know it's probably part of Yang-next. But listening to it again, last last meeting when I was attending, I thought, you know, is there something we could do now? And we we came up with you know, if we could just normalize the format and compare it. And it turns out that with a small extension that works in yang now, you can at least express it. It doesn't do anything, but it it it passes yang validation, and nobody has to change anything. It does it implies that the the values are treated the way we would like them to be treated. And with a small update, you know, that and in the future, hopefully, the the code would come along, and it would actually be able to validate it. You could validate it now, you know, with post processing, etcetera. But you would even maybe be able to detect it if somebody put in duplicate MAC addresses that had different format, you know, when you're validating the the schema. So this is what it looks like in the in the code, and that's all you'd have to add. And it's you know, this is what works for MAC addresses. I know there's other types of things that have this other other, you know, places that have this type of thing, but this is what's would work for MAC addresses. And so the proposal is that we we introduce something like this. If we wanna extend it to other types, we're open to that. And like I said, it eventually, it could work its way into Yang-next. Maybe this is a way to do some of the things that we take out of Yang-next and put them as a separate thing. So that's what it is.
[01:40:57] Michael Richardson: Questions? Michael Richardson. So you don't have a third format for us then. So sad. So I care about serialization to CBOR where we don't want the colons or the dashes or the hex digits. We just want bytes. Right. So I I don't know if this is enough clue that to go to be able to do that. But any signal's good. But I just don't know if this is enough signal from a yang ecosystem space Right. Thing. Of course, you know, we wanna do the same thing with v four and v six addresses and stuff like this, and we don't yet have a clear solution that I know of. But this sounds great. Michael Richardson, just
[01:41:47] Lou Berger: a clarification question. Not being a CBOR expert, why isn't that just an encoding issue?
[01:41:53] Michael Richardson: It's just an encoding issue. So why do we care about it? Because I need to recognize it's a MAC address and not a string. Okay. Right? That's all. The the the fact that it's cluefully normalized, I think that's enough signal. I don't know if it's an I I I don't know if there's enough signal at the right place and the right thing from a programming point of view.
[01:42:16] Lou Berger: But Sure. Forward to
[01:42:19] Michael Richardson: it's enough signal. I mean, it looks like there's enough there to say, and when you serialize it, you should normalize it to bytes, not ASCII digits without I really was looking for a third serialized version. You know?
[01:42:37] Lou Berger: Next up.
[01:42:37] Kent Watsen: Contest contributor, Next in queue. I I don't know if this is the actual problem. It may be, but I thought the problem was more with the canonical format. So for instance, the the IEEE client would write IEEE MAC address and but yet because the canonical format is the IETF MAC address format, it would get back the IETF format.
[01:43:00] Don Fedyk: No. I I mean, we're in IEEE, we're fine with the format the way it is. It's just that that so the the the cross between the two definitions is there there's a lot of baggage on that trying to resolve that. But as far as, like, as far as dealing with it that way, it wasn't a problem. It was just you know, it's kind of this is kind of just encapsulates the larger problem that that, you know, we don't have we we don't have a way to take strings and get values out of them. Okay.
[01:43:36] Ladislav Lhotka: I very much appreciate the problem and the need to solve it. Some questions. What is the relation between the normalized and the canonical format? So, would you expect, I don't know, normalized format to get in the GET config?
[01:43:52] Don Fedyk: When we we we originally called it canonical form, and then we changed it to normalized because we thought we didn't we didn't wanna be that specific. And even even the go back to the the the underlying value. We were careful not to say that that was a value of bytes. It could be just a string value too. So we're we're we're just putting the ideas out right now, and it'd be up to the work to to clarify it more, really.
[01:44:25] Ladislav Lhotka: It needs to be clarified. So what what do you expect in a get config reply?
[01:44:30] Don Fedyk: What's what's here is sufficient for our needs, but, you know, for whatever the work group wants to be how how precise they want it to be, that's that would be to be decided.
[01:44:42] Ladislav Lhotka: Next question that is the argument of this normalized is it the free string or are there rules how
[01:44:50] Don Fedyk: to normalize? Yeah. That's a point. I I did it as an identity, but the identity is just a string, and there's no there's no validation on that. But it would be nice that it it's something that, again, could be checked when you're when you're validating it that it is you know, you didn't put MAC 49 in, and it it works too.
[01:45:10] Ladislav Lhotka: Okay. Thank you.
[01:45:15] Rob Wilton: Robertson. So, originally, I was going to say this is like a layer eight, nine, 10 problem and things like that. But I've been in that layer, and I think it's intractable. You can't solve it there. So so although I was initially skeptical and saying thinking, well, do we do we need to do this? The fact is, I think, actually, we do need to find a solution to this problem, especially if it applies to other cases. Whether it's exactly this, I'm not quite sure. But but something is I think we should try and find find an answer. Another one could be to identify the alternative type. So, like, if each of them had a reference back to the other type, say, look. This is the equivalent type. That might be another way of doing it. So worry about these extra new encodings that are being defined here. The last comment I had is I think this is not significant enough to do as an extension to yang. I would see this more as yang next, but I'd go for them as well.
[01:46:12] Lou Berger: Okay. Thank you. I think there's clear interest in this topic, but it also seems that it might be a little early to move to adoption. I think it would be really good to get more discussion on the list and get some of the feedback you've heard from the room and from others, get those issues clarified, get the document updated, and then I would expect we'd wanna move quickly on this. Although, it's been years, but it seems like it's it's time. Kent, do wanna add anything?
[01:46:41] Kent Watsen: No. That's fine. Okay. Other than I saw Joe in queue. Do you while I'm putting up the slides, do you wanna say whatever you were gonna say there?
[01:46:51] Joe Clarke: This this just Joe Clark, this just strikes me as display hints from MIBS. Couldn't you generalize that in yang next and have something that would signal any type of
[01:47:05] Lou Berger: so good list discussion topic. Thank you.
[01:47:10] Kent Watsen: Thanks.
[01:47:14] Vivek: So good morning, everybody. My name is Vivek. I'm from Innoalios and collaborating with Swisscom, and I work with my team on the young library feature comparison. So the objective of this project, you know that young evolves a lot through the years. And when you're kinda new to young and you want to add it in your project, the first thing to do is to understand how Yonge works. This is the easiest part. And the second part is to find the right implementation that fits your requirement, especially if you have an already existing architecture. And this part is a bit more complex, but what can help you decide is to know for which implementations, the implementation status for each features. So here we have a quick overview over the young feature evolutions through the years, starting ten years ago with the basic features such as schema loading, JSON validation, or any data. We have some new feature like young library, young push, young structure, and symbol data validation, and we still have work in progress. For example, we have some telemetry validation, notes vendor validation, or schema comparison. We have a bunch of libraries, and we decided to work for this project on Libyang, young tools, and young kit because they were active. And, also, there was not just wrappers around Libyang. And, Kent, thank you for your mail. We focus first on Libyang and Yong-two and Yong-kit, but we want to complete our comparison with other tools such as pyang, yangson, etcetera. So here are some lead details for the version. And quick information, I am currently discussing with the YangKit authors in the mailing list, so I have some update for some implementation status feature. Each library is different. And for example, even if they are written in the same language, for example, young kit and young tools, they can have different type of implementation. If you took young tools, for example, this is like Lego stuff, and you have to build brick by brick what you want to achieve. And, for example, in comparison, young kit is more straightforward. So for each library, we wrote the corresponding code to represent the features, and we tested against valid and invalid input to be sure that it supports the feature correctly. And after the test, we marked the feature as supported, partially supported, not supported, or not applicable. This is all the feature we test, and I will go in detail for the non obvious one. Starting with the basic, Schema loading module inspection is the base level, so it is supported by these three libraries. If we look at JSON data validation, we mark it as partially support for young tools because we cannot reproduce the mass test we have for the other lab. This is what is partially support. If we go to see board data validation, it is now supported by Libyang as they closed the pull request two weeks ago. For YangKit, it was already supported. And for YongTools, they do not support CBOR data validation. For the any data part, what we did is that we have, like, three scenarios. The first one is you put primitive values like a string or a number, and you expect to have an error at this time. The second scenario is you put an object without the schema. You expect an error because you don't know which schema to use to do the validation. And the last one is you put an object with the corresponding schema, and you expect the library to use the schema to do the validation. Libyan must support all of this scenario. For young kid, if you put the primitive value, you don't have any error, and we expect to have one. And for young tools, the problem is when you put an object, even with the corresponding schema, they do not do any validation. So you always have an error when you use the any data in young tools. So for this structure, this structure is supported in Libyan and also in young kit. Note that we have the same problem for any data in structure on young kit, and YANG Tools does not support structure. This is why we cannot apply the any data in structure and structure inside any data. For the XPath, so we have two use cases. The first use case is you apply an XPath on the schema node of on the schema tree to get the corresponding node or the data. And the second scenario is you'd want to do subtree validation. You have an original schema. You apply an XPath on it. You get a subtree, and you want to validate your data against this subtree without the constraint of the original schema. So for the XPath data extraction, Libyang is supported. YangKit is partially supported. For example, if you want to retrieve a container using YangKit, you cannot do it. You have some other functions that let you do this. And for young tools, they have not a real XPath implementation. You have to go through a specific function. For this structure validation, it is supported by these three libraries using a native function for each of them. For the young to young transformation, we have three use cases. The first one is you want to add a new schema node to your schema tree. The second one, you already have the schema the node the schema node, sorry, and you want to add a new data node. And the last one is you already have a data node and you want to update this value. So you can do this in Libyan. For YangKit, the add new schema node is supported after discussion with the others. I tested a few days ago, so it is supported. And the update existing data node is not supported, but this seems to be an implementation choice. So maybe we need to check what we want to do with young to young transformation. Do we want to support this or not? Because we have two libraries that are not doing the same way for this. And for young tools, you cannot add new schema node, but you can add missing data node or update existing data node. For the Yang library, it is supporting by all the three libraries. For the Yang push telemetry and notification envelope, is just a mix of any data and structure. So it is supported by Libyang and Yankit. Yank2 doesn't support structure, so we cannot apply this test. And the last one, have the schema comparison. So it is supported in Libyang. You can test it. And for YangKit and YANG Tools, it is implementable using the native function. Here, you have a quick summary of all the feature that was tested and the result. And thank you for your attention, and let me know if you have any question.
[01:54:34] Kent Watsen: Amazing.
[01:54:36] Lou Berger: Thank you. It was great information. Really appreciate it. Are you coming to the queue? No. Thank you. I think it's great information for the group and for the community. And with that, we're going to move to the last
[01:54:57] Marek Laco: presentation. You.
[01:54:59] Ignas Bagdonas: So I don't have much time, so I'll try to rush it up or maybe not.
[01:55:04] Lou Berger: You actually have an extra minute.
[01:55:05] Ignas Bagdonas: I have an extra minute. Fantastic. So this is the presentation of the Yank coverage. This document was presented also in Montreal last year. Was going to go into the now this is on-list, but now that it moved to on-site, the chart didn't really fit this tooling, so we are going to propose it here. Right? We're starting with zero zero now. The basic idea of this is to, at the end, provide tooling so that you can get the coverage of a model after you have some set of valid examples. It's for authors, young young young model authors, for reviewers, etcetera. You have a set of examples, valid, of course. And at the end, you will get what we call the coverage, which is basically what parts of the model you have not covered by your examples. For that, we propose something called the uncover tree, which is basically just the entry of the model, but just the leaves that have not been covered. Just let me go quickly here. The problem here is that to be able to I mean, at the end, this is a tool. To be able for the the tool to run well, we need to identify which examples are actually valid from the documents. And I think there's a gap there, and we have excellent feedback. But the feedback kind of went all over the place, so we need to start, like, shepherding the the what to actually propose. So right now, the proposal on the document is to keep going with the code begins, code ends. But let's say we can have some kind of a prefix to to set or to define or to signal, hey. This is a valid example. And so that the rest of the tooling, not only for coverage, but maybe something else, can use it. There's this Internet track with Jan modules template in GitHub. It has been proposed, I don't know if officially, by the by the by the area. I I'm not sure. We are trying to align with that, so we we use the examples valid prefix for that. When you use this template in GitHub, you have to put examples in that folder, so we're trying to align it there. We have a few proposals here. Even though examples are bulky, they could also be part of the document. So we propose that whenever examples are in the document, they can be extractable in unclear way in a clear way. There's also the example begins. Example lens proposal has been there, but, of course, I don't know how hard is that to standardize. So the code begins code ends seems like a low hanging fruit. There must be auxiliary so there could be metadata that we need. I mean, when you I mean, and you guys probably have also experience on defining models, and so you sometimes need to do a auxiliary model and stuff like that. I still don't know how to we can do that, but we have proposals for that too. Of course, we will come to a point in which not all the data for the models will be in the document. There has to be something outside. There's the the bureaucracy and the practical part. In the practical part, everybody's using GitHub. Right now, this Internet module template that I define, I don't know how many people are using it, but it's a concrete proposal. In that sense, we try to align with that. But let's see what I don't know the source of a loss here. I think I don't know how that will work out in the future, but we'll try to get along. Now regarding coverage itself, we had very good feedback. Richard made very good feedback, Joe, I don't know, a group of Rob, about also trying to cover types and onions, these sort of things. However, we're trying to leverage the Yantry heavily for this. And if we want to show coverage of that, we will might need to extend the Yantry to also show it like in in the tree. I mean, if there's an union, don't just don't say union, but show all the possible types so that you can mark not show them when you have covered in your examples.
[01:59:12] Rob Wilton: So we have it as
[01:59:13] Ignas Bagdonas: a as a future work. We can keep keep going on that. There's a POC of this. It's working. It's based now in yangson. I'm sorry, believe, Jan, it's too complicated. So the good point is that Jan Sun already has some coverage some some some coverage stuff. I mean, some coverage code. We are not using the output from Jan Sun. We are modifying it as a library, but it's good. It's it's not super big. It it was bycoded, to be honest, but it's not super big and you can actually follow it. More information in the draft. I I don't have time to propose it. Yep. I think I'm in the edge. So I was very aggressive with the adoption. Maybe we need more time, but I don't know.
[02:00:09] Mahesh Jethanandani: Mahesh speaking as a contributor, I very much support this work. I think not just area wide, but even ITF wide if we could get all the tooling and the templates in place. You're correct to point out that I think a lot of the work anyway gets done in GitHub. So this ideally should be part of the CICD of in GitHub itself for how to validate. Now I have some tooling examples, but they were mostly on what I believe was what is covered, not what is not covered. So I think I like the idea that you're trying to break forth the enforcement on the not covered portion of the model. So I would really like to see the work. Thank you.
[02:01:00] Lou Berger: Rob, actually, you go. I'll go after.
[02:01:02] Rob Wilton: Okay. I mean, I think I've given you the same comments on the list and things. I think that getting coverage data for yang is good. Think so the base of what you're doing, I think that's a great thing to do. I think integrating into tooling, that's a great thing to do. The one thing I'm concerned about is not forcing all examples, like, yang models of the examples that have to be all complete, in the documents, but I think that's a separate minor thing. I think I think I support the adoption of this work as in I think it's a good basis to to then sort of progress and go forward.
[02:01:32] Kent Watsen: Kenton queue. I've heard this before where we could have some examples in the document, but then in the package that you upload, there's many more examples, and those are the examples that are used for coverage.
[02:01:45] Rob Wilton: Yeah. Something like that. Yep.
[02:01:48] Lou Berger: One of the questions I have is whether or not we should run the change in guidelines, the establishment of maybe example code begin and end. Should we run that separately from the rest of the document? Because that is an update to our guidelines. Because our guidelines right now say don't market. So we would need to address that point, and that seems like a little bit of a separate discussion and very well contained and something we might wanna do quick more quickly than the rest of the discussion.
[02:02:18] Ignas Bagdonas: I agree with that.
[02:02:19] Kent Watsen: So as chair, I have a question about if this is the right working group for the document. Is it in the netmod charter?
[02:02:28] Lou Berger: So the the change would be in guidelines. The rest of it, I'm not sure. And I think that's part of the reason why it might be worth separating those pieces. That's something we can take up with
[02:02:39] Kent Watsen: the
[02:02:39] Lou Berger: AD. With that, we are actually a little bit over time. Thank you all for an excellent session. Stay tuned for a possible interim well, on possible interim, and we the and we will see you in San Francisco.