Session Date/Time: 16 Mar 2026 01:00
Kent Watsen: Okay, it's now 9:00 AM. We can start the meeting, I suppose. Welcome, everybody. Monday morning, first session. I don't know about you, but I'm very sleepy. Um, thank you, Thomas, for the coffee. It will hopefully get me through the meeting. If I fall asleep halfway through, you know what to do, right? Okay. Um, yes, so this is the NETCONF session. If you're not expecting to be in a NETCONF meeting, you might want to go to a different room. I'm Kent Watsen. My co-chair, Per Andersson, is on the line. And I think our secretary—actually, I don't think our secretary's joined yet, but Mithun is normally on the line. Oh, there he is. Okay.
As always, there's a Note Well. And normally I go very fast on the Note Well slide, but because it's the very first session Monday morning, I probably should spend a little time to say that it's incumbent upon everybody to be aware of the fact that anything you share with the idea of, you know, you come to the microphone, is considered to be you contributing to the IETF. Um, there's more details in it, so please look at it. There's a QR code if you're concerned about the details. Um, look at that carefully before contributing anything to the microphone.
For folks that are in person, please be sure to sign in, DataTracker. There's a QR code on the screen and a microphone. Um, use that to join the queue. Like, if you want to join, like at the end of every presentation there's an opportunity for discussion. Um, use the show of hands—raise your hand to join the queue before you come to the microphone, and that way it's clear who it is that's making comments to the microphone. And of course, when you leave the queue, try to remove yourself from the microphone, like, remove yourself in the app. Of course, the chairs can remove you, but it's a little bit of extra work, so it's best if you can do it yourself. Um, same for remote participants, but also be extra careful of external audio noises in the background. Um, just be careful of, you know, polluting our environment here at the IETF.
There's many resources that can be accessed during the meeting. Of course, there's Meetecho. Um, we will use a timing clock. So, you know, most presentations are well-constrained in how much time they have, but for some, we might put up a timing clock. It's a countdown timer that will show up at the bottom of the screen, and it might, you know, turn red if you're in the last one minute of your presentation. So just be mindful of trying to stay in your time constraint. Oh, there is a notes page. And Per, I don't know if you've done it already?
Per Andersson: I've done it.
Kent Watsen: You have? Okay, perfect. Um, yes, already to the chat window, the URL for the notes page has been posted. So please everybody, join the notes page and primarily make sure your own comments are being captured correctly. But if you are able to, also capture the comments from others. Um, it's very helpful to the chairs for that to be done.
Uh, okay, encouraging participation. So this is kind of, you know, just out there, but you know, everybody is a volunteer when we come to the IETF. But the IETF only happens, it only is successful because of the volunteers standing up and doing more. Um, so, you know, first and foremost, we encourage participation on the mailing list. Um, of course, during presentations, we hope that you'll provide comments, even if the comment is as simple as "I support the draft" or "I approve of this idea." Um, as little as that is meaningful. Um, there are many drafts that are moving through the IETF, through the working group, and if you can provide reviews to those drafts, it's very helpful. Of course, if you're the author of a draft, that's amazing. And then there's the draft shepherd. So at the end of the process, after the draft has gone through the working group, but before it goes to the IESG, um, we need to have a shepherd write-up, and we always ask if anyone would be willing to be the shepherd to do the write-up for the draft.
So there's many opportunities to be participating in the IETF. Um, so active authors are encouraged to participate in the review of other working group documents in order to increase working group activity participation, reciprocate effort shown by others, and to illustrate broad understanding, interest, and thought leadership. So truly, it is the case that your participation is being acknowledged, right? I mean, um, if you just sit in your chair, you're kind of anonymous. But if you stand up and say something, you become recognized and you're an active participant. It's important. It's good. Be aware that the chairs are human beings and may forget or miss deadlines. This happens all the time. Like, we receive so many emails and things get lost sometimes, so be kind and just remind us, like, if we forgot to respond to you at any time.
Okay, so status of post-working group documents. Um, this is great. We have accomplished many things in the last, you know, four months. Um, first and foremost, the port numbers draft, RFC 9900. That's a very cool number, by the way. 9900 was published. So congrats on that. I think a round of applause? Yes. Yes, very good. Um, and there's many other drafts that are currently in the RFC editor queue. So next meeting, we will clap again for all of those. It's so good to see that we're actually publishing documents. That's what we're here to do. Um, more documents. So we have, not only in the RFC editor queue, but we have some that are in last call, expert review, IESG evaluation, AD evaluation, a couple that are in "waiting for working group chair go ahead." Um, and then others that have working group consensus and are waiting for write-up. So all these documents are basically out of the working group, so not expected to be discussed during this meeting, but they're also in queue, they're about to be published. And so very good, we're going to clap a lot at the next IETF meeting. For documents that are in this working group, we have the draft-ietf-netconf-privcand document and the list pagination—well, pretty much all these documents are being discussed here. You can see, um, the first, well, I guess five of them are being discussed here, and then two of them were being—their updates were posted to the mailing list before this meeting.
The agenda for this meeting is on screen. I'm not going to read it out for you. It was also posted to the mailing list, so hopefully everyone has had a chance to look at it. Um, I think it's two slides. Yep, two pages here, so here's the second page. There's some documents, I'll go to the previous page, some documents that are chartered. So these are documents that have already been adopted by the working group and considered to be working group documents, and so we give attention and time to them first. And then there's other documents that are currently not chartered, but hopefully they'll be adopted by the working group shortly, and um, they come after. And I think there's a little bit of time at the end for an open mic session. So if anything closer? Am I too? Thank you. So if there's any desire to talk about anything that's not been discussed before, that's your opportunity to raise the issue during the open mic session. And I think that concludes the chair slides. So I will go to the first presentation. As soon as I figure out how to do this. Okay, quick. Perfect.
Try the on-off slider. I had to turn it on.
Qin Wu: Okay, great. Morning everyone. My name is Qin Wu. So I will present the update of the list pagination. So this draft has been around for a while, and finally we actually make progress.
Okay, we have three relevant drafts. First is draft-ietf-netconf-list-pagination base draft, and so we clean remaining review comments from OpsDir review and YANG Doctor review. And you can see a list of changes we made. First, we added a note on potential resource impact from larger and complex queries. So this comment's from OpsDir review, and so we made some clarification on the text in the base list pagination draft. Second is about the protocol mapping, also raised in the OpsDir review. Um, but we think this is more relevant to the NETCONF list pagination and the RESTCONF list pagination. So we add some base text, you know, to clarify protocol mapping has already been documented in two relevant protocol list pagination drafts. The third change actually relates to the offset and cursor. So this, in early comments, they think we need to clarify how offset and cursor, these two parameters, can be used together. We think, we believe actually, this should be excluded to be used together, actually. So we made a statement and also further, we moved out of the conformance bullet and make it more clear, because this is not a conformance issue. And the last change, we use list pagination error for logging and debugging paginated queries. For all other changes, just editorial changes. We also believe um, all the review comments from OpsDir review and YANG Doctor have been addressed.
The second is draft-ietf-netconf-list-pagination-nc. I think we don't make, you know, too many changes. Actually, we added the revision number of the YANG data model, and we believe all other comments have been addressed. And also for, you know, further technical changes, actually no technical changes have been agreed by, you know, list pagination design team members. So that's the current status of the NETCONF list pagination draft.
RESTCONF, and we also believe similar to the NETCONF list pagination, all comments have been resolved. And this the current version has been agreed by our, you know, NETCONF list pagination design team members. And for the next step, we request publication. Um, yeah. Thank you.
Kent Watsen: All right. Thank you, Qin, for the update. Um, of course, I think the publication will go through and so it's going to be on Mahesh's desk shortly. And, you know, not specific to this one document, but in general, I like the way these documents are structured. That there's the one document that's the list pagination document, the general, you know, describes the general list pagination mechanism, and then there's a NETCONF specific document that's for how to map it to NETCONF, and then a RESTCONF specific document for how to map it to RESTCONF. Um, in general, I think this is a good way to go. We'll probably talk about it later in this meeting, again, not specific to this document. Does anyone have comments about this document? There is a comment from the chat. I can read it.
Per Andersson: Yeah, please go ahead. If you can read it out.
Per Andersson: Yeah, so Rashad had a comment that he hasn't taken a look at the documents since Montreal, but he wonders if there's any implementation status to share.
Qin Wu: Oh, implementations. I think the document itself talks about some? We do have implementations. In the early presentations, we listed a set of the implementations, you know. I think, yeah, we can post to the list for the implementation we have.
Kent Watsen: Right, right. I, yeah, the documents themselves, I think, have an implementation section. As co-author of one of the documents, I can say that I have implemented them partially, right? So there's, uh, you know, there's different, I think there's limit and order-by and so I've implemented some of the query parameters, but not all of them.
Mahesh Jethanandani: So you mentioned publication request. Is there an update to the draft that is to be posted? For the main draft? I believe you said no changes for the NETCONF and the RESTCONF draft, but what about the main draft? Is there an update coming for that? Or is it done-done?
Qin Wu: I think just before this meeting we posted all the updates, and also confirmed from the author, from the reviewer in the OpsDir review and YANG Doctor, and everything has been resolved as, yeah.
Mahesh Jethanandani: All right. So that means it's truly ready to go out.
Qin Wu: Yes.
Kent Watsen: After this meeting we'll probably send it to your desk.
Mahesh Jethanandani: Okay. Sounds good.
Per Andersson: I can share, if Mahesh was done in the queue, I can share, Per Andersson co-author of these drafts, that I have implemented most of it previously, and I know that Olaf Hagsand has implemented most of it as well for implementation status. Thank you.
Kent Watsen: All right. The next presentation is draft-ietf-netconf-over-quic. David Dai is presenting. And here comes David. Thank you. Oh, let me give you slide clicker.
David Dai: Good morning, colleagues. Glad to see you again, especially in China. Now I'd like to give the brief introduction for NETCONF over QUIC. Since the IETF 120 meeting, the Montreal meeting, we have generated two versions. The first version is 04. In this version, we did two changes. One is we replaced the original port number for NETCONF over QUIC with the port 443. And the reason was that in the last meeting, most people think using port 443 is more flexible. The other change is that we have reorganized the security considerations section following the comments given by Rob in the last meeting.
The last week we submitted the 05 version. In this version, we added some words for the section concerning the authentication. We clarified the certificate authentication in some common use cases. For example, for the machine-to-machine, the server may maintain a client database and maintain each identity for the device. If the server is given the username, then it will verify the user with the given username. For the end-user with end-user logins, the authentication may be more complicated. But in our case, for NETCONF over QUIC, we can rely on the original NETCONF over TLS authentication method. And for the next step, I think we have fully discussed all the open issues so the draft should be ready for the working group last call. Okay, that's all. Any questions?
Kent Watsen: Any questions? Oh, wait. I can say, I'm the co-author of this draft too. Um, as an implementer, I'll say that um, the initial thought of having a unique port for NETCONF over QUIC seemed correct, because it would look like NETCONF over SSH or NETCONF over TLS, you know, unique ports for each transport. But in the discussion, it was raised that QUIC is often, well, always, encrypted, and if it's running over UDP port 443, it's easily confused with HTTP/3. And so, um, using port 443 seemed reasonable, except for how you might distinguish between them. And this draft uses ALPN, so it identifies as NETCONF over QUIC, and that seems very reasonable. And the same thing happened, I think, for RESTCONF over QUIC. I'm not a co-author of that, but it's another draft that I think we have. Any comments? Okay. Thank you very much.
Okay, next. Oh, actually, next presentation is um, draft-ietf-netconf-quic-client-server, which was on David's slide. So, Per is presenting this?
Per Andersson: Yes. Can you still hear me?
Kent Watsen: Yes, can hear you. Okay, so let me load your slides then. The QUIC client-server slides.
Per Andersson: Yes. No, the QUIC client server.
Kent Watsen: Uh, yes, yes, yes. Thank you. Yes, and I'll pass slide control to you. You should have it now. Go ahead.
Per Andersson: Thanks. I don't dare to start the video. I'll just run it as is. My name is Per Andersson, and I'm going to present the YANG groupings for QUIC client and QUIC servers. Let's go.
So what are we doing? We're defining reusable YANG groupings for the QUIC protocol. We're reusing the TLS client-server and the UDP client-server documents and YANG modules for this. And adding IANA YANG modules for the QUIC versions and QUIC transport parameters. And this work is used by the NETCONF over QUIC YANG module.
The update since last IETF is that we have clarified handling of QUIC transport parameters updates. And then editorial fixes: updated copyright year, revision date for initial IANA YANG modules, and editorial fixes.
So this is the verbatim from the document regarding the IANA considerations for the QUIC transport parameters registry. The issue is, as was raised at the last meeting, that the provisionally registered names can change value when they are made permanent. So how would that be handled? And in short, it's handled as normal with the YANG SemVer work. So you would roll a new major version of the YANG module when you update the enum values in a non-backwards compatible way. And IANA is okay with this, with these considerations.
And that is it this time around. All issues that have been raised have been discussed, addressed, and cleared. So in my view, we can go for working group last call. Opening up for questions.
Kent Watsen: I'm a little bit surprised that it's already ready for working group last call. It seems like it was just recently adopted. It's good. I mean, of course, it's not adding too much, so maybe it makes sense. Does anyone have any comments or questions, concerns about this document?
Qin Wu: Yeah, this is Qin Wu again. Can you go back to slide 4, page 4, about the change? Yeah, QUIC transport parameters. I review this part, you you define a YANG model, you know, use enum. But if you, you know, change enum into identity, whether this issue will go away? Because for for this, you know, QUIC version issue, maybe they already can be see as capability negotiation between the QUIC client and QUIC server. They already can be aware of this, you know, version issue or... do you do you know what I mean?
Per Andersson: Yeah, yeah, I understand. It was discussed in Madrid to use identities or enums, and the working group decided on that we should use enums, as is done for most other IANA YANG modules for registry parameters. I think.
Qin Wu: Okay. Yeah, I just try to understand why management system need to care about this issue. Yeah.
Per Andersson: Uh, yeah, um, I don't know if they need to. They update the YANG module and continue as, as they would. The value is not um, it's only in the description, so the underlying system would have to update it anyway manually.
Qin Wu: Okay, maybe provide some example will help. Yeah, thank you.
Per Andersson: Okay, thank you, Qin.
Kent Watsen: Any other comments for this draft? Okay. Thank you very much.
Per Andersson: I can share—if Mahesh was done in the queue, I can share, Per Andersson co-author of these drafts, that I have implemented most of it previously, and I know that Olaf Hagsand has implemented most of it as well for implementation status. Thank you.
Kent Watsen: All right, so the next presentation is draft-ietf-netconf-https-notif-cbor. Barajwa is presenting. Great, I'm going to pass slide control to you. Go ahead.
Barajwa: Hi everyone. So we're presenting the CBOR encoding for HTTPS-based transport for YANG notifications. And so basically this is an extension to the HTTPS-Notif draft, which is a document proposing a protocol for sending asynchronous YANG notifications over HTTPS, very similar to the idea of sending notifications in RFC 5277. And we started working on an implementation based on the guidelines laid out in the document where we had a publisher and a receiver. And the idea was that the receiver didn't need to be a NETCONF or RESTCONF server necessarily, but it would have two HTTPS endpoints: /capabilities and /relay-notifications. So the publisher would initiate the conversation by using—sending an HTTPS GET request to the receiver's /capabilities endpoint along with suggesting what capabilities it does process. And the receiver would reply with the 200 OK message and complying with the possible receiver-encoded capabilities. JSON and XML were supported in the initial draft, and while we were implementing it, we'd experimented with the other encodings and thought CBOR encoding was also a good idea.
Well, this was the high-level implementation architecture, which borrows upon the YANG Push ideology, where the entire system is like a Kafka publisher. And once the receiver receives the notification, it puts it into a specific Kafka topic, which is then consumed by a Kafka consumer, which is like a time-series database. We use InfluxDB in our implementation. But as we were doing our implementation, we sort of tested out different encodings, and we'd also realized that CBOR is pretty efficient, especially in bandwidth-constrained networks where we get pretty good throughput for CBOR, right? And we'd proposed this document in the last two IETFs, and it has got adopted in the last IETF. And the update since the last one were: we fixed a few references from IANA, and the draft has been updated to the working group status.
And we'd ask for a few reviews in the mailing list. One of the most trivial questions we had was that with the CBOR encoding, we have actually two different ways of encoding the data: one using named identifiers and one using SIDs, which is schema identifiers. And according to the RFC 9254, we have an optional parameter in the application media type where we can specify which encoding we want to use. And this allows us to sort of figure out which encoding we want to use while communicating it. But the initial draft, we use the HTTP application status of like application/xml or application/json. So if we follow similar guidelines, if we use application/cbor, we won't have the optional ID parameter that we can use, which means we would have to communicate whether we want to use the SIDs encoding or the named identifier encoding in a different way, which we still can do technically, by having a separate receiver capability. Because in the receiver capability, we can just have it as like a standard tag where we right now have encoding-json, encoding-xml, we can have two different encoding-cbor or encoding-cbor-in-sids. We wanted to find out which is the most standard way of progressing ahead, because the second one would introduce a dependency and changing the initial draft, but it seemed more standard-way because it relies on RFC 9254. We'd already asked for reviews in the mailing list, so it would be nice if people have suggestions here or we get it on the mailing list.
We were also working on adding CBOR support to the libyang library. We've made progress and submitted a PR where we wanted to introduce the standard CBOR handling support for libyang. We're receiving reviews on the PR for that as well. Um, yeah, that's about it for us. Any questions?
Kent Watsen: Okay, thank you. First I want to congratulate you on the most clear remote microphone audio. Very, very clear, I could hear every word. Thank you. And everyone else take note, your microphone, your audio quality matters. It's very difficult sometimes to hear remote participants. Um, please go back to slide number 9. I think we have comments from the room. Alex, you're first in queue. Uh, sorry, slide 8. Yeah, thank you.
Alex: So I read your feedback on the mailing list and I already got a response to that, so I will send it out when I have it written. But here I agree with you that I think we should use application/yang-data+cbor as actually the data that is encoded from the node, it's YANG encoded data rather than pure CBOR, pure XML, and pure JSON data. So I do think we should use yang-data+ the encoding. I am aware that the HTTPS Notif draft is out of the working group, so I'm not sure which would be the better way to change those encodings, either by just quickly changing those media types on the HTTPS Notif, or just using this draft to update the HTTPS Notif. So I don't know which process would be better here, up to the working group. But yeah, my opinion here is that since this data is actually YANG encoded data, we should actually use the media type for YANG data.
Kent Watsen: So as a contributor, I'll say that I think best would be to update the document while it's before it's been published. As a co-author, I can say that I think it's a good idea for the co-authors to push for that. My other co-author is also AD sitting in the room laughing. So actually Med is going to be the acting officiator of this document. But Mahesh, do you have any comments?
Mahesh Jethanandani: No, I didn't want to jump the queue if... So I agree. The draft is of course past working group. It's sitting actually past IESG review at this point. But if it's... I'm okay to ask Med to pull it back and make the change if need be.
Kent Watsen: Okay, so I think the thing to do is to bring it back to the working group and just ask the working group if there's any objections to the change, and then we'll make the change. Benoit, you're next in queue.
Benoit: Thank you. So thank you for this work. So can I see that you had like a hackathon this weekend? Can you share a bit more about what you did during the hackathon for the libyang implementation?
Barajwa: Right, of course. Um, okay, so what we've done is we've added sort of CBOR support to libyang, as in libyang follows a standard part where we sort of parse—I mean, it supports XML and JSON currently. And it has different APIs to read the data, and it mainly supports like parsing and validating the YANG formats and parsing the XML and JSON input formats, manipulating the data into a data tree, and then mapping it with the YANG format and seeing if it's right, and then also like a printer for the output. So we've decided to add CBOR support for the same. But instead of writing like a complete CBOR parser from scratch, we decided to use libcbor as like the fundamental CBOR parser, and what we had developed was like a mapping between the YANG data tree and the input CBOR data. You can find the work on the pull request number 2130, sorry, 2499. Uh, yeah. We weren't able to present the slides for the hackathon, but we'll update the notification or I can share the PR in the chat. We've received some comments regarding the coding style and a few improvements to make. We've updated those as well. So right now, you would be able to use libyang and just give it any sort of data, and any sort of CBOR data, and it should be able to parse it and check if the CBOR data conforms to a particular YANG model that we've written for it. And yeah, it would also be able to inter-like you could give it JSON data and print it out in XML if you want to debug. That should be working for now, but we'd only implemented CBOR named identifiers for now, because we weren't fully sure on what architecture we should use for CBOR schema identifiers, as we'd have to have a database storing all the mappings from like the schema identifier to the actual named identifier somewhere. But that's something that we plan to do in the future. Um, yeah.
Kent Watsen: Okay, thank you. You also get the award for the longest response to a question. Um, one last comment, Thomas, you have a question.
Thomas: Right, just really quick one. Hey, thanks a lot Barajwa. I wanted to ask actually the same question as Benoit, so great job. Looking forward for testing in the next IETF hackathon. Thanks.
Barajwa: Oh, thank you. Right.
Kent Watsen: Okay, great. Good progress. Happy to see this document moving forward. Moving on to the next presentation. So we already did Yang Push. The next one would be transaction ID mechanism. I think Per is presenting this one.
Per Andersson: Yes. Can you still hear me?
Kent Watsen: Yes, can hear you.
Per Andersson: Great. I have slide control. So I'm going to present draft-ietf-netconf-transaction-id for RESTCONF on behalf of the authors, Jan Lindblad and myself.
The background is that Jan wrote a draft for a transaction ID mechanism for NETCONF. It defines a somewhat rudimentary solution for RESTCONF, and this document defines a solution in parity with the NETCONF transaction ID mechanism.
So the solution adds the possibilities to supply the transaction ID as a payload attribute, which is in parity with the NETCONF transaction ID mechanism. It furthermore adds or extends the possibility to have a default transaction ID as an HTTP ETag header, and you can use the HTTP Last-Modified header for conditional requests. This is somewhat defined in Transaction ID for NETCONF, but further refined in this draft. As well as the conditional application of requests with HTTP If-Match header.
So this is what the transaction ID looks with when it is supplied as a payload attribute. You can see the highlighted tx-id-etag in the payload there. So this is an addition in this draft. This is how it works in the NETCONF variant of transaction ID as well. I've shown an example with XML here, but of course since this is RESTCONF, this can also be done in JSON, it's included in the draft.
Using the HTTP headers. So this solution defined in the NETCONF transaction ID is that the ETag is the only way to supply a transaction ID for RESTCONF. So there's no granularity as for the corresponding NETCONF solution. This document instead adds or extends uses the ETag transaction ID value as a default value if the nodes doesn't have an explicit transaction ID attribute set. And together with the If-Match HTTP header, you can then reject an entire request if the transaction ID values in the header or attribute don't match the nodes.
And the next steps. This was raised by Kent, that there should be a parity between the NETCONF and RESTCONF protocols for the transaction ID mechanism. This shows that it is possible to do. This is a proposed solution for that work. If the working group wants to work on this, then let's adopt this work and define a solution. And then the normal route: gather working group feedback and define the solution, etc. Time for questions or suggestions.
Kent Watsen: Yeah, thank you, Per. Um, do you have one more slide?
Per Andersson: No, it's only this slide.
Kent Watsen: Okay, great. Um, so as a contributor, uh, can you go back to the previous slide? I think slide number 5. Yes. Uh, so help me understand the last bullet point, "reject entire request." Is this—are you saying that—so this document, the transaction ID document, proposes a very granular mechanism. Um, but here it's saying that the entire request is being rejected based on the HTTP header. Is it granular or is it not granular?
Per Andersson: Currently, this is what is in the document, but it can be further refined, of course. So currently as it stands in the document, it rejects the entire request. But that, as you point out, that should probably be changed to match the NETCONF transaction ID mechanism to be granular, of course. That's the intention at least.
Kent Watsen: Right. Um, again, as a contributor, I mean, one approach to the transaction ID draft would have been to copy-paste the HTTP header solution, which is the coarse header-based transaction ID. But it chose to do a more granular idea, which is good. Um, but if we don't replicate that granular idea into the RESTCONF, then I don't think that's necessarily achieving the parity that we spoke of and had the poll on last IETF meeting. Um, so yeah, I think it should be granular.
Per Andersson: Yeah, good point.
Kent Watsen: Any other comments on this document? Okay. As a contributor, one more time. Um, I see this document, and this isn't a comment specific to this document, but for all documents that, you know, based on the desire to have parity between RESTCONF and NETCONF. Um, you know, I think there's probably two good ways of doing that. One is to have a single document that defines the generic solution and then subsections for how to map it to NETCONF and how to map it to RESTCONF. Uh, I guess we should talk about CORECONF, but uh, CORECONF is not actually maintained by this working group, so we don't have to. Um, so that's one approach, a single document. A second approach is three documents, where there's a single document is defining the generic solution and then a second document for mapping to NETCONF and a third document for mapping to RESTCONF. So it's either one or three documents. Uh, here we see two documents. So the NETCONF specific document is defining a generic solution and the NETCONF mapping, and then this document that's being discussed right now, presented right now, is just simply the RESTCONF mapping. Um, it's kind of confusing to do it that way, I think. Uh, I worry about long-term maintenance, um, you know, if, if... anyway, either one or three documents seems to be the right way of proceeding. I see Mahesh as AD nodding his head. And um, yeah. Oh, and I see a comment on the list from Lou Berger, who's my co-chair at NETMOD. Um, he appears to like the three-document approach, per protocol mapping documents, which I think is ideal actually, because then it maps, it allows for other mappings like CORECONF, I mentioned, not maintained by this working group, but another working group could easily create a CORECONF. Um, oh, and I see Rashad plus-oneing Lou's comment. So I think that's a good idea. Um, anyway, I'll step away from the microphone, my contributor microphone, and go back to the chair microphone. Are there any more comments on this?
Per Andersson: I can respond, maybe. So as a contributor, I agree. It's very clear to have it split out into one base functionality document and then protocol-specific documents. It's clear to follow, clear to implement, clear to reference when you need it. Uh, we didn't want to disturb the transaction ID document that was already pretty far in the process. So, would you suggest that or the people that support this, that it should be reworked and folded into that transaction ID document that has already been into working group last call, or to now split into three documents? That is probably substantial work.
Kent Watsen: So, again, I'll say as chair, either one or three documents would be ideal. As a contributor, I think three documents is better.
Per Andersson: Okay. We'll take that to the author group and discuss it.
Kent Watsen: Okay, thank you very much. I think that's it for this presentation. Back to next presentation. Uh, I think it's the NETCONF error list and error identities.
Per Andersson: Yes, exactly.
Kent Watsen: Yes, it's on screen. I'll pass the slide control back to you.
Per Andersson: Thank you. So, uh, it's me again, on behalf of the authors, myself and Mithun. I'm presenting the NETCONF error list and error identities registries draft.
So, um, the NETCONF errors and identities have no canonical source. We would like to create IANA registries for NETCONF errors and identities, which makes it possible to create IANA YANG modules of these registry contents.
The status quo is that there exists no canonical source as said, or registry for NETCONF errors. They are listed in RFC 4741 and RFC 6241. New errors and error identities are listed in the RFC where they are defined and introduced. So the NETCONF notification, subscribed notifications, YANG Push, etc., etc. The and as you've seen the work in this working group, recently, current work, the list pagination, trace context extension, YANG Push 2, etc. So it's a distributed set of documents if you want to have a complete list of errors or error identities. There's no easy way to get all the existing errors, often needs to be hardcoded, or at least need some parsing of several sources to get all the error identities. And the RFCs aren't machine-friendly to parse. And you could end up needing to import YANG data models just for error identities.
So solution is to create IANA registries then: a NETCONF error list registry and a NETCONF error identities registry, and create initial YANG modules for these above registries. Advantages would be then that there will be a canonical source for all NETCONF protocol errors and error identities, easy and well-defined way to define these, the YANG modules of of these registries, they're machine readable for implementations to have access to NETCONF errors and error identities, no need to import full protocol modules for just these error errors and identities list.
So the next steps would be to ask the working group if we should work on this, adopt the document and then gather feedback and define a solution, etc. That was it. Thank you.
Kent Watsen: Nobody's in the queue, but uh, oh, two people in the queue. Please.
Mahesh Jethanandani: Mahesh speaking as a contributor. I do think it's a good idea, and I do, I would support the work in the working group.
Per Andersson: Thank you. I can say also, before Alex, that last last IETF I discussed this shortly with Rob as well. So I'm hoping that he will join as a co-author as well. Yes, Alex.
Alex: Um, same here. I think this is interesting work. I have however some questions and maybe some suggestions. First thing is that you say some errors are defined in some YANG modules that are in an RFC, and these when you need to use them, you need to import that and therefore you need to implement the YANG module. That's logical, but however, if that error is in that YANG module, that means that it's specific to that document, right? So it would not make sense to just use the error without the implementation of of the whole or at least the protocol that is defining that, right? So I am a bit puzzled on that. Um, then another thing from the slides, slide 5, you want to create a registry in IANA and then create an initial YANG module with all the registries. I support that, however, when there is a new draft or new proposal, there would be new errors and we need a way to enforce that, okay, when we are creating new ones, we need to to tell these authors that they need also to register those identities to this IANA. And then second thing is that maybe a way to go as these YANG module need to be updated with new, as new registries are in the IANA, maybe it should be a IANA-maintained module, that I don't know if that would be the way to go. So that that are my comments.
Kent Watsen: I'm sorry, Alex, could you repeat the last... I didn't hear it quite right. Could you repeat it?
Alex: So if my understanding is correct, is there a way that there are some YANG modules that are maintained by IANA and not by the working group themselves? And so when a registry is updated, IANA themselves, they create the YANG module and register them into the IANA. And I think that would be the better approach so that not every time we have a new a new error, we need to re-update that YANG module and letting IANA maintain that. I see. Okay, got it.
Per Andersson: Yeah, for for that that's the idea here, that to have IANA maintain YANG modules for this. And there's a process for that as well. It's being discussed in Netmod and outside of Netmod as well in the corridors. So that is the idea. Thank you. And then the IANA YANG modules would be updated automatically when the IANA registries are updated.
Kent Watsen: Okay, Kent as contributor, I'm in queue. So I'm looking at this document and one thing that I think about is the NETCONF errors are also used by RESTCONF. RESTCONF, whenever there's an error, it's presenting the RPC error as defined in NETCONF.
Per Andersson: I have a backup slide for this.
Kent Watsen: Okay, go ahead and present your backup slide. Perfect. Go ahead.
Per Andersson: Yeah, so the the thought I had as well was if we should have an analogous registry for NETCONF error list for RESTCONF? Are the RESTCONF errors distributedly defined as the NETCONF errors, or could the RESTCONF protocol just reuse the YANG modules that are defined for NETCONF? That is the thoughts I have had.
Kent Watsen: Okay, perfect. I'm glad that you jumped, you foresaw the issue I was going to raise. Um, so these aren't truly NETCONF specific errors or RESTCONF specific, or I mean, they're just errors. And I mean, CORECONF would have the same errors. We shouldn't call them NETCONF errors, the IANA registry should not be a NETCONF specific error registry, it should just be protocol error registry. Um, so I mean, let's make it generic is basically my high point. Um, and then my low point is that I almost question if we as a working group are going too far in trying to define all these errors. Um, I mean the specific error codes. So as an implementer, I will tell you I I simply look to see whether or not there's any error. If there's any error, you know, versus you know what is the specific error? I I mean, it I I wonder if like others are feeling the same or like... are people actually switching, you know, do they have code logic that switches on the specific error code, or is it more like myself where if it's any error that's that's the end of the transaction? Um, I mean, so here we're trying to define a registry for errors, but my question is do we want error codes at all? I mean, like should we maybe back out of that whole solution approach as we think about NETCONF next and RESTCONF next? Here's an opportunity to just do away with it. Any comments from the room?
Mahesh Jethanandani: Mahesh again. I believe Rob has a couple of comments in the chat. My take is that, yes, there is probably going to be a common set of errors for both the protocols, but then there would be NETCONF-specific and RESTCONF-specific based on the transport maybe errors that it encounters. So I don't know, leaving aside the question of whether how you use them, if you're truly looking to register these errors, probably you need common and then one specifically for NETCONF and one for RESTCONF.
Kent Watsen: Okay, great. And I see there's an active chat window going on. Perfect. I love to see a lot of activity on the chat window, discussion, right? I mean, that's what we're here for: to discuss the items. Um, and I throw out, um, you know, contentious or, uh, you know, interesting items for discussion. So there's that. Per, you're next in queue. Or do you mean to be next in queue or should we...?
Per Andersson: Yes, yes, just to address your point there about if we should remove errors. Uh, I don't think so. I should I think we should have a much more granular... I mean, could have an error per line number when we're debugging, right? So the error identities and everything, the combinations you can have for NETCONF errors, they're very helpful to find stuff in implementation when at least I'm debugging and when my peers are are debugging. So.
Kent Watsen: Okay, and just responding to your comment, I'm kind of jumping back in queue, but does this suggest then that maybe there should be three IANA registries: one for common errors, one for RESTCONF specific errors, and one for NETCONF specific errors? I'm not really sure if we're talking about that as a potential solution. Um, anyway, I'll just throw it out there. James, you're next in queue.
James: Uh, yeah. So, James. Um, I also agree we should not do away with the errors, we should keep them. Um, we should make sure that they are specific to the protocol, not specific to the transport layer as well, I think that's we don't want to kind of muddy those waters really. Um, I think it's useful to have a set of them. I II question how frequently they really add and remove and change them, I think this would be a fairly static registry, at least I'd hope so. Um, and given it's a small number and fairly static, creating two additional, one for NETCONF, one for RESTCONF, or three additional for a joint one, might be a lot of administrative overhead for a very small number of errors.
Kent Watsen: Mm-hmm. Okay. And and just kind of peaking to the next presentation which I'm giving, which is the YANG Next impacts onto NETCONF, um, but basically YANG Next impact onto this working group. Um, one of the things that I noticed in RFC 7950 was that it did specify uh when specific error codes should be presented. And sometimes those error codes were not actually NETCONF specific, they were actually more um uh like uh you know logic oriented, like um you know a validation error, right? A validation error isn't NETCONF specific or RESTCONF specific, it's just a validation error. Um, and and uh so so there is indeed uh in the YANG Next effort, the desire to define some error codes that are generic uh to any protocol mapping, and then and then I would think that the NETCONF document would go into the details about how to do it, the RESTCONF document would go into details about how to do it. In fact, it already does, 8040 does. Um, so I think uh that's my response to—does that make sense to you?
Per Andersson: Oh, yes. And uh, we were talking about the YANG Next document, right? I was going to ask you in the NetMod meeting, but anyway, I'm just going to go ahead and ask you right away. So we are talking about YANG Next, we are talking about YANG 2.0, and there is also something called YANG++, which has the C++ elements to it. So I'm assuming all these are uh kind of evolving towards a next version of YANG, or are we talking about different versions or different evolutions of the uh YANG?
Kent Watsen: Yes, there's uh—so first off, I'm mindful of the time, we're over limit, so a very quick response. Um, YANG++ is an idea for YANG Next uh to become object-oriented, an object-oriented version of YANG. Um, and uh that would be a big change to YANG. Uh, I think currently the idea is for YANG Next to be minimally uh non-backwards compatible. So it's mostly like, let's say, 95% the same as YANG 1.1, but there's some things that change, like for instance semantic versioning. So we just simply say that that's now the way of doing it, so that's not backwards compatible, but it's not a big change. You understand. Okay. Um, so again we're over time. Thank you everybody for uh joining um and and participating in this meeting. Um, first meeting of Monday morning is always difficult, but you we all hung in there and uh appreciate it, especially the coffee that Thomas brought me. Um, so thank you everybody. Have a good rest of day and week.