**Session Date/Time:** 14 May 2024 14:00

# [SCHC](../wg/schc.html)

## Summary

This SCHC inter-meeting focused on two main topics: the progress of the SCHC OEM draft (specifically ICMPv6 compression) and a preliminary discussion on the concept of "set of rules." A key decision was made regarding the OEM draft to separate the generic "action" mechanism into a new, more general document. The discussion on "set of rules" explored how rules are defined, managed, and identified across different technologies and by various actors (manufacturers, device owners, network providers), distinguishing between a broad "set of rules" and an "instantiated context."

## Key Discussion Points

*   **OEM Draft (ICMPv6 Compression)**
    *   The `draft-barthel-schc-oam` (on ICMPv6 compression) is still a personal submission, not yet a working group document.
    *   The draft defines ICMPv6 field compression, introduces new CDAs (e.g., reverse compression, reverse rule match for error messages), and proposes "actions" such as proxy ping.
    *   A significant point of discussion was the "action" concept, with a proposal to extract it from this draft. Anna suggested that "actions" are a more general feature for rule formats (e.g., flow compression, payload compression for Zero Energy Devices) and should reside in a separate document defining such attributes.
    *   There was a consensus to separate the "action" concept from the OEM draft due to its generic nature.
    *   Post-removal of "actions," the document's name needs revision to accurately reflect its scope. Suggestions included "ICMPv6 compression and optimization" or "Static Context Compression for ICMPv6 Protocol," emphasizing its focus on ICMPv6 field compression rather than broader OAM.

*   **Set of Rules Discussion**
    *   Laurent introduced the concept of a "set of rules" as a collection of compression, fragmentation, and management rules defined for a SCHC-enabled object.
    *   Different actors have a view and influence on rules:
        *   **Manufacturer**: Defines initial compression and fragmentation rules based on device protocols and traffic patterns.
        *   **Device Owner**: May modify rules (e.g., application address for server communication).
        *   **Network Provider**: Assigns IP addresses and manages device-specific rules.
        *   **Technology**: Fragmentation rules are highly dependent on the underlying LPWAN technology (e.g., 3GPP, LoRaWAN, Sigfox).
    *   The discussion explored whether a single "set of rules" could encompass different technologies, or if technology-specific rule sets or "profiles" would be necessary. The sense was that a set of rules should typically be tied to a specific technology for fragmentation, with the potential for different rule ID numbering schemes across technologies.
    *   Edgar mentioned a use case in cellular networks for dynamically activating/deactivating fragmentation and adjusting parameters like tile size based on connectivity conditions, indicating a need for flexibility in rule activation.
    *   A distinction was made between a "set of rules" (a downloadable, uninstantiated collection of rules) and a "context" (the active state, including instantiated, technology-specific, and adapted rules, along with runtime state like fragmentation counters). The "context" is what is effectively used by a device pair.
    *   The challenge of "joker values" or placeholders within rules (e.g., IP addresses unknown to the manufacturer) that need to be filled by device owners or network providers during instantiation was highlighted.
    *   Proposals for identifying rule sets included using a structured URI (URL) pointing to a canonical JSON/XML representation, potentially with digital signatures for authentication.
    *   A core point was the distinction between a rule's internal name/identification within a large "set of rules" and the compact Rule ID (e.g., 1, 2, 3) actually transmitted over the air. The Rule ID in the air is context-specific and determined for a particular pair of devices and their active rules subset, potentially allowing for smaller Rule ID sizes for efficiency (e.g., 4 bits for 10 rules vs. 8 bits for 200 rules in a full set).

## Decisions and Action Items

*   **Decision**: The generic "action" concept (e.g., proxy behavior) will be removed from the `draft-barthel-schc-oam` and moved into a new, separate document that defines general rule attributes.
*   **Action Item**: Laurent Barthel will update the OEM/ICMPv6 compression draft to remove the "action" concept.
*   **Action Item**: Laurent Barthel will initiate a new document for generic rule attributes and actions.
*   **Action Item**: The name of the ICMPv6 compression document will be revised to better reflect its specific scope after the removal of the generic "action" features.
*   **Action Item**: Following these updates, a working group adoption call will be initiated for the revised ICMPv6 compression document.

## Next Steps

*   The working group will continue to discuss and define the "set of rules" concept, including its structure, identification mechanisms (URIs), management of "joker values," and the relationship between generic rule sets and instantiated contexts. This discussion may lead to improvements in the architecture document or a new dedicated document/BCP.
*   Further exploration of specific scenarios for rule management and identification across different technologies and operational contexts is needed.