Agenda for the NETCONF 124 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/124/materials/agenda-124-netconf Session: Monday, November 3, 2025 Monday Session 1 Room Name: Agora WG Chairs: Kent Watsen (kent plus ietf at watsen dot net) Per Andersson (per dot ietf at ionio dot se) WG Secretary: Mithun Thai Valaphil (mithun dot ietf at gmail dot com) Available Now: ICS: https://datatracker.ietf.org/meeting/124/sessions/netconf.ics Available During Session: (pick one) Onsite Tool: https://meetings.conf.meetecho.com/onsite124/?group=netconf Remote Tool: https://meetings.conf.meetecho.com/ietf124/?group=netconf Audio Only: https://mp3.conf.meetecho.com/ietf124/netconf/1.m3u Chat Only: https://zulip.ietf.org/#narrow/stream/netconf Available During and After Session: Notes: https://notes.ietf.org/notes-ietf-124-netconf Slides: https://datatracker.ietf.org/meeting/124/session/netconf Drafts (PDF): https://datatracker.ietf.org/meeting/124/agenda/netconf-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/124/agenda/netconf-drafts.tgz Available After Session: Recording: https://www.meetecho.com/ietf124/recordings#NETCONF Introduction Chairs (10 minutes) Session Intro & WG Status Thomas Graf: udp-notif document status should be "Publication Requested" instead. The document shepherd review concluded with no open action items. Kent: acknowledged. Mahesh Jethanandani: Regards docs in the AD queue. We recently unblocked on the HTTP client/server draft which should unblock various other drafts, including netconf client/server, restconf client/server and ultimately, https-notif draft; so we should a few more drafts make it into the RFC editor queue after this morning. Kent Watsen: We haven't published a draft for a year, so it would be good to see a new RFC published (by this group). Chartered items: List Pagination for YANG-driven Protocols (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-09 Discussion Leader: Qin Wu Mahesh Jethanandani (as posted in chat): I went back to look at the history of calling WGLC on the list pagination drafts. I did close the second WGLC back in March, so if we want a WGLC, it will have to be a new one, a third. Do the authors believe the document is ready for another WGLC. Per Andersson (as posted in chat): @mahesh as you saw there are a few outstanding issues that need to be resolved before WGLC. but it is close. Chair Action: None Support of Versioning in YANG Notifications Subscription (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning-09 Discussion Leader: Thomas Graf Thomas Graf: Requesting WGLC Robert Wilton: It's unclear as to which module name is being put on the path. Needs to be clarified in th document what it is. Nothing needs to change, just need some clarification. Kent Watsen: We can start a WGLC Chair Action: Start WGLC Extensible YANG model for YANG-Push Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-03 Discussion Leader: Thomas Graf Robert Wilton: 4 comments: - in terms of the location of the contents field, might want to consider the COSE provenance draft, that is being presented in OPSAWG. - Don't think that implementations MUST configure hostname - Don't have a feature at the top of the module, it isn't necessary - Keep the names shorter rather than longer. Thomas Graf: We will remove the sentence that "implementations MUST configure hostname" and the feature on envelope support. Thomas Graf: Will review COSE provenance draft. Reshad Rahman: There is another option to have an "observed" container to wrap timestamp and point-in-time. Thomas Graf: Agree, that would be another valid option. Would like to have feedback from the working group. Show of hands poll: Should timestamp be kept as is in th draft? Total participants: 57 yes 15, no 6 no opinion, 3 Per Andersson: On "Show of hands" Rough consensus is to keep timestamp as it is. Benoit Claise: New WGLC message was sent after changing state to WGLC which is a new feature. Can you clarify where we are in the WGLC? Kent: We should have changed state to WGLC, it was an oversight. After changing the state recently, the email got sent but the actually the document has been in WGLC for sometime. Second issue slide: Reshad Rahman: I don't like config being dependent on state, it is my preference not to have such a dependency. Robert Wilton: I strongly oppose config depending on operational state. Joe Clarke : while the draft explains the operational impact of changing a particular option, the YANG module does not. Modifying this option could cause existing subscriptions to be removed, which would violate the principle of least astonishment for operators. Suggest that implementations, such as CLIs, provide warnings before applying such changes, and that the YANG module explicitly indicate that altering this option may disrupt or delete active subscriptions. Robert Wilton: Essentially, no other configuration behaves this way. For example, we don’t block the removal of BGP configuration until all BGP sessions are down, and we don’t prevent shutting down an interface just because it’s carrying traffic. In general, configuration changes are allowed even if they may cause disruption. This makes the current behavior—where changing this option can implicitly remove subscriptions—stand out as unusual. Joe Clarke : If I shut down an interface or delete configuration, I naturally expect a negative or disruptive outcome. However, when I enable an option like enable-notification-envelope, I would not reasonably expect existing subscriptions to disappear. I’m fine with simply adding clarifying text to the YANG module so users don’t need to refer back to the draft, but I disagree with comparing this situation to shutting down an interface. Robert Wilton: I propose that we keep text about the impact of changing this (which might require an update to YANG module), but don't require any restriction on the config, tearing down the subscriptions is fine. Show of hands: Should the proposed text for enable-notification-envelope be used? Total participants: 60 yes 0, no 8, no opinion 7 Per Andersson: Consensus is not to make this change. Mahesh Jethanandani (not spoken on the mike, and just an observation): The consensus was that the YANG module will be updated to reflect that config should be allowed, and that a warning will be added to the YANG module that such a change would disrupt existing sessions. Chair Action: None Subscription to Notifications in a Distributed Architecture (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-16 Discussion Leader: Thomas Graf Thomas Graf: @Mahesh, What is the next step? Are there any open items on ourside? Mahesh Jethanandani: The draft is still a WG document. As such it is for the chairs to decide what is the next step. Kent Watsen: Was there any transport issue? Thomas Graf: There was a transport area direcorate review for udp-notif. OPS directorate and YANG doctors review for distributed-notif. WG LC was finished in Feb and Shpherd review done in June. No remaining items. Per Andersson: Unsure of the current status, we will need to check. Kent Watsen: Since the WG LC was a long time ago, then perhaps should have a second to refresh the reviews. Thomas Graf(chat): @Per and @Kent. distributed-notif had a OPS directorate and YANG doctors review. udp-notif had a transport area directorate review. All open points from those and shepherd reviews were addressed. Since distributed-notif has no normative text regarding transport, having a transport area directorate review might not bring much value. I see that there is a second transport area directorate review open and due October 23rd for udp-notif. Please let both author groups now the next steps and action items. Augmented-by Addition to the YANG Library (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby-12 Discussion Leader: Zhuoyau Lin Per Andersson: The document was updated according to the outstanding issue discussed in IETF 123 Madrid. The issue is that there is a restriction that the YANG modules and the augmented-by YANG modules need to be listed in the same module-set, a similar restriction exists to deviations. It has since the update been sent to publication and is in the AD queue. Mahesh Jethanandani (posted in the jabber queue): I will acknowledge that the draft is in PubReq queue and the next one for me to review. Since the document had exited the WG, not sure why it was presented again. Chair Action: None NETCONF and RESTCONF Private Candidate Datastores (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-07 Discussion Leader: James Cumming Robert Wilton: I had quite a few comments on what I believe was the -06 WGLC version, but I don’t think any of my individual points received a direct response. Should I review the latest version to check whether my comments were addressed, or is there a better way to approach this? I just want to confirm the expected process. James Cumming: We did incorporate your comments in the revisions. The remaining point about splitting NETCONF and RESTCONF was discussed, but the differences were minor and separating them made the document harder to read, so we kept them together. Robert Wilton: Please can I get a chance to do a final review to check that my WG LC comments have been addressed. James Cumming: -08 has been pubished, that should be fine. Kent Watsen: Once Rob's comments have been addressed, we could close the WGLC and look to do a sheperd write up. Chair Action: None NETCONF over QUIC (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-quic-05 Discussion Leader: David Dai Robert Wilton: On stream splitting, I think your current approach makes more sense. I had a question for Per: my assumption is that you typically don’t need multiple NETCONF sessions from the same client to the same server, so this scenario seems unlikely. But I’m not sure whether controller implementations might disagree, so I wanted to validate that assumption. Per Andersson: It’s much simpler to have one session per connection — that model makes a lot more sense. The drawback of allowing multiple sessions is that you would still need to use the same credentials and security context anyway, so there’s no real benefit. Kent Watsen: The only real reason you’d want multiple sessions would be to use separate private candidates. If you need independent private candidate datastores, then separate sessions make sense; otherwise, there’s not much justification for maintaining multiple parallel connections. Robert Wilton: Is there any implementations of this yet? Having implementations to test against would be helpful to confirm that the proposed behavior works as intended. Per Andersson: There is proxy implementation. Kent Watsen: Want to remind the working group that there is no RESTCONF-over-QUIC document because RESTCONF already supports QUIC. So any work we do here would only need a NETCONF-specific document, and we wouldn’t need a parallel RESTCONF one. That’s why there isn’t a RESTCONF document in this. Robert Wilton: Is there anything in the current RESTCONF draft that covers splitting operations over separate transport sessions — effectively using separate streams for things like telemetry/notifications? Kent Watsen: It really depends on the HTTP version. If you’re using HTTP/2, then you can potentially use channels, and if you’re using HTTP/3, you would use the QUIC-specific streams. So the behavior is tied to the underlying transport, and the details vary accordingly. Lou Berger: Having a dedicated document would be very useful—both to cover exactly what Rob was discussing regarding the use of multiple channels within HTTP/3, and because some vendors have already said they don’t want to implement this behavior without a clear specification. Providing that guidance would help clarify expectations. Kent Watsen: Speaking as the call-home draft author, not as chair: you raise a good point. I’m not sure how call-home would work over QUIC, since QUIC merges transport and security, whereas the original solution relied on those being separate. We need to look into this further, and can continue the discussion offline. Mahesh Jethanandani (as part of chat): For RESTCONF over QUIC, if the only thing to address is how it will work over H3, can it be collapsed into the existing NETCONF over QUIC draft and the draft expanded to address both NETCONF and RESTCONF. Kent Watsen(again on chat): I don't think there is any question for how RESTCONF can work over H3 (it's just HTTP, right). I thought Lou was only asking for a document to explicitly state that it's allowed. IMO, that document could be the http-client-server document, with its use of the new ietf-http-versions module. Per Andersson (on chat):I think the issue that was asked to be defined is that it is allowed to open several QUIC or HTTP/3 streams in a QUIC connection for RESTCONF sessions, right? Robert Wilton(on chat): @Kent, both that it is allowed and also about putting telemetry subscriptions on separate QUIC streams (if that makes sense). Per Andersson(on chat): it might do, but that would be something else than RESTCONF Event Streams then? That is a bit more elaborate, but makes sense. Chair Action: None YANG Groupings for QUIC clients and QUIC servers (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-quic-client-server-03 Discussion Leader: Per Andersson Phil Shafer: Under what conditions would this registered number likely change? Per Andersson: I don't know. I will ask IANA or someone else knows. Robert Wilton: Treat it as normal YANG Semver rules, don't treat in any special way. Per Andersson: Yes, I actually believe this isn’t a big issue. It just needs the right clarification, and I think that YANG Semver helps a lot in this regard. Chair Action: None Non-Chartered items: CBOR Encoding for HTTPS-based Transport for YANG Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-chittapragada-netconf-https-notif-cbor-03 Discussion Leaders: Bharadwaja Meherrushi C, Vartika T Rao, Siddharth Bhat, Hayyan Arshad (remote) Kent Watsen: I don’t think it’s necessary for us to wait until the document is perfect before adopting it. At this stage, we understand what the document is trying to achieve, and that alone is enough to move forward with adoption. Show of hands poll: Is the WG ready to adopt draft-chittapragada-netconf-https-notif-cbor? Total participants: 61 yes 22, no 0, no opinion 3 Thomas Graf(chat): @Meher and team, great work on CBOR implementation in libyang. Michal Vasko, libyang maintainer is joining IETF 124. Can you share when you intend to finalize the code, wherever we can help and perhaps test at IETF 125 hackathon? Alex Huang Feng (chat): @Meher and company, I would prefer application/yang-data+cbor, the data that would be pushed as notifications are not only pure CBOR (RFC8949), but YANG-CBOR (RFC9254), so I would suggest the authors to use application/yang-data+* for any data that is encoded using YANG. Thomas Graf (chat): +1 on Alex comment Bharadwaja Chittapragada (chat): @Thomas Graf, Thank you ! That is great to know. We have got the main core-functionality working for cbor named identifier- we would need to work with formatting and handling a few edge cases. We can complete it based on the reviews. We will get back with the exact time frame we would need to complete it but should be the cbor named identifier full feature should be ready before IETF 125 for sure. Bharadwaja Chittapragada (chat): @Alex and @Thomas noted the comment. Thank you! Chair Action: initiate adoption YANG Push Lite (20 min) https://datatracker.ietf.org/doc/html/draft-wilton-netconf-yang-push-lite-02 Discussion Leader: Rob Wilton Kent Watsen: YANG Push” isn’t a perfect name, but it’s what we have, and calling this “Push v2” keeps the lineage clear. I don’t think “lite” should be in the name—it won’t age well. Something like “YANG Push v2” or a more telemetry-focused name would be better, and we can settle on something suitable. Robert Wilton: In terms of the container used to configure this, it falls under datastore telemetry, so something along those lines might be a better naming direction. But I’m not concerned or stuck on the naming itself—that’s not the key point here. Jason Stern: How are separate processes pushing subscriptions coordinated? They might not be independent if they need to coordinate. Robert Wilton: There is a requirement if you have distributed publishers that they will need to coordinate, otherwise if something is delayed and the subscriptions are merged you might not know when something has happened. Jason Stern: This requirement appears to conflict with the goal of allowing subscriptions to be split across independent processes, since coordinating an end-of-period notification would undermine that independence. A similar discussion is currently taking place in the gNMI-based telemetry community, it may be useful to share insights between the two groups. Robert Wilton: Yes and we’re very aware of the similar discussions happening in the gNMI space. Goal with YANG Push lite isn’t to make it identical to gNMI, but to align things like notification handling and message structure so that implementers can reuse code across both. Given that many vendors already support gNMI, this kind of alignment is intentional and beneficial. Reshad Rahman (chat): +1 on end-of-monitoring being very useful Thomas Graf (chat): @Reshad, currently YANG-Push only has statistics on receiver level at the publisher. Missing statistics on subscription level which YANG-Push Lite addresses. Thomas Graf (chat): @Reshad and @Rob, +1 on naming YANG-Push V2 instead of YANG-Push Lite since we are not only reducing complexity but we are also adding features. We are optimizing/updating. Balázs Lengyel: As I understand it, YANG Path is essentially a JSON-formatted variant of XPath, and there’s actually a 3GPP specification that attempts something similar. I’ll post the specific 3GPP spec number in the chat. Robert Wilton: XPath’s tight coupling to XML adds friction and complexity, and XPath 1.0 hasn’t been a great fit for YANG—especially for must statements, where mistakes are common. XPath 2.0 or 3.0 are even more complex. A lightweight, YANG-specific path language may be a better direction. Reshad Rahman: Has there been any discussion about using YPath consistently throughout NETCONF? Would existing mechanisms continue using XPath while YPath is only used for YANG Push? Robert Wilton: If we expanded this more broadly, it would probably fall under YANG Next or NETCONF Next. For now, I’m focused on subscription paths for YANG Push and YANG Packages. Embedding XML-based paths adds unnecessary complexity, especially with namespaces; a JSON-style path with simple module prefixes feels much cleaner. Per Andersson: Could we simply use the API identifier format from RESTCONF? Would that be sufficient? In other words, using the RESTCONF-style path that includes the module name, a colon, the identifier, and the slash-based structure. Robert Wilton: I might be very similar. We want to include the ability to have keys in the path, allow those keys to be optional, and also support using regex on those key values. James Cumming: Yes, the idea is to allow list keys and list key values when referencing instance data, so that paths can point to both schema elements and specific instances. A potential next step would be adding search capabilities, such as wildcards or regex. The overall proposal is essentially a blend of the JSON-path approach from RFC 7952 and the way instance identifiers are defined, combining elements of both. Thomas Graf: +1 for working group adoption. As the chair’s slides showed, most of the YANG Push work is now nearing completion, and it makes sense to bring this document into the working group so we can begin the broader discussions and refinements. Joe Clarke: Bringing this to the list sooner and keeping the discussion there is probably the right approach. In my view, there’s clearly interest in this work, so adopting it now and continuing the conversation on the list—and possibly at an interim—would be a great idea. Show of hands poll: Does the WG want to adopt draft-wilton-netconf-yang-push-lite? Total participants: 60 yes 23, no 0, no opinion 3 Paolo Lucente: We’ve invested years of outreach around the “YANG Push” name, so completely changing it now would create confusion. “YANG Push Version 2” seems fine, but we should keep consistency and not abandon the established branding. Reshad Rahman: how do we justify using YANG Push Light or v2 instead of gNMI when many rely on gNMI today? Some of gNMI’s drawbacks aren’t widely discussed, so bringing those points into the open might help. Robert Wilton: gNMI works for many, but the IETF still needs a clearly specified alternative. The aim is to fix gNMI’s inconsistent behaviors and provide better extensibility through YANG Push Light. Adoption will depend on delivering a complete, usable end-to-end solution with client support. Chair Action: None Open mic discussion: Kent Watsen: Would like to revisit whether the working group should keep NETCONF and RESTCONF aligned. This was raised before and there was interest but we never set concrete milestones. As chair, I still see most proposals focused on NETCONF, and I keep asking whether RESTCONF should receive the same updates and whether common parts should be factored out. Would like to get a sense of whether the group actually wants to commit to this going forward. Robert Wilton: From what we see, NETCONF is the dominant controller-to-device API, and there’s little demand for RESTCONF at the device level. So whether the two need to stay in lockstep may depend on whether a feature is aimed at controllers or devices. I do support more commonality, though, since duplicating the same work in two specs is inefficient. Kent Watsen: Many operators have said it’s still too hard to manage devices—too many libraries, too much programming overhead—and that’s part of why gRPC looks attractive. One takeaway from the recent IETF MOPS/IETF-OPS discussions was that RESTCONF actually has a lower barrier to entry than gRPC, since JSON over HTTP is universally available without special libraries. It’s more of a forward-looking point about usability. Mahesh Jethanandani: If RESTCONF is stacked on top of NETCONF and a controller is acting as a pass-through, the encodings need to be closely aligned. That way, the controller can forward requests with minimal processing. This compatibility is part of why we’re trying to keep the two protocols consistent. Lou Berger: maintaining feature parity is important because it lets the community focus on YANG model design without fragmenting the solution space by transport. The clean separation between models and protocols has been key to YANG’s adoption, and splitting that risks creating incompatible model sets. From an implementation standpoint, the choice between NETCONF, RESTCONF, or gNMI ultimately depends on the sector you’re supporting. Mahesh Jethanandani: We can update the charter to include an explicit statement that we should aim for compatibility between NETCONF and RESTCONF. Benoit Claise: Question to Lou about statement that YANG models would differ depending on whether NETCONF or RESTCONF is used. Is there an example? If that’s true, it’s definitely a problem. Lou Berger: If RESTCONF and NETCONF diverge into different market segments, the next step would be writing YANG models only for specific device or controller use cases, which would fragment the ecosystem. I think that’s a bad direction—we should keep YANG models transport- and encoding-independent. Would like to hear examples from Rob Wilton. Robert Wilton: I don’t have concrete examples of modules that would be directly impacted by this yet. One area I’m unsure about is list pagination—it’s not clear whether that needs to be applied at the device level, the controller level, or both. For features like that, you might end up designing different solutions depending on whether you’re targeting constrained devices or more capable controllers, which could lead to divergence in practice. Thomas Graf: NETCONF and RESTCONF also differ at the encoding level, so if we’re talking about feature commonality between them, does that also imply commonality in encodings (JSON vs XML)? In other words, do we also want to align behavior across both encodings, or is the goal limited to protocol features only? Lou Berger: YANG modules should be completely agnostic to encoding and transport. They should fully support any standardized encoding, even if it’s defined outside the IETF, as with gNMI. In my view, YANG models should be 100% independent of both encoding and transport. Maria: Note that CBOR is also in use, and we’re already seeing issues like IPv6 addresses being encoded as strings instead of binary. That shows how easily divergence happens, and I strongly favor keeping all encodings aligned to avoid bigger problems down the road. Kent Watsen: The device vs. controller distinction feels very IETF-centric, and RESTCONF has the opportunity to move beyond that. Like gRPC, it could be used for managing any kind of web-based application not just network devices which greatly expands its potential. Not sure the device/controller divide really matters here. Benoit Claise: Fully agree with Lou’s point: whatever we do, our YANG models must remain agnostic to both encoding and transport. That’s the key principle we need to preserve. Kent Watsen: This issue is coming up because there’s a NETCONF-improvement draft in the working group that, in my view, may not even be implementable in RESTCONF. I’m not asking for a RESTCONF solution right now, but we should at least know whether one is possible before publishing the NETCONF RFC. That’s the background for why this discussion started. Show of hands poll: Should the WG ensure feature parity between NETCONF and RESTCONF? Total participants: 60 yes 20, no 0, no opinion 5 Chair Action: Send Mahesh propsed Charter update text. Time Remaining: 0 minutes