**Session Date/Time:** 07 Nov 2023 08:30 # netconf ## Summary The NETCONF working group meeting at IETF 118 covered a range of topics, including updates on existing drafts, discussions on new proposals, and future directions for NETCONF and RESTCONF. Key discussion points included private candidate datastores, transaction ID, UDP notifications, and the integration of YANG-modeled data into time-series databases. Several presentations were made, and the group actively engaged in discussions regarding the various drafts. ## Key Discussion Points * **Private Candidate Datastore:** Discussion focused on the lifecycle of private candidates, their applicability to RESTCONF, and potential integration with transaction IDs. There was some confusion regarding when the datastore is committed versus destroyed, and clarification was provided. The group agreed that private candidates are less useful in the RESTCONF context due to the short-lived nature of RESTCONF requests, but ways to improve support were discussed. * **Transaction ID:** The draft update covered the implemented transaction history concept. Feedback was received concerning the format of e-tags for RESTCONF compatibility. There was discussion on potential overlaps between transaction IDs and private candidates. A poll showed a need for more time to read the draft. * **UDP Notifications:** Discussions centered around packet loss concerns and the need for congestion control mechanisms. Recommendations were requested regarding maximum packet size. A Transport Services Directorate review was also discussed. * **Pagination Mechanisms:** Cursors and snapshot parameters were key topics, with a poll regarding opting in vs. opting out of cursor based pagination. The group favored opt-in. Server support for local aware sorting was detailed. * **Versioning in YANG Notifications:** Errors for revision unsupported and revision label unsupported were extended. The relationship to YANG packages was discussed. * **Host Event Sequencing:** A request was made to adopt the draft. The need for consistent host identification across the network was discussed. The rational for separating the two drafts with host sequencing was also clarified. * **YANG Model for NETCONF Notifications:** Concerns were raised about duplicating definitions of message time with an existing working group document. The author agreed to coordinate with the other document's authors. The need for SIP allocation and tooling was also discussed. * **Generic YANG Groupings for UDP Clients and Servers:** Discussion about whether the DTLS extensions need to be explicitly defined. There was a suggestion to remove them. * **Project Team Push Integration into Apache Kafka:** Overview of an internship project and discussions about how to store YANG models in a schema registry, identify the YANG model for data, and obtain the model and dependencies. * **Filet List Framework:** Discussions about using YANG descriptions for time-series data in order to provide data traceability. Concerns were raised about losing semantics when mapping data to time-series databases. ## Decisions and Action Items * **Client Service Suite:** Work with AD and Rob on the liaison response, send it to the working group for confirmation, and then send it on. * **Private Candidate Datastore:** James and Rob to address the RESTCONF concerns. John and co-authors to discuss interactions with Transaction ID draft. * **Transaction ID:** Update the format of e-tags to better conform to HTTP documents. * **UDP Notifications:** Authors to make the recommendation of packet size more clear and the need for congestion control. * **Pagination Mechanisms:** Consider the need to tag subsequent requests for pagination with snapshots. * **Supportive Host Event Sequencing in, Yang Notifications:** Request working group adoption. * **YANG Model for NETCONF Notifications:** Author to coordinate with the "notification messages" document to avoid duplicate definitions. Request Sevorside. * **Generic YANG Groupings for UDP Clients and Servers:** Author to remove details of less plan or the details of the server parts in it. ## Next Steps * Continue discussions on the mailing list for all drafts. * Per to set up a side meeting to discuss NETCONF Next and RESTCONF Next and communicate information to the mailing list.