**Session Date/Time:** 07 Nov 2025 14:30

# NETMOD Session Minutes - IETF 124

## Summary

The NETMOD session at IETF 124 covered a range of topics including the status of various working group documents, a discussion on a liaison from 3GPP, and detailed updates on YANG versioning tooling, YANG Push validation, and YANG example validation. Key discussions included defining how to address conflicting MAC address definitions, the need for robust tooling to support new YANG versioning mechanisms, and methods for validating `anydata`/`anyxml` and examples in YANG modules. Decisions were made regarding the publication of `6991-bis` and modifications to the `Semver` draft.

## Key Discussion Points

*   **Document Status and MAC Address Discussion:**
    *   Several RFCs were recently published, with thanks to the working group and authors.
    *   The `6991-bis` draft, related to MAC address type definitions, will be published *as is*.
    *   A new discussion was initiated regarding the slightly conflicting definitions of MAC addresses between IEEE and IETF. No conclusions are expected at this meeting, but the aim is to develop a draft for discussion at the next meeting.
    *   Documents post-last call, `system-config` and `immutable-flag`, are stalled pending author action.
*   **AD Report (Mahesh Jethanandani):**
    *   The `Semver` draft, having more than five authors, requires an updated Shepard's report with justification for the author count (Question 13).
    *   The `Semver` draft also requires a modification: the YANG module file name specification, currently stating "may publish," must be changed to "must publish" both file names. The Datatracker state needs to be updated to reflect this requirement.
    *   A cluster of documents, including the `sub-interface VLAN model`, are awaiting reviewer conclusions before proceeding to Last Call.
*   **Liaison from 3GPP:**
    *   3GPP expressed dissatisfaction with the proposed solution in `system-config` and `immutable-flag`, preferring an alternative previously considered. They requested the working group reconsider.
    *   The working group reaffirmed its prior stance against introducing non-transactional behavior into YANG models. The chairs will draft a response encouraging 3GPP members to participate directly if they wish to influence the outcome.
*   **Schema Comparison (Michal Vasko):**
    *   Presented a draft to compare two YANG module/schema revisions, categorizing changes as backwards compatible (BC) or non-backwards compatible (NBC) based on YANG 1.1 RFC and the versioning draft.
    *   Differentiates between parsed (text) and compiled (on-the-wire) schemas for different use cases (tooling vs. authoring).
    *   The tool supports both YANG 1.0 and 1.1.
    *   Discussion arose regarding how to categorize a change in the YANG version (e.g., 1.0 to 1.1) itself, with arguments made for it being non-backwards compatible due to import restrictions. This point requires a decision.
    *   The draft includes an extension for authors to explicitly mark ambiguous changes in extensions as BC. The Libyang reference implementation supports this.
*   **YANG Package Update (Rob Wilton):**
    *   Provided an overview of the YANG packages solution, which offers an alternative, hierarchical mechanism for managing YANG modules using Semver.
    *   Mentioned the need for a separate draft to provide IANA update guidelines on versioning, which the chairs anticipate adopting quickly.
    *   Progress on the YANG packages draft has been slower than anticipated due to focus on other work.
    *   Mahesh highlighted that an IANA document would need to address how `revision` statements in modules already in the RFC Editor queue are handled.
*   **YANG Versioning Tooling Update (Joe Clark):**
    *   Emphasized the critical need for tooling to support new YANG versioning extensions and rules, noting that the AD has put related documents on hold until tooling is ready.
    *   Outlined the impact on key tools: `Zim` (extraction), `RFC Strip` (extraction), `Pyang` (linting, validation), and `Libyang`/`Yanglint` (linting, validation).
    *   Reported significant progress on implementing these tooling changes, with `Zim` updates merged, and substantial work done on `Pyang`, `RFC Strip`, and `Libyang`.
    *   A sense of those present indicated a strong desire for the tooling to also suggest the *next semantic version* based on detected changes, a feature not yet fully implemented.
    *   Discussions included potentially integrating tooling checks into ID Nits and modifying shepherd processes to ensure new modules adhere to versioning rules.
*   **YANG Push Validation (Asem Elshimi):**
    *   Presented the problem of validating `anydata`/`anyxml` content in YANG Push messages, especially at scale, to prevent processing errors (e.g., integer overflows). Current approaches for `RFC 7950` and `8649` are insufficient.
    *   Proposed an *optional* mechanism where validation libraries can look up `anytree` content against the YANG Library-defined schema and validate it. Invalid data would be routed to a "dead letter queue" rather than being dropped.
    *   Discussion highlighted the challenge of validating subtrees within `anydata` and defining how an implementer would choose to enable/disable this optional validation.
*   **YANG Example Validation (Camilo Cardona):**
    *   Stressed the importance of examples in documentation and proposed using "coverage" (what parts of a YANG module are covered by examples) as a metric.
    *   Noted that the `Jansson` tool already provides similar functionality.
    *   Identified gaps in formalizing how examples are integrated, extracted, and differentiated (valid vs. invalid) within the IETF document creation process, especially for complex cases involving deviations or groupings.
    *   Solicited feedback on formalizing example integration into the IETF process.

## Decisions and Action Items

*   **Decision:** The `6991-bis` draft will be published *as is*.
*   **Decision:** The `Semver` draft's requirement for YANG module file names will change from "may publish" to "must publish" both file names.
*   **Action Item:** Mahesh Jethanandani (AD) to ensure the `Semver` draft's Shepard's report (Question 13) is updated with justification for having more than five authors.
*   **Action Item:** Mahesh Jethanandani (AD) to ensure the Datatracker state for `Semver` is updated to reflect that a revised ID is needed for the "may" to "must" file name change.
*   **Action Item:** Chin Wu will quickly follow up after the meeting to make a revision for the `immutable-flag` draft.
*   **Action Item:** Co-chairs, with Charles Eccle's help, will craft a response to the 3GPP liaison clarifying the working group's stance and encouraging direct participation.
*   **Action Item:** Joe Clark to continue work on YANG versioning tooling, including adding `recommended-min-date` checks to Pyang, merging changes upstream, and working with the tools team on Datatracker integration (e.g., Libyang packaging).
*   **Action Item:** Joe Clark to write Markdown documentation on the new YANG versioning tooling for increased awareness among authors.
*   **Action Item:** Ivan will collaborate with Joe Clark on pushing Libyang updates to Debian upstream.

## Next Steps

*   **MAC Address Definition:** A draft will be developed to address the IEEE/IETF MAC address definition conflict for discussion at the next meeting.
*   **YANG Packages:** The working group will resume regular Tuesday meetings on the packages draft, continue progress on tooling (including open-sourcing the Libyang implementation), and conduct more testing. The IANA update guidelines draft is expected soon.
*   **YANG Versioning Tooling:** The community is encouraged to test Joe Clark's updated tools (links provided in slides) and provide feedback. Further discussions will explore process changes for shepherds and ID Nits integration to automate versioning checks.
*   **YANG Push Validation:** Further investigation is needed into subtree validation within `anydata` and how to implement the optionality of the validation mechanism.
*   **YANG Example Validation:** The working group will consider how to formalize the integration, extraction, and validation of examples in IETF documentation.
*   **General Participation:** A continued plea for additional contributors, especially for the YANG packages and version selection drafts, was made.