**Session Date/Time:** 04 Dec 2023 17:00

# [NETCONF](../wg/netconf.html)

## Summary

This interim meeting of the NETCONF Working Group focused on classifying outstanding issues for `restconf-next` and `netconf-next`. The primary goal was to determine which issues would require a new protocol version, which could be addressed with existing protocols or minor updates, and which could be closed due to ongoing work or irrelevance. Discussions also touched upon the broader strategy for evolving both NETCONF and RESTCONF, including feature parity and encoding formats. Due to the number of issues, a follow-up meeting in January will be scheduled.

## Key Discussion Points

*   **Purpose of `*-next` versions**: A key point of discussion was the understanding that `netconf-next` and `restconf-next` should primarily address significant changes that require a new protocol version, such as new capabilities, major structural changes, or correction of fundamental design flaws (e.g., lack of warnings, new encoding formats). Minor additions or bug fixes often do not necessitate a new protocol version.
*   **Issue Classification Categories**: Issues were classified into three main categories:
    *   **Close**: Already fixed, ongoing work, or deemed irrelevant.
    *   **Needs new protocol version**: Requires a change that breaks backward compatibility or introduces fundamentally new capabilities.
    *   **Clarification / Document Update**: Requires only improved text in existing RFCs or minor additions without protocol changes.
    *   Some issues were also flagged for further investigation or deferred due to the absence of the original submitter.
*   **RESTCONF Issues Reviewed**:
    *   "Enhancements to work with lists in RESTCONF": **Closed** (ongoing work in list pagination).
    *   "Correct `tag` value in `response-mode` for data resource existing case": **Needs new protocol version** (would break existing clients).
    *   "Restructure the RESTCONF error messages": **Needs new protocol version** (for better HTTP tailoring).
    *   "Support for accessing a list/leaf-list as a data resource": **Needs new protocol version** (adds direct URI access without keys, currently requires keys per RFC 840).
    *   "JSON encoding for a single list item is not intuitive": **Needs new protocol version** (changing RFC 7951 behavior, not broadly supported).
    *   "Enable PUT to move a list entry without needing to supply the entry's contents": **Needs new protocol version**.
    *   "Replace the RESTCONF Yang data with Yang data structure extension": **Needs new protocol version**.
    *   "HTTP/3 (QUIC) based HTTP/2 as a transport": **Needs new protocol version** if utilizing QUIC's multi-streaming capabilities for features like flow control in Telemetry; otherwise, transparent.
    *   "Deprecating or obsoleting the combined data store resource": **Requires protocol change** (would break most existing deployments, discussion on NMDA adoption vs. legacy support).
    *   "Exclude query parameter": **Decision deferred** for input from the original author.
    *   "Keep-alives in the protocol": **Clarification/Document Update** (can be addressed with existing mechanisms or minor RFC 8040 recommendations like comment messages).
    *   "XPath filter": **Clarification/Document Update** (can be supported by using the POST method on the operation resource in existing RESTCONF).
*   **NETCONF Issues Reviewed**:
    *   "Copy config on factory default data store": **Needs use case** for further discussion, action deferred.
    *   "Support for binary encoding": **Needs new protocol version**.
    *   "Confirmed commit procedure needs clarification if persist parameter is used": **Needs new protocol version** (if desiring persistence through server reboots, which is a change in current RFC behavior). Requires further examination.
    *   "Commit-Z-Light should accept vendor-specific information": **Needs new protocol version** (to allow returning additional data like warnings in RPC replies, a recognized oversight in RFC 6241).
    *   "Clarify meaning of default operation replace in any config": **Clarification/Document Update** (to improve understanding of existing intentional behavior, e.g., for `copy-config`).
    *   "Use of Quick as transport": Similar to RESTCONF, **Needs new protocol version** if utilizing multi-streams for things like subscriptions or Telemetry flow control; otherwise, transparent transport.
    *   "Cleanup of the spec relative to Yang XML": **Document restructuring** (long-term effort to factor out XML encoding specifics into a separate RFC, while retaining examples in existing NETCONF RFCs).
    *   "Cleanup hello capability and version negotiation": **Clarification/Document Update** (Yang 1.1 and Yang Library address redundancy, not a NETCONF protocol change).
    *   "NAAM - Need to re-examine or rename NAAM": Kept in NETCONF WG for now.
    *   "Private candidate data stores": **Closed** (work ongoing).
    *   "Stop on error and continue on error should be optional": **Needs new protocol version**.
    *   "Make lock and unlock optional": **Needs new protocol version** (if making optional to implement).
    *   "Extend the notification header to support Yang XPath and version": **Closed** (work in progress in other drafts).
    *   "Fully define the merge operation": **Clarification/Document Update** (for `leaf-list` and `bits` types, may need to be split into separate issues).
*   **Meta-Discussion on NETCONF and RESTCONF Evolution**:
    *   Both protocols are considered necessary for different use cases; there is no current intent to deprecate one in favor of the other.
    *   There is strong community interest in adding JSON and CBOR encoding support to NETCONF, similar to RESTCONF.
    *   Maintaining feature parity where sensible was supported, with `confirmed-commit` highlighted as a missing RESTCONF feature.
    *   The group acknowledged a potential higher pressing need to address NETCONF issues first, particularly around new encodings.

## Decisions and Action Items

*   **Decision**: Several GitHub issues were closed due to ongoing work, being fixed, or deemed irrelevant (e.g., "Enhancements to work with lists in RESTCONF", "Private candidate data stores", "Extend the notification header to support Yang XPath and version").
*   **Decision**: Many issues were classified as requiring a "new protocol version" or "clarification/document update" for `netconf-next` or `restconf-next`.
*   **Action Item**: The co-chairs will schedule another interim meeting in January to continue classifying remaining issues.
*   **Action Item**: All participants are encouraged to update the GitHub issues list with their comments, opinions, and suggestions to facilitate faster review in future meetings.
*   **Action Item**: Per will update tagging for encoding-related issues to group them.
*   **Action Item**: The decision to close the "Exclude query parameter" issue is deferred, pending input from the original author.
*   **Action Item**: Further investigation into the use case for "Copy config on factory default data store" is required before further action.
*   **Action Item**: Andy to provide a reference (section number) to RESTCONF's existing `POST` method for operation resources as an alternative to an "XPath filter".

## Next Steps

*   **Schedule a follow-up interim meeting in January** to continue the classification of remaining `restconf-next` and `netconf-next` issues.
*   **Prioritize issues** based on their impact, feasibility, and community interest in the upcoming meetings.
*   **Encourage offline discussion and comments** on the GitHub issue tracker to expedite progress.
*   **Focus attention on key areas** such as flexible message encoding (JSON/CBOR) for NETCONF and clarifying existing behaviors in both protocols.