Options representation in SCHC YANG Data Models

2.1. Option Representation Problem

In the current SCHC Data Model defined in [RFC9363], CoAP options are represented as predefined Field Identifiers (FIDs) that are included in SCHC Rules. Each option is essentially abstracted away from its original protocol identifier and assigned a new SCHC-specific identifier. While this approach works adequately in static LPWAN environments where the set of options is known in advance and rarely changes, it creates significant challenges in more dynamic networks or when protocols evolve.¶

The core problem is that the mapping between protocol option identifiers (as defined in the protocol specification) and SCHC FIDs is not standardized or predictable. When a new CoAP option is defined after a SCHC implementation is deployed, there is no straightforward mechanism for the implementation to assign an appropriate FID to this option or to communicate this assignment to other SCHC implementations.¶

2.2. Rule Management Challenges

This limitation becomes particularly problematic in scenarios involving rule management between two SCHC endpoints. The following scenario (cf. Figure 1) illustrates this issue:¶

In this scenario:¶

• Device A generates CoAP packets that may include various options, including newly defined ones.¶

• SCHC nodes S1 and S2 compress and decompress the traffic using Rules they share.¶

• When A uses a newly defined or private option, S1 can parse this option (as the CoAP header structure remains consistent) and could potentially derive a new Rule to optimize compression.¶

• However, S1 faces a critical problem: how to identify this new option in the Rule and communicate this identifier to S2 in a way that S2 can understand which option is involved and correctly reconstruct the header.¶

For example, suppose a Rule defines just a CoAP header, and S1 derives a more specific Rule including a URI-path. The entry shown in Figure 2 can be added to the derived Rule, and [RFC9363] defines appropriate identityref values (respectively fid:coap-option-uri-path, di:up, mo:equal and cda:not-sent) that can be used to communicate this Rule description to S2.¶

However, when A uses a recently defined option or a private option that was not known when the SCHC implementation was created, S1 cannot represent this option using existing FIDs. While S1 can still parse the CoAP header and identify the new option, it has no predefined FID to use in the Rule, as shown in Figure 3, and S2 is unable to find the original option number to reconstruct the header:¶

2.3. Interoperability Consequences

This disconnect between protocol option identifiers and SCHC FIDs creates several interoperability issues:¶

• Limited Protocol Evolution Support: New protocol options cannot be efficiently compressed without updates to the SCHC implementation.¶

• Incompatible Rule Exchanges: Different SCHC implementations may assign different FIDs to the same new option, making Rule exchange between them problematic.¶

• Implementation Complexity: SCHC implementations must maintain complex mappings between protocol options and FIDs, and these mappings may differ between implementations.¶

• Deployment Barriers: Deploying SCHC in environments with evolving protocols becomes difficult and requires frequent updates to SCHC implementations.¶

The fundamental issue is that the protocol option space and the SCHC FID space are disconnected, with no standardized or dynamic mapping between them. This disconnect seriously limits SCHC's applicability in dynamic environments and its ability to adapt to protocol evolution.¶

In the following sections, we introduce two approaches to address this challenge for CoAP. The first approach, called 'semantic,' abstracts away from the byte-level representation and introduces a generic option framework that eliminates the need for mapping between option values and Field IDs. This semantic approach focuses on the logical meaning rather than the protocol-specific encoding. The second approach, termed 'syntactic,' aims to closely align with CoAP's native representation of options by defining three distinct fields: option delta type, option length, and option value. Since many protocols encode their options as a type, a length and a value, this second approach can easily be derived for protocols other than CoAP.¶

3.1. Universal Options

In RFC 9363 [RFC9363], each entry in the compression structure is referenced by a tuple composed of a Field ID (FID), a Direction Indicator (DI) and a position.¶

This keying does not guarantee that entries appear in the same order as the corresponding fields in the header (all the options will appear at the end of the Rule), whereas RFC 8724 [RFC8724] mandates that order and recent implementations have shown it to be efficient. In addition, these three- or four-element keys remain large, which may be a penalty when Rule management is used.¶

