**Session Date/Time:** 25 Jan 2024 14:00

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

## Summary

This virtual interim meeting of the NETCONF Working Group was held to kick off the work for NETCONF Next and RESTCONF Next. The discussion focused on categorizing existing issues, establishing design teams, determining appropriate communication channels (mailing lists vs. GitHub), and calling for volunteers. Key outcomes include the formation of two design teams, agreement on creating GitHub repositories for the `bis` documents, and a plan for initial communication and kickoff meetings.

## Key Discussion Points

*   **Meeting Logistics**:
    *   The chairs opened the meeting, reiterated the IETF Note Well and Code of Conduct.
    *   Meecho was used for audio/video, with a Zulip channel and in-Meecho chat available for text communication.
    *   Participants were reminded to use the Q function to speak and remove themselves when finished.
    *   Notes were being taken on the datatracker.
*   **Status of NETCONF Next and RESTCONF Next Issues**:
    *   Per disclosed the current number of open issues on GitHub: 31 for NETCONF Next and 13 for RESTCONF Next. Additionally, 101 open issues for Yang Next were noted.
    *   Work categories identified:
        1.  Backwards-compatible extensions (no protocol upgrade needed).
        2.  Minor protocol upgrades (e.g., NETCONF 1.2, RESTCONF 1.1), which may or may not be backwards-compatible.
        3.  Major protocol upgrades (e.g., 2.0 versions), likely non-backwards-compatible and potentially requiring Yang Next.
    *   **RESTCONF Versioning Clarification**: Kent noted that RFC 8040 (RESTCONF) capabilities are explicitly versioned 1.0, establishing a precedent for a 1.1 version.
    *   **Yang Next Dependency**: Chin inquired about dependencies on Yang Next for major protocol upgrades. It was clarified that while some NETCONF/RESTCONF issues might be intertwined or require Yang Next, many can proceed independently.
*   **Design Teams (DTs) and Communication**:
    *   Chairs created two design teams: NETCONF Next DT and RESTCONF Next DT, with the idea that each would work across all three categories of issues for their respective protocols.
    *   Mailing lists for each design team were established (e.g., `netconf-dt@ietf.org`).
    *   **Mailing List vs. GitHub Workflow**: A discussion ensued regarding the use of GitHub issue trackers versus mailing lists.
        *   Per and Kent suggested mailing lists for coordination, logistics, or broader discussions not tied to a specific issue, while GitHub trackers are suitable for specific issues and contributions (e.g., pull requests).
        *   Mahesh highlighted that GitHub allows for geographically distributed, asynchronous contributions and workflows (pull requests, merges).
*   **Call for Volunteers**:
    *   The chairs emphasized that IETF work is volunteer-driven. Individuals are encouraged to contribute to specific issues, take ownership of documents, or serve as editors/authors.
    *   Contribution is not top-down; design team members will decide what to work on. Small, isolated issues can be tackled, leading to standalone drafts, or more comprehensive `bis` documents.
    *   Mahesh added that volunteers don't need to be responsible for every issue, but can focus on areas of personal interest.
*   **Design Team Meetings**:
    *   Kent and Chin raised concerns about scheduling recurring meetings due to global time zone differences.
    *   Mahesh suggested using Doodle polls to find suitable times for initial kickoff meetings and subsequent cadences, allowing design team members to decide what works best for them.
*   **Goals and Deliverables of Design Teams**:
    *   The primary goal is to produce drafts for adoption by the working group, ultimately becoming RFCs.
    *   The working group charter specifically mentions producing `RFC 6241bis` and `RFC 8040bis`.
    *   It was discussed that some backwards-compatible extensions might result in separate RFCs rather than being part of the `bis` documents, depending on the scope and design team's focus.
    *   **Yang Next Timeline**: Kent reiterated that Yang Next is a long-term project (potentially 3+ years) and should not block the start of NETCONF/RESTCONF Next work.
    *   **Consolidation of Extensions**: Kent suggested that new `bis` documents could consolidate existing protocol extensions (e.g., list pagination) into the base protocol, simplifying the ecosystem.
*   **GitHub Repositories for `bis` Documents**:
    *   Kent proposed creating dedicated GitHub repositories for the `6241bis` (NETCONF) and `8040bis` (RESTCONF) documents, initialized with the XML of the current RFCs. This would facilitate contributions via pull requests.
    *   Mahesh supported this, seeing it as a tangible way to kick off the effort and allow contributors to start suggesting changes.
*   **Volunteer Confirmations**:
    *   Kent volunteered to participate in both NETCONF Next and RESTCONF Next design teams.
    *   Chin also volunteered for both NETCONF Next and RESTCONF Next design teams.
    *   Ram volunteered to join the design teams and start by reviewing open issues.
    *   Shang expressed willingness to contribute to both and emphasized prioritizing issues not dependent on Yang Next.
*   **Design Team Mailing List Access**:
    *   Chin asked if DT mailing lists are public and if subscribing makes one a member. Kent clarified that lists are public, anyone can join, and while lurking is fine, authorship on documents requires actual text contributions.
    *   Mahesh noted that GitHub allows for different privilege levels (admin, write, read) which could be used to manage contributions.
    *   Per highlighted that GitHub can also attract contributions from outside the direct IETF participant pool (e.g., colleagues, external experts).

## Decisions and Action Items

*   **Design Teams Established**: The NETCONF Next Design Team and RESTCONF Next Design Team have been formally established by the chairs.
*   **GitHub Repositories**: Chairs will create GitHub repositories for `RFC 6241bis` and `RFC 8040bis`.
*   **Initial Communication (Per)**: Per will send a summary email of this interim to the main NETCONF mailing list, including links to the new design team mailing lists.
*   **Repo Initialization (Kent)**: Kent will initialize the new `bis` GitHub repositories with the XML from the current base protocol documents.
*   **Follow-up Communication (Per)**: Per will send a second email to the NETCONF mailing list announcing the creation and availability of the `bis` GitHub repositories.
*   **Kickoff Meeting Scheduling**: Doodle polls will be sent to the design team mailing lists to find suitable times for initial kickoff meetings.
*   **Volunteer Contributions**: Kent, Chin, Ram, and Shang explicitly volunteered during the meeting to participate in the design teams.

## Next Steps

1.  **Chairs**: Facilitate the creation of GitHub repositories for `RFC 6241bis` and `RFC 8040bis` and send out the initial summary email and subsequent repo announcement to the `netconf@ietf.org` mailing list.
2.  **Design Team Members**: Subscribe to the `netconf-dt@ietf.org` and/or `restconf-dt@ietf.org` mailing lists, participate in Doodle polls for kickoff meetings, and begin reviewing existing GitHub issues to identify areas of interest.
3.  **Design Teams**: Hold initial kickoff meetings, self-organize, and decide on specific issues to pursue, potentially leading to standalone drafts or contributions to the `bis` documents.
4.  **Working Group**: A status update on the design team's progress will be provided at IETF 119.