**Session Date/Time:** 08 Mar 2022 15:00

# [LPWAN](../wg/lpwan.html)

## Summary

This interim meeting of the LPWAN Working Group focused on two main technical discussions: the ongoing Last Call for the YANG Data Model draft and a continuing debate regarding the interpretation and application of "Device" (Dev) and "Application" (App) roles in SCHC, particularly in peer-to-peer and multi-hop network scenarios. The meeting also included a shepherd review of the Compound ACK draft, leading to specific action items for its publication. Administrative items for IETF 113 were also covered.

## Key Discussion Points

*   **YANG Data Model Working Group Last Call (WGLC):** The WGLC for the YANG Data Model draft is underway, having run for approximately one week. There have been no reviews posted to the mailing list yet. The working group chairs emphasized the importance of reviews, even partial ones, to ensure completeness and correctness of the model. Pascal is the shepherd for this document.
*   **Dev and App Role Discussion:**
    *   **Context:** The existing SCHC framework defines "Dev" (constrained device) and "App" (network-side application server) roles for compression and decompression. The discussion centered on how these roles apply in peer-to-peer (P2P) mesh networks (e.g., IEEE 802.15.4) where both communicating endpoints are constrained devices and would conventionally be considered "Dev."
    *   **Problem Statement:** In such symmetric P2P scenarios, it is unclear which endpoint assumes the "Dev" role and which assumes the "App" role, as the compression and decompression rules are expressed in terms of these roles.
    *   **Proposed Solutions & Feedback:**
        *   **New Roles (e.g., Source/Destination):** An initial proposal in a related 6lo over 6f draft was to define new "Source" and "Destination" roles. However, feedback from the LPWAN WG preferred sticking to the existing "Dev" and "App" roles to maximize reuse of SCHC functionality.
        *   **Overloading Dev/App:** Suggestion to overload the meaning of Dev/App to represent sender/receiver dynamically per packet, or to use a more generic "North/South" concept.
        *   **Symmetric Rules:** It was noted that rules would need to be highly symmetrical to work in both directions for P2P traffic. The existing `direction indicator 'B'` in SCHC rules already supports bidirectional use.
        *   **OpenSCHC Implementation:** The OpenSCHC implementation uses a `device ID` associated with a rule, where for the "App" role, this ID refers to the other end of the communication, providing a mechanism for distinction.
    *   **Multi-hop Considerations:** The discussion extended to multi-hop (route-over) networks where intermediate nodes might need to decompress headers. This significantly increases complexity, as intermediate nodes would need to manage roles or rules for multiple endpoint pairs. The consensus was that applying SCHC compression to IP headers in multi-hop scenarios is overly complex and might not be advisable. It was recommended to focus on SCHC for upper layer compression in multi-hop, or to use tunneling/label switching if IP compression is required over multiple hops.
*   **Compound ACK Shepherd Review:** Pascal presented his shepherd review of the Compound ACK draft. Key points raised included:
    *   The document must explicitly state that it "updates RFC 8724" in its RFC tag, Abstract, and Introduction, with a small section explaining the nature of the update.
    *   Clarification on the placement of Window Number 0 in the SCHC Compound Header.
    *   A specific sentence in a diff that appeared as "new" but seemed unchanged needs verification.
    *   Discussion on whether the document clarifies an underspecified behavior in RFC 8724 (e.g., an asynchronous NACK for a missing fragment) rather than introducing entirely new behavior. If so, this clarification should be explicitly documented as an update applicable to existing RFC 8724 implementations.

## Decisions and Action Items

*   **YANG Data Model WGLC:** All working group participants are urged to review the YANG Data Model draft and submit comments to the mailing list.
*   **Dev and App Roles:** Laura (and potentially other interested parties) to initiate a discussion on the mailing list to precisely define "Dev" and "App" roles, clarify how they differ, and explore how they can be interpreted or adapted for symmetric peer-to-peer communication (e.g., "Dev-to-Dev" scenarios). The architecture draft should be updated with this clarification.
*   **Compound ACK Draft:**
    *   The draft authors (Carles) are to incorporate the shepherd review comments, specifically:
        *   Add "updates RFC 8724" to the RFC tag, Abstract, and Introduction.
        *   Add a section explaining the nature of the update to RFC 8724.
        *   Clarify the text regarding Window Number 0 placement.
        *   Verify the "new" sentence in the diff.
        *   Add specific wording in the update section to clarify that the asynchronous NACK behavior applies to RFC 8724 without Compound ACK, retrofitting or clarifying expected behavior for existing implementations.
    *   Carles is requested to publish an updated version of the Compound ACK draft on Monday, March 21st, if possible. Pascal offered to review the proposed text before publication.
    *   The chairs will issue the publication request for the Compound ACK draft to the IESG once the updated version is published.
*   **IETF 113 Logistics:**
    *   Laura (on-site chair) is to review the Meetecho session management training materials (provided by Dominic) and utilize test sessions.
    *   All presenters are reminded to use the official slide template and upload slides in advance.
    *   Anna (NB-IoT) to prepare for a 20-minute slot to discuss NB-IoT readiness for WGLC.
    *   Carles to ensure Diego is listed as presenter for the 6lo over 6f slot.

## Next Steps

*   **Mailing List Discussion:** Initiate discussions on the LPWAN mailing list regarding the "Dev" and "App" roles for symmetric communication and multi-hop scenarios.
*   **Document Publication:** Publish the updated Compound ACK draft and proceed with the IESG publication request.
*   **IETF 113 Preparations:** Continue preparing for the IETF 113 meeting, including presentation uploads and logistical coordination.