**Session Date/Time:** 17 Jan 2023 15:00

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

## Summary

This LPWAN session focused on reviewing the re-chartering text, discussing minor updates to the `CHIC YANG Data Model` (RFC 9037), and initiating a discussion on access control mechanisms for CHIC rules. Key administrative issues regarding agenda links were addressed. The working group also reviewed the status of documents currently with the RFC Editor.

## Key Discussion Points

*   **Administrative and Logistics**
    *   A typo in the session agenda URL (`lp1-2` vs `lp1-02`) was identified and corrected. Note-takers were requested to use the correct `lp1-02` page.
    *   The IETF Note Well was presented, covering IPR, anti-harassment policy, and the ombuds team.

*   **Document Status Updates**
    *   **`CHIC YANG Data Model` (RFC 9037)**: Laurens noted potential tool compatibility issues with the `union` type for `field-length` (identity vs. integer). These are minor technical changes, not affecting compatibility, and will be addressed during the RFC 48 phase. Proposed a new identity for CoAP options (`feed-CoAP-option`) for clearer identification.
    *   **`NBIoT`**: Awaiting comments from the RFC Editor. No new updates since the last meeting.
    *   **`CoAP Compound Arc`**: Alex reported a minor editorial fix regarding line length is pending from Sergio.
    *   **`Sigfox`**: Sergio needs to provide a reference in the text to address a blocking comment from Roman Danyliw.

*   **Re-chartering Discussion**
    *   The proposed re-chartering text was reviewed, with specific attention to the "background" section (which will be an envelope for the charter, not part of the contract).
    *   Discussion around the first sentence of the charter: Eric suggested modifying "will extend its scope" to reflect the new scope as the current one.
    *   **Scope Expansion**:
        *   Edgar proposed including "Zero Energy / Scavenging Devices" and "Delay Tolerant Transmissions" as a new use case for CHIC, particularly in relation to adapting IP transmission and managing configuration, timers, and fragmentation for such devices.
        *   There was agreement that this is an important area, especially concerning fragmentation and potentially adjusting operational parameters (e.g., timers) rather than changing the core CHIC protocol itself. Pascal suggested that the first bullet point in the current charter (adapting compression and fragmentation) could cover this, but explicit mention would be beneficial.
        *   A proposed sentence to be added to the charter text was: "The WG will work on new profiles that enable CHIC benefits for extremely constrained devices that may not have always-on power sources (e.g., zero-energy/scavenging devices) or devices operating with very long delays between transmissions." (Slightly rephrased for minutes).
    *   **Explicit mentions for FEC and protocol lists**:
        *   The re-chartering text explicitly lists "FEC for fragments" as a reliability mechanism within the scope of fragmentation, which was previously implicit.
        *   Carsten raised a concern about listing specific protocols (e.g., TCP, IPv4, OAM, LoRaWAN) in the charter itself, citing the "expressio unius est exclusio alterius" principle (mentioning some implies exclusion of others). He suggested such specific items should be in Milestones rather than the generic charter text.
        *   The Area Director (AD) concurred, advising the working group to focus on the topics they want to work on (e.g., "CHIC profiles for specific higher-layer protocols") and the AD/ISG will handle the precise wording and placement (e.g., in milestones) during the review process. The AD indicated that an "open bar" approach (not listing any examples) might be too broad for the ISG.
        *   A poll of the room indicated no other specific protocols or topics that the group wished to add to the list.

*   **YANG Data Model Tweaks (Laurens)**
    *   Laurens presented an issue with the `union` type used for `field-length` in the current CHIC YANG model. Tools for YANG often expect integers within a `union` to be represented as strings in JSON/XML, which is counter-intuitive for integers.
    *   He proposed moving the `union` definition from a `typedef` directly into the `compression` structure. This change is minor, does not affect data compatibility, and simplifies tool implementation and validation.
    *   Additionally, Laurens suggested creating a new identity `feed-CoAP-option` to better categorize CoAP option fields within the data model.
    *   These changes are intended to be incorporated during the RFC 48 phase of the document.
    *   Carsten asked about including "Raw On The Wire" fields for CoAP options, but Laurens indicated this would be a more significant change, better suited for a future version or separate discussion.

*   **Access Control for Rules (Laurens)**
    *   Laurens introduced the need for fine-grained access control to CHIC rules. Currently, all fields are implicitly read-write, and there's no mechanism to restrict who can modify specific parts of a rule, or add/delete rules/entries.
    *   The goal is to allow control over individual rule entries (e.g., preventing changes to source address or CoAP URI) and broader operations like adding or deleting rules.
    *   For fragmentation rules, Laurens suggested limiting changeable parameters to things like timers or the number of fragments, to avoid excessive complexity in implementation.
    *   **Discussion on Use Cases and Attack Vectors**:
        *   Carsten expressed concern that fine-grained access control could lead to "chaos" if multiple entities could modify parts of a rule. He suggested rules are typically managed wholesale by one entity.
        *   Pascal raised the potential for attack vectors, such as an attacker creating a new rule similar to an existing one to divert traffic. He asked how rule precedence or matching logic would handle such conflicts.
        *   Eric suggested starting by documenting envisioned use cases and possible attack vectors. This would help determine the necessary granularity of access control (e.g., an Access Control List (ACL)).
        *   Anna mentioned that the definition of "context" (within which rules live) might already provide some level of access control.
    *   The general sense was that a dedicated discussion on concrete use cases and threat models is needed before defining a specific access control solution.

## Decisions and Action Items

*   Laurens' proposed tweaks to the CHIC YANG Data Model (union type for `field-length`, new CoAP option identity) will be incorporated during the RFC 48 phase of RFC 9037.
*   The re-chartering text will be updated to explicitly include "Zero Energy / Scavenging Devices" and "Delay Tolerant Transmissions" use cases, with a focus on their impact on fragmentation and operational parameters.
*   The re-chartering text will explicitly mention "FEC for fragments" as a reliability mechanism.
*   Laurens will start a new draft to describe the use cases and potential attack vectors for access control of CHIC rules.

## Next Steps

*   Laurens to begin work on the draft for access control use cases and attack vectors.
*   Continued discussion on the re-chartering proposal, with focus on refining the scope text for the ISG review.
*   Await updates from Sergio for the `CoAP Compound Arc` and `Sigfox` documents.
*   Mailing list discussions on the proposed access control use cases and the re-chartering text are encouraged.