RFC 7950 [RFC7950], Section 11, does not allow the "entry" list's key, nor the "field-id" leaf, to be changed in place in a published module ("Otherwise, if the semantics of any previous definition are changed [...] then this MUST be achieved by a new definition with a new identifier"). This document therefore deprecates the whole compression Rule entry structure in favor of a new one, providing a uniform way to reference a field entry. A new "entry-index" leaf is introduced as the key of the new "entry-universal" list. The list is defined as "ordered-by user", and "entry-index" values are assigned sequentially according to the order of the entries in that list. The list order therefore continues to convey the header field order (addressing the second problem).¶

"entry-index" is then followed by a choice between a field-id and a space-id/option-number. The rest of the entry is unchanged, except for the new "field-length-value" leaf, added to carry the argument of a Field Length function.¶

This document therefore leaves the RFC 9363 "compression-rule-entry" grouping, its "compression-content" grouping, and the "compression" case untouched, and marks them "status deprecated;" (RFC 8407 recommends a "deprecated" status be kept for at least one year before moving to "obsolete"). The new structure is defined in a new "compression-rule-entry-universal" grouping, used by a new "compression-content-universal" grouping and a new "compression-universal" case, sitting alongside the deprecated ones in the "nature" choice. The YANG definitions of these groupings are specified in [I-D.toutain-schc-rfc9363bis].¶

Figure 5 shows the resulting YANG tree diagram for both cases (deprecated "compression" and new "compression-universal").¶

x--:(compression) {compression}?
|  x--rw entry* [field-id field-position direction-indicator]
|     +--rw field-id                    fid-type
|     +--rw field-length                union
|     +--rw field-position              uint8
|     +--rw direction-indicator         di-type
|     +--rw target-value* [index]
|     |  +--rw index    uint16
|     |  +--rw value?   binary
|     +--rw matching-operator           mo-type
|     +--rw matching-operator-value* [index]
|     |  +--rw index    uint16
|     |  +--rw value?   binary
|     +--rw comp-decomp-action          cda-type
|     +--rw comp-decomp-action-value* [index]
|        +--rw index    uint16
|        +--rw value?   binary
+--:(compression-universal) {compression or management}?
   +--rw entry-universal* [entry-index]
   |  +--rw entry-index                 uint16
   |  +--rw (field-or-space)
   |  |  +--:(regular-field)
   |  |  |  +--rw field-id              fid-type
   |  |  +--:(universal-option)
   |  |     +--rw space-id              space-id-type
   |  |     +--rw universal-value       uint64
   |  +--rw field-length                union
   |  +--rw field-length-value?         uint16
   |  +--rw field-position              uint8
   |  +--rw direction-indicator         di-type
   |  +--rw target-value* [index]
   |  |  +--rw index    uint16
   |  |  +--rw value?   binary
   |  +--rw matching-operator           mo-type
   |  +--rw matching-operator-value* [index]
   |  |  +--rw index    uint16
   |  |  +--rw value?   binary
   |  +--rw comp-decomp-action          cda-type
   |  +--rw comp-decomp-action-value* [index]
   |     +--rw index    uint16
   |     +--rw value?   binary
   +--rw action?                          action-type
   +--rw action-value* [index]
      +--rw index    uint16
      +--rw value?   binary

Unlike the deprecated "entry" list, keyed by the compound "field-id"/"field-position"/"direction-indicator", "entry-universal" is keyed by the single-leaf "entry-index". This makes an entry cheap and unambiguous to reference from elsewhere within the same Rule, e.g. the "field-length-value" argument of a Field Length function, or a management operation targeting that entry.¶

3.2. Space ID

Several protocols define options: CoAP [RFC7252] is one example, but other protocols define their own options too, each with its own option numbering. An option number is therefore not enough by itself; it must be qualified by the option space, i.e. the protocol it belongs to.¶

To identify these option spaces, this document creates a "space-id-base-type" identity and derives one identity per protocol from it; a "space-id-type" typedef is then created from "space-id-base-type", following the identityref pattern used throughout RFC 9363 (e.g. for "rcs-algorithm-type"). At present, the module only defines one such identity, "space-id-coap", for the CoAP option space; other protocols that define options can add their own "space-id-*" identity the same way. Figure 6 shows this pattern, mirroring how RFC 9363 introduces its own identityref-derived types.¶

identity space-id-base-type {
  base schc:space-field-id-base-type;
  description
    "Base identity for a Universal Option space. Several
     protocols define options (e.g. CoAP); each such protocol
     is identified by an identity derived from this base type.";
}

identity space-id-coap {
  base space-id-base-type;
  description
    "Space ID identifying the CoAP option space.";
  reference
    "RFC 7252 The Constrained Application Protocol (CoAP)";
}

typedef space-id-type {
  type identityref {
    base space-id-base-type;
  }
  description
    "Space ID type for universal option spaces (CoAP options,
     etc.). Used in the universal-option case of
     compression-rule-entry-universal.";
}

"space-id-type" is used, together with "space-id-base-type" and "fid-base-type"'s common ancestor "space-field-id-base-type", by the "field-or-space" choice (see Figure 5).¶

3.3. Deprecating the Per-Option CoAP FIDs

RFC 9363 defines twenty per-option Field IDs deriving from "fid-coap-option", one for each CoAP option registered at the time (see Table 1). Now that Universal Options provide a "space-id-coap"/"universal-value" pair to reference any CoAP option by its option number, without needing a dedicated FID for it, each of these twenty identities is superseded and marked deprecated.¶

RFC 7950 [RFC7950], Section 11, states that "Obsolete definitions MUST NOT be removed from published modules, since their identifiers may still be referenced by other modules": once RFC 9363 is published, these twenty identities can only ever be marked "deprecated" and then "obsolete"; they can never simply disappear from a later revision of the module. RFC 8407 [RFC8407], Section 4.7, further recommends that "an object SHOULD be available for at least one year with a 'deprecated' status before it is changed to 'obsolete'", and that "the status SHOULD NOT be changed from 'current' directly to 'obsolete'": since these twenty identities are "current" in RFC 9363, this document marks them "deprecated" rather than "obsolete".¶

These twenty identities MUST NOT be used in a new "entry-universal" list (Figure 5): the "space-id"/ "universal-value" pair introduced in Section 3.1 supersedes them there. They remain usable only in the deprecated "entry" list, for Rules that already reference them.¶

IANA has allocated the SID range 2550-2949 to the "ietf-schc" module. At the time of writing, no SID file for "ietf-schc" is registered in the IETF YANG-SID Modules registry. No SID from that range is to be allocated to these twenty deprecated identities: a SID "immutably maps to EXACTLY one YANG name", so allocating one to an identity already superseded by Universal Options would waste it permanently, with no way to reclaim it later.¶

The working copy of the module has been corrected accordingly: the twenty identities are present, each with "status deprecated;" (see Figure 7).¶

identity fid-coap-option-uri-path {
  base fid-coap-option;
  status deprecated;
  description
    "CoAP option Uri-Path. Deprecated in favor of Universal
     Options (space-id-coap / universal-value).";
  reference
    "RFC 7252 The Constrained Application Protocol (CoAP)";
}

6.1. Field Length Functions

This is what Section 6 relies on: in the OSCORE Option value, the flag-related fields for OSCORE and KUDOS are distinct and split, so that its length indicator ("fid-coap-option-oscore-flags-n", "fid-coap-option-kudos-x-m") is its own entry; "fl-length-bytes" or "fl-length-bits" can then use that entry's "entry-index" to derive the length of the corresponding Partial IV field. This works directly for OSCORE; Section 6 explains why the same does not hold for KUDOS's Nonce.¶

6.2. Example 1: OSCORE outer header

Figure 9 shows an example SCHC Compression Rule (Rule ID 2, encoded on 5 bits, i.e. "00010") that compresses, in both directions, the outer CoAP header of a CoAP/OSCORE message.¶

The server is located on the Application side and the client on the Device side. In OSCORE, the client's request carries an OSCORE option with the security parameters, while the server's response carries an empty OSCORE option; the Token links the response to its request.¶

The first column is new and not defined in RFC 8724 [RFC8724]: it numbers the entries in the rule. The names in the other columns are the ones defined in the YANG module, without their prefix ("fid-", "fl-", "mo-", "cda-"), for better legibility.¶

This rule uses the new capabilities introduced above:¶

• The Token field's length no longer uses the legacy "fl-token-length" function; instead, "fl-length-bytes" is used, with its parameter set to 2, referring to entry 2, "coap-tkl".¶

• The OSCORE option's content is split into sub-fields. Note that the Flags field is itself split between "coap-option-oscore-flags- flagbits" and "coap-option-oscore-flags-n", the latter carrying the length of the Partial IV field.¶

• The Partial IV length is likewise given by "fl-length-bytes", this time with its parameter set to 8, referring to entry 8, "coap-option-oscore-flags-n".¶

• In the other direction, the OSCORE option is empty and is compressed using a Universal Option, indicating option number 9.¶

TO BE DISCUSSED: the "h" flag is set to 0, meaning the KID Context is normally absent; should entry 10, "coap-option-oscore-kidctx", still appear in the rule in that case? When present, the KID Context value is itself encoded as a length byte followed by the context bytes. Should this document keep it as a single "coap-option-oscore-kidctx" entry of variable length -- which would send that length twice, once through SCHC's own variable-length encoding and once through the length byte already embedded in the OSCORE encoding -- or split it into two entries, a length indicator and the context value, with the latter using "fl-length-bytes" to point to the former?¶

7.1. Example, Non-Byte-Aligned MSB Residue

The case "var_bit" and "fl-variable-bits" actually address is a variable-length field, whose residue needs an explicit length prefix. [I-D.ietf-schc-8824-update] itself has such an example, for the OSCORE "kid" sub-field (entry "coap-option-oscore-kid" in Figure 9, which instead sends it unmatched): Figure 10. "msb(44)" matches the KID's most significant 44 bits against the 6-byte (48-bit) target value; only the remaining 4 bits are sent with "lsb". "var_bit" (this document's "fl-variable-bits") carries that 4-bit length in its residue length prefix; RFC 8824's byte-counted "fl-variable" could not.¶

10.1. Normative References

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/rfc/rfc7950>.

[RFC8724]

Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, <https://www.rfc-editor.org/rfc/rfc8724>.

[RFC9363]

Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, <https://www.rfc-editor.org/rfc/rfc9363>.

10.2. Informative References

[GPC-SPE-207]

GlobalPlatform, "Remote Application Management over CoAP – Amendment M v1.0", n.d., <https://globalplatform.org/specs-library/amendment-m-remote-application-mgmt-over-coap/>.

[I-D.ietf-core-oscore-key-update]

Höglund, R. and M. Tiloca, "Key Update for OSCORE (KUDOS)", Work in Progress, Internet-Draft, draft-ietf-core-oscore-key-update-14, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-core-oscore-key-update-14>.

[I-D.ietf-lpwan-architecture]

Pelov, A., Thubert, P., and A. Minaburo, "LPWAN Static Context Header Compression (SCHC) Architecture", Work in Progress, Internet-Draft, draft-ietf-lpwan-architecture-02, 30 June 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lpwan-architecture-02>.

[I-D.ietf-schc-8824-update]

Tiloca, M., Toutain, L., Martínez, I., and A. Minaburo, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", Work in Progress, Internet-Draft, draft-ietf-schc-8824-update-10, 26 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-8824-update-10>.

[I-D.ietf-schc-icmpv6-compression]

Barthel, D. and L. Toutain, "Static Context Header Compression (SCHC) for the Internet Control Message Protocol (ICMPv6)", Work in Progress, Internet-Draft, draft-ietf-schc-icmpv6-compression-02, 13 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-schc-icmpv6-compression-02>.

[I-D.lampin-lpwan-schc-considerations]

Lampin, Q., "SCHC design and implementation considerations", Work in Progress, Internet-Draft, draft-lampin-lpwan-schc-considerations-00, 10 November 2022, <https://datatracker.ietf.org/doc/html/draft-lampin-lpwan-schc-considerations-00>.

[I-D.toutain-schc-rfc9363bis]

"*** BROKEN REFERENCE ***".

[RFC7641]

Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/rfc/rfc7641>.

[RFC7959]

Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/rfc/rfc7959>.

[RFC7967]

Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/rfc/rfc7967>.

[RFC8407]

Bierman, A., "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", RFC 8407, DOI 10.17487/RFC8407, October 2018, <https://www.rfc-editor.org/rfc/rfc8407>.

[RFC8613]

Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/rfc/rfc8613>.

[RFC8824]

Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, <https://www.rfc-editor.org/rfc/rfc8824>.