CORECONF Rule management for SCHC
draft-toutain-schc-coreconf-management-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ana Minaburo , Laurent Toutain , Javier Alejandro FERNANDEZ , Corentin Banier , Marion Dumay | ||
| Last updated | 2025-10-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-toutain-schc-coreconf-management-01
SCHC Working Group A. Minaburo
Internet-Draft Consultant
Intended status: Standards Track L. Toutain
Expires: 21 April 2026 J.A. Fernandez
C. Banier
IMT Atlantique
M. Dumay
Orange
18 October 2025
CORECONF Rule management for SCHC
draft-toutain-schc-coreconf-management-01
Abstract
This document describes how CORECONF can be applied to SCHC for
context and rule set management between endpoints.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Minaburo, et al. Expires 21 April 2026 [Page 1]
Internet-Draft SCHC for CoAP October 2025
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability statement . . . . . . . . . . . . . . . . . . . 3
2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 3
2.2. CoAP Profile . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Rule modification . . . . . . . . . . . . . . . . . . . . 4
2.4. Rule creation . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Rule deletion . . . . . . . . . . . . . . . . . . . . . . 6
3. Management messages . . . . . . . . . . . . . . . . . . . . . 6
3.1. YANG Data Model . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Management Rule Nature . . . . . . . . . . . . . . . 6
3.1.2. Guard Period . . . . . . . . . . . . . . . . . . . . 6
3.1.3. YANG tree representation . . . . . . . . . . . . . . 6
3.2. Set of Rules Editing . . . . . . . . . . . . . . . . . . 8
3.3. Management Errors . . . . . . . . . . . . . . . . . . . . 8
3.4. CoAP Methods . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1. FETCH . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.2. iPATCH . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.4. Optimizations . . . . . . . . . . . . . . . . . . . . 13
3.5. RPC statements . . . . . . . . . . . . . . . . . . . . . 14
3.5.1. Duplicate Rule . . . . . . . . . . . . . . . . . . . 15
4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Management Compression Rules (M Rules) . . . . . . . . . 17
5. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 21
6. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 21
7. Example CORECONF usage in Python . . . . . . . . . . . . . . 21
7.1. Deletion cases . . . . . . . . . . . . . . . . . . . . . 21
7.2. Update cases . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Addition cases . . . . . . . . . . . . . . . . . . . . . 26
8. Normative References . . . . . . . . . . . . . . . . . . . . 29
Appendix A. YANG DM . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Minaburo, et al. Expires 21 April 2026 [Page 2]
Internet-Draft SCHC for CoAP October 2025
1. Introduction
[RFC9363] defines the YANG Data Model for a SCHC context (a.k.a Set
of Rules, or SoR). [I-D.ietf-lpwan-architecture] proposes the
architecture for rule management. Some rules must be clearly
dedicated to the modification of the context.
[RFC9254] defines a way to serialize data issued from a YANG DM into
a CBOR representation and [I-D.ietf-core-comi] defines the CoAP
interface.
This document describes how CORECONF can be used to manage SCHC
contexts and rule sets within a SCHC instance. It also specifies
SCHC compression rules tailored for the CORECONF-based management
traffic itself. These “management compression rules” improve
efficiency for control and configuration exchanges, distinct from the
compression applied to regular application data.
2. Applicability statement
2.1. Architecture
SCHC instance management allows the two endpoints to modify the
common SoR, by:
* Modifying rules values (such as TV, MO or CDA) in existing rules.
* Adding a new rule.
* Removing an existing rule.
* Triggering Remote Procedural Calls (RPC) within the endpoints.
A new type of traffic is defined called management traffic, which
deals exclusively with message exchanges concerning context and rule
management.
The rule management uses the CORECONF network management interface
[I-D.ietf-core-comi], which is based on CoAP. In this context,
management traffic refers to the CORECONF messages exchanged between
the endpoints to configure or modify rule sets. The management
traffic is transported as SCHC-compressed packets, tagged with
specific Rule IDs. These rules are identified as Management Rules
(or M Rules) in Figure Figure 1. M Rules can be either Compression
Rules or No-Compression Rules. Only M Rules are permitted to modify
the SoR.
Minaburo, et al. Expires 21 April 2026 [Page 3]
Internet-Draft SCHC for CoAP October 2025
The management traffic uses its own IPv6 stack, distinct from regular
application traffic. See Section Section 4 for more details.
SCHC Packets using M Rules MUST be encrypted either by the underlying
layer (for instance in a QUIC stream dedicated to management inside a
QUIC connection) or directly using OSCORE or DTLS.
+-----------------+ +-----------------+
| ^ | | ^ |
| C/D !M ___ | | !M ___ |
| +-[]>[SoR]| ... | +-[]>[SoR]|
| ! [___]| | ! [___]|
| ! | | ! |
| F/R | | F/R |
+------ins_id1----+-----ins_idi-----+------ins_idn----+
. C/D ! M +---+ ___ .
. +------------->|Mng|<=>[SoR] .
. F/R +---+ [___] .
+.................. Discriminator ....................+
Figure 1: Inband Management
2.2. CoAP Profile
Management requests MUST be protected against packet loss. It is
RECOMMENDED to use CONfirmable requests and no Token. If the
management request is too large regarding the MTU, SCHC Fragmentation
SHOULD be used instead of the Block option. As shown in figure
Figure 1 fragmentation can be common to Management rules and other
rules.
2.3. Rule modification
SCHC imposes that both ends share exactly the same SoR, therefore, a
new or modified rule cannot be used while it remains in candidate
status until the other end has validated the modification. A
candidate rule cannot be used, either in C/D or F/R. A SCHC PDU MUST
NOT be generated with a candidate rule ID and received PDUs
containing a candidate rule ID must be dropped.
Minaburo, et al. Expires 21 April 2026 [Page 4]
Internet-Draft SCHC for CoAP October 2025
A X B
X valid | modify Rule x ------| X valid
X candidate |=====================/=====>| X candidate
| /------------ |
---|<======/====================|----
| | / | |
Guard | |<----- | | Guard
v | | v
---| |----
X valid | | X valid
Figure 2: Modifying a rule
Figure 2 illustrates a Rule modification. The left-hand side entity
A wants to make rule x evolve. It send an acknowledged CoAP message
to the other end. Host A change the status of the rule to
“candidate”, indicating that the rule can no longer be used for SCHC
procedures. The receiving entity B, acknowledges the message and
continues to maintain the “candidate” status for a Guard period. At
the reception of the acknowledgement, A set also a Guard period
before rule x becomes valid again.
The Guard period is used to avoid SCHC message with a rule ID to
appear at the other end after a rule modification. The Guard period
appears only once during the rule management and is depends on the
out-of-sequence messages expected between both ends.
2.4. Rule creation
Rule creation do not require a Guard period, and acknowledgement is
RECOMMENDED. Figure Figure 3 gives an example, where the
Acknowledgment is lost. Entity A sends a management message to
create a new rule. Since its a new rule, the Guard period is not set
and the new rule becomes immediately valid on B. The Acknowledgement
does not reach A, so the rule stays in the candidate state, but the
reception of a SCHC PDU carrying the RulE ID X, informs that the
message has been correctly received by B. So X becomes valid in A.
A B
X created |
X candidate |===========================>| X valid
| X==================|
| |
X valid |<---------------------------|
| X |
| |
Figure 3: Modifying a rule
Minaburo, et al. Expires 21 April 2026 [Page 5]
Internet-Draft SCHC for CoAP October 2025
2.5. Rule deletion
After the rule deletion, a Guard period is established. During that
period, a rule with the same ID cannot be created, and SCHC PDU
corrying the Rule ID are dropped.
3. Management messages
3.1. YANG Data Model
CORECONF proposes an interface to manage data structured with a YANG
Data Model. RFC 9363 defines a YANG Data Model for SCHC Rules. SCHC
Instance Management MUST use FETCH to read a rule and iPATCH to
create, modify or delete a rule. In order to accomplish management,
the YANG Data Model has been updated.
3.1.1. Management Rule Nature
M Rules have to be marked in a way that allows quickly identifying
which rules in a SoR are responsible for management. Therefore, a
new “nature-management” type has been defined. This nature is
actually a specialization of “nature-compression” for management
purposes and compression needs to be available and activated to do
management.
3.1.2. Guard Period
To determine if a rule is considered available or not during the
Guard period, a rule needs to have a status which determines if it
can be used. Basically, an available rule MUST associate the key
“rule-status” with the value “status-active”. Conversely, during the
Guard period, “rule-status” MUST be set to “status-candidate”.
3.1.3. YANG tree representation
The YANG tree represents the Rule structure as defined in RFC 9363
with the two updates described above:
module: ietf-schc
+--rw schc
+--rw rule* [rule-id-value rule-id-length]
+--rw rule-id-value uint32
+--rw rule-id-length uint8
+--rw rule-status status-type
+--rw rule-nature nature-type
+--rw (nature)?
+--:(fragmentation) {fragmentation}?
| +--rw fragmentation-mode schc:fragmentation-mode-type
Minaburo, et al. Expires 21 April 2026 [Page 6]
Internet-Draft SCHC for CoAP October 2025
| +--rw l2-word-size? uint8
| +--rw direction schc:di-type
| +--rw dtag-size? uint8
| +--rw w-size? uint8
| +--rw fcn-size uint8
| +--rw rcs-algorithm? rcs-algorithm-type
| +--rw maximum-packet-size? uint16
| +--rw window-size? uint16
| +--rw max-interleaved-frames? uint8
| +--rw inactivity-timer
| | +--rw ticks-duration? uint8
| | +--rw ticks-numbers? uint16
| +--rw retransmission-timer
| | +--rw ticks-duration? uint8
| | +--rw ticks-numbers? uint16
| +--rw max-ack-requests? uint8
| +--rw (mode)?
| +--:(no-ack)
| +--:(ack-always)
| +--:(ack-on-error)
| +--rw tile-size? uint8
| +--rw tile-in-all-1? schc:all-1-data-type
| +--rw ack-behavior? schc:ack-behavior-type
+--:(compression) {compression or management}?
+--rw entry* [field-id field-position direction-indicator]
+--rw field-id schc:fid-type
+--rw field-length union
+--rw field-position uint8
+--rw direction-indicator schc:di-type
+--rw target-value* [index]
| +--rw index uint16
| +--rw value? binary
+--rw matching-operator schc:mo-type
+--rw matching-operator-value* [index]
| +--rw index uint16
| +--rw value? binary
+--rw comp-decomp-action schc:cda-type
+--rw comp-decomp-action-value* [index]
+--rw index uint16
+--rw value? binary
Figure 4: Updated YANG Data Model for CORECONF
Minaburo, et al. Expires 21 April 2026 [Page 7]
Internet-Draft SCHC for CoAP October 2025
3.2. Set of Rules Editing
For clarity reasons, this document will use YANG Identifiers in
quotes instead of SID values. Each entry in the YANG tree has a
corresponding SID number. Each level of the hierarchy is accessible
through one or several keys. For example, to access the hierarchy
under “rule”, “rule-id-value” and “rule-id-length” must be specified.
To access the hierarchy corresponding to a field entry in a
compression rule, “rule-id-value” and “rule-id-length” must be
followed by “field-id”, “field-position” and “direction-indicator”.
Since the TV, MO-value, and CDA-value are stored as lists, “index”
must be added to access a specific element.
Therefore, to access a specific element in a hierarchy, the SID of
this element has to be specified, followed by the keys needed to
access it.
For example, ["target-value/value", 5, 3, "fid-ipv6-version", 1, "di-
bidirectional", 0] is used to access the first value (0) of TV for
the IPv6 Version of Rule 5/3.
3.3. Management Errors
There are different levels of error detection:
* CORECONF Errors: these errors are directly generated at the
CORECONF-managed context level. For instance, retrieving a value
with a wrong key.
* YANG validation errors: the data model does not conform with
constraints such as “must” or “mandatory”. This check is optional,
since it may require a lot of resources on a device.
* SCHC errors: errors on the Data Model that cannot be detected at
the YANG level. For example, the rule numbering does not
correspond to a binary tree.
3.4. CoAP Methods
3.4.1. FETCH
As mentioned in [I-D.ietf-core-comi], FETCH requests are used to
retrieve at least one instance-value.
Example: Fetching TV, MO and CDA of the Entry fid-ipv6-version/1/
bidirectional from Rule 6/3.
Minaburo, et al. Expires 21 April 2026 [Page 8]
Internet-Draft SCHC for CoAP October 2025
REQ: FETCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
["target-value", 6, 3, "fid-ipv6-version", 1, "di-bidirectional"],
["matching-operator", 6, 3, "fid-ipv6-version", 1, "di-bidirectional"],
["comp-decomp-action", 6, 3, "fid-ipv6-version", 1, "di-bidirectional"]
RES: 2.05 Content
(Content-Format: application/yang-instances+cbor-seq)
{
{"target-value" : [{"index" : 0, "value" : h"06"}]},
{"matching-operator" : "mo-equal"},
{"comp-decomp-action" : "cda-not-sent"}
}
3.4.2. iPATCH
Several payload formats can be used in a CoAP iPATCH request to
modify SCHC rule parameters. For example, when a field entry in Rule
7/8 is configured as ignore/value-sent and no target value has been
defined, the following iPATCH request payload sets a new Target Value
(TV) and updates the corresponding Matching Operator (MO) and
Compression/Decompression Action (CDA):
iPATCH /c
{
["target-value", 7, 8, field, 1, "di-bidirectional"] : [{delta_TV: 0, delta_value: value}],
["matching-operator", 7, 8, field, 1, "bi-directional"] : "mo-equal",
["comp-decomp-action", 7, 8, field, 1, "bi-directional"] : "cda-not-sent"
}
It is possible to represent each field update as a separate entry in
the payload, as shown above. However, when the modifications apply
to elements of the same subtree, it is RECOMMENDED to group them
within a single structure inside the iPATCH request payload, as shown
below:
iPATCH /c
{
["entry", 7, 8, field, 1, "di-bidirectional"] : {
delta_target-value : [{delta_index : 0, delta_value : value}],
delta_matching-operator : "mo-equal",
delta_comp-decomp-action : "cda-not-sent"
}
}
Both payload formats are valid encodings for a CoAP iPATCH request.
The interpretation and application of the modifications are
implementation-specific.
Minaburo, et al. Expires 21 April 2026 [Page 9]
Internet-Draft SCHC for CoAP October 2025
The same approach applies to rule updates and YANG leaf-list objects,
where multiple related modifications may be grouped within a single
iPATCH request.
3.4.2.1. Adding an element
If the target object, field, or entry does not exist in the SCHC
context, it is added. It supports two main cases:
* Adding a new key-value pair to an existing object.
* Adding a new object to an existing list.
When adding a new element to a YANG leaf-list in the SCHC context,
the model requires that each list index be strictly incremental.
CORECONF does not enforce this automatically; it relies on the client
or system to provide correctly ordered indices.
Example: Add TV into fid-ipv6-payload-length/1/di-bidirectional in
Rule 0/3
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["target-value", 0, 3, "fid-ipv6-payload-length", 1, "di-bidirectional"] : [
{delta_index : 0, delta_value : h"50"},
{delta_index : 1, delta_value : h"55"}
]
}
RES: 2.04 Changed
3.4.2.2. Modify an element
If the target object, field, or entry does exist in the SCHC context,
it is updated.
Examples:
* The Entry fid-ipv6-version/1/di-bidirectional is in Rule 6/3.
Minaburo, et al. Expires 21 April 2026 [Page 10]
Internet-Draft SCHC for CoAP October 2025
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["entry", 6, 3, "fid-ipv6-version", 1, "di-bidirectional"] : {
{"delta_target-value": []},
{"delta_matching-operator": "mo-ignore"},
{"delta_comp-decomp-action": "cda-value-sent"}
}
}
RES: 2.04 Changed
* The Entry fid-ipv6-version/1/di-bidirectional is in not in Rule
7/8 but Rule 7/8 exist.
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["entry", 7, 8, "fid-ipv6-version", 1, "di-bidirectional"] : {
{"delta_target-value" : []},
{"delta_matching-operator" : "mo-ignore"},
{"delta_comp-decomp-action" : "cda-value-sent"}
}
}
RES: 2.04 Changed
* The Entry fid-ipv6-version/1/di-bidirectional is not in Rule 5/8,
and Rule 5/8 does not exist. Therefore, Rule 5/8 cannot be added
in order to include the Entry fid-ipv6-version/1/di-bidirectional
because other fields, which are not keys, cannot be deducted at
every depth of the context.
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["entry", 5, 8, "fid-ipv6-version", 1, "di-bidirectional"] : {
{"delta_target-value" : []},
{"delta_matching-operator" : "mo-ignore"},
{"delta_comp-decomp-action" : "cda-value-sent"}
}
}
RES: 4.04 Not Found
Minaburo, et al. Expires 21 April 2026 [Page 11]
Internet-Draft SCHC for CoAP October 2025
3.4.2.3. Delete an element
If the specified value in the request is “null”, it deletes an
object, field, or entry from the SCHC context
Example:
* Delete Rule 7/8
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["rule", 7, 8]: null
}
RES: 2.04 Changed
When deleting objects in the SCHC context via iPATCH, the operation
is restricted to prevent removal of required structural elements.
Deleting the top-level object (ietf-schc:schc) does not remove it
entirely; instead, the object is reset to a minimal representation:
{"ietf-schc:schc": {"rule": []}}
This ensures the SCHC context remains structurally valid. Updates to
existing objects are generally allowed, but deletion of protected
keys is forbidden.
Example: Delete rule-id-value of Rule 0/3
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
{
["rule-id-value", 0, 3]: null
}
RES: 4.00 Bad Request
3.4.3. POST
As described in [I-D.ietf-core-comi], the POST CoAP method is used to
trigger Remote Procedure Calls (RPC) and other actions within a SCHC
endpoint. Thus, a POST message can be sent to invoke a specific RPC
on the remote endpoint. Details of the supported RPCs and their
behavior are defined in Section Section 3.5.
Minaburo, et al. Expires 21 April 2026 [Page 12]
Internet-Draft SCHC for CoAP October 2025
RPCs and actions are defined in a YANG Data Model with optional
associated inputs and outputs, The request payload contains the RPC
input map, if any. The response payload contains the corresponding
output map, if any.
3.4.4. Optimizations
Two optimizations are possible: first, deriving rules to avoid
sending the full object; second, using universal option indexing for
fine-grained field updates.
3.4.4.1. Derive-from-existing-rule optimization
When sending SCHC rules in iPATCH messages, the naive approach is to
include the full rule object in the payload, even if only a few
fields need to be updated. This can be inefficient, especially in
constrained environments. To reduce the amount of data transmitted,
an optimization consists in deriving a new rule from an existing one
and specifying only the fields that are changing.
Therefore, for adding new rules, the RECOMMENDED method is to use the
duplicate-rule RPC, defined in Section Section 3.5.1, which
implements this derivation mechanism efficiently.
3.4.4.2. Universal-options optimization
The data model for universal options
[I-D.toutain-schc-universal-option] augments SCHC compression rules
with a structured format for protocol options. Each entry is indexed
by:
* a space-id, referring to the protocol containing the option (e.g.,
CoAP, QUIC, TCP),
* the option itself, and
* the position of the field within the protocol header.
Minaburo, et al. Expires 21 April 2026 [Page 13]
Internet-Draft SCHC for CoAP October 2025
+--rw schc-opt:entry-option-space* \
[space-id option-value field-position direction-indicator]
+--rw schc-opt:space-id space-type
+--rw schc-opt:option-value uint32
+--rw schc-opt:field-length union
+--rw schc-opt:field-position uint8
+--rw schc-opt:direction-indicator schc:di-type
+--rw schc-opt:target-value* [index]
| +--rw schc-opt:index uint16
| +--rw schc-opt:value? binary
+--rw schc-opt:matching-operator schc:mo-type
+--rw schc-opt:matching-operator-value* [index]
| +--rw schc-opt:index uint16
| +--rw schc-opt:value? binary
+--rw schc-opt:comp-decomp-action schc:cda-type
+--rw schc-opt:comp-decomp-action-value* [index]
+--rw schc-opt:index uint16
+--rw schc-opt:value? binary
In the CORECONF representation, even though the structural names may
resemble each other, the SID values differ. Each entry key consists
of four elements, enabling precise referencing of individual protocol
fields and allowing efficient selective field-level updates without
touching the rest of the rule.
REQ: FETCH </c>
(Content-Format: application/yang-identifiers+cbor-seq)
["schc-opt:matching-operator", 8, 3, "schc-opt:space-id-coap", 11, 1, "di-up"]
3.5. RPC statements
A YANG “RPC” is an operation that may be invoked within a SCHC
endpoint and triggers a specified behavior. Within the context of
rule management, RPCs are used to perform actions on the set of rules
and may also be used for other operations, such as rebooting the
remote device endpoint.
Each RPC resource has specific inputs and outputs, and may be invoked
remotely via a POST CoAP message, as described in
Section Section 3.4.3.
Minaburo, et al. Expires 21 April 2026 [Page 14]
Internet-Draft SCHC for CoAP October 2025
3.5.1. Duplicate Rule
To add a new rule, instead of using the iPATCH method with a full
rule definition (especially when the new rule is similar to an
existing one), the RECOMMENDED approach is to use the duplicate-rule
RPC. This operation copies an existing rule (“from”) into a new rule
(“to”), and can optionally include an iPATCH sequence specifying
modifications to apply to the duplicated rule. The output returns a
status string conveying the result of the operation.
Represented as a tree:
rpcs:
+---x duplicate-rule
+---w input
| +---w from
| | +---w rule-id-value uint32
| | +---w rule-id-length uint8
| +---w to
| | +---w rule-id-value uint32
| | +---w rule-id-length uint8
| +---w ipatch-sequence? binary
+--ro output
+--ro status? string
This mechanism reduces management overhead and addresses the isue of
adapting to variable application traffic. For example, a SCHC
instance may begin with a generic rule with low compression rate, but
progressively make rule duplications to make more specialized rules
that better match the observed traffic patterns, acheiving higher
compression rates and thus adapting the rule set dynamically to the
session characteristics.
To maintain consistent rule indexing and enable efficient rule
matching, newly created rules SHOULD follow a binary tree structure.
For instance, a rule identified as 8/4 may be duplicated as either
8/5 or 18/5, thereby extending the rule identifier by one bit.
Example:
* Representation with identifiers for clarity. Delta-encoded SIDs
are used in a real request.
Minaburo, et al. Expires 21 April 2026 [Page 15]
Internet-Draft SCHC for CoAP October 2025
REQ: POST </c>
(Content-Format: application/yang-instances+cbor-seq)
{
"/ietf-schc:duplicate-rule":
{
"input/from/rule-id-value": 8,
"input/from/rule-id-length": 4,
"input/to/rule-id-value": 7,
"input/to/rule-id-length": 4,
"input/ipatch-sequence":
[
"/ietf-schc:schc/rule/entry/target-value/value", 8, 5,
"fid-coap-mid", 1, "di-bidirectional", 0,
]: "FAA="
}
}
RES: 2.04 Changed
(Content-Format: application/yang-instances+cbor-seq)
{
"/ietf-schc:duplicate-rule":
{
"output/status": "success",
}
}
3.5.1.1. Error Handling
The duplicate-rule operation SHALL be atomic. If an error occurs
during either stage of the process (rule duplication or subsequent
modification through the iPATCH sequence) the SCHC endpoint MUST
revert any partial changes to restore the previous state. The RPC
output MUST indicate the failure, for example with an error status
such as Bad Request, to signal that the duplication did not take
place as requested. The precise error code and diagnostic message
are implementation-dependent but SHOULD provide enough context for
the management entity to identify the cause of failure.
4. Protocol Stack
The management inside the instance has its own IPv6 stack,
independent of the application traffic. IPv6/UDP/CoAP is used to
allow the implementation of the CORECONF interface. No other kind of
traffic is allowed.
Minaburo, et al. Expires 21 April 2026 [Page 16]
Internet-Draft SCHC for CoAP October 2025
The end-point acting as a Device has the IPv6 address fe80::1/64 and
the other end, the Core, is assigned the address fe80::2/64.
Both endpoints implement CoAP client and server capabilities, that
is, both endpoints are capable of sending requests and processing
responses. The server uses port 5683 and the client 3865.
4.1. Management Compression Rules (M Rules)
To enable CORECONF-based context and rule management over SCHC, a set
of dedicated management rules, identified as M rules, is defined.
These rules are used exclusively for management traffic, that is,
packets exchanged between SCHC endpoints for the purpose of managing
rules, not for application data transfer.
This specification introduces four rules, allowing bidirectional
operation and fine control over management capabilities. Each rule
defines the compression behavior for management messages in its
direction, distinguishing between requests and responses.
* M1: Handles packets containing a payload (e.g., CoAP requests or
Content responses) in one direction (Uplink).
* M2: Handles packets without a payload (e.g., CoAP responses) in
the same direction (Uplink).
* M3: Mirrors M1 in the opposite direction (Downlink), for payload-
bearing management messages.
* M4: Mirrors M2 in the opposite direction (Downlink), for
payloadless messages.
Implementations MAY choose to support only a subset of these rules,
depending on their operational or security requirements. For
instance, an implementation may include only M3 and M4 to permit
management operations exclusively from one endpoint, effectively
preventing unsolicited management requests in the other direction.
In this sense, the absence of certain M rules in the SoR implicitly
acts as a policy mechanism or safeguard for rule management
operations.
M rules are protected elements within the SoR. They define the
operation of the management channel itself and therefore MUST NOT be
modified, duplicated, or deleted through CORECONF operations. Any
attempt to apply a modification or duplication request to an M rule
MUST result in an Unauthorized error response. This restriction
ensures the integrity and stability of the SCHC management process.
Minaburo, et al. Expires 21 April 2026 [Page 17]
Internet-Draft SCHC for CoAP October 2025
+-------------------------------------------------------------------+
|RuleID M1 |
+-------------------+--+--+--+-----------+-------------+------------+
| FID |FL|FP|DI| TV | MO | CDA |
+-------------------+--+--+--+-----------+-------------+------------+
|IPv6 Version |4 |1 |Bi|6 |equal |not-sent |
|IPv6 Traffic Class |8 |1 |Bi|1 |equal |not-sent |
|IPv6 Flow Label |20|1 |Bi|144470 |equal |not-sent |
|IPv6 Length |16|1 |Bi| |ignore |compute-* |
|IPv6 Next Header |8 |1 |Bi|17 |equal |not-sent |
|IPv6 Hop Limit |8 |1 |Bi|64 |equal |not-sent |
|IPv6 DevPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 DevIID |64|1 |Bi|::2 |equal |not-sent |
|IPv6 AppPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 AppIID |64|1 |Bi|::1 |equal |not-sent |
+===================+==+==+==+===========+=============+============+
|UDP DevPort |16|1 |Bi|3865 |equal |not-sent |
|UDP AppPort |16|1 |Bi|5683 |equal |not-sent |
|UDP Length |16|1 |Bi| |ignore |compute-* |
|UDP Checksum |16|1 |Bi| |ignore |compute-* |
+===================+==+==+==+===========+=============+============+
|CoAP Version |2 |1 |Bi|1 |equal |not-sent |
|CoAP Type |2 |1 |Dw|2 |equal |not-sent |
|CoAP Type |2 |1 |Up|0 |equal |not-sent |
|CoAP TKL |4 |1 |Bi|0 |equal |not-sent |
|CoAP Code |8 |1 |Up|[2, 5, 7] |match-mapping|mapping-sent|
|CoAP Code |8 |1 |Dw|69 |equal |not-sent |
|CoAP MID |16|1 |Bi|0 |MSB(9) |LSB |
|CoAP Uri-Path |8 |1 |Bi|c |equal |not-sent |
|CoAP Content-Format|8 |1 |Bi|application|equal |not-sent |
| | | | |/yang-ident| | |
| | | | |fiers+cbor-| | |
| | | | |seq | | |
+===================+==+==+==+===========+=============+============+
Figure 5: Management Rule 1
Minaburo, et al. Expires 21 April 2026 [Page 18]
Internet-Draft SCHC for CoAP October 2025
+----------------------------------------------------------------------+
|RuleID M2 |
+-------------------+--+--+--+--------------+-------------+------------+
| FID |FL|FP|DI| TV | MO | CDA |
+-------------------+--+--+--+--------------+-------------+------------+
|IPv6 Version |4 |1 |Bi|6 |equal |not-sent |
|IPv6 Traffic Class |8 |1 |Bi|1 |equal |not-sent |
|IPv6 Flow Label |20|1 |Bi|144470 |equal |not-sent |
|IPv6 Length |16|1 |Bi| |ignore |compute-* |
|IPv6 Next Header |8 |1 |Bi|17 |equal |not-sent |
|IPv6 Hop Limit |8 |1 |Bi|64 |equal |not-sent |
|IPv6 DevPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 DevIID |64|1 |Bi|::2 |equal |not-sent |
|IPv6 AppPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 AppIID |64|1 |Bi|::1 |equal |not-sent |
+===================+==+==+==+==============+=============+============+
|UDP DevPort |16|1 |Bi|3865 |equal |not-sent |
|UDP AppPort |16|1 |Bi|5683 |equal |not-sent |
|UDP Length |16|1 |Bi| |ignore |compute-* |
|UDP Checksum |16|1 |Bi| |ignore |compute-* |
+===================+==+==+==+==============+=============+============+
|CoAP Version |2 |1 |Bi|1 |equal |not-sent |
|CoAP Type |2 |1 |Dw|2 |equal |not-sent |
|CoAP TKL |4 |1 |Bi|0 |equal |not-sent |
|CoAP Code |8 |1 |Dw|[68, 128, 129,|match-mapping|mapping-sent|
| | | | | 132, 160] | | |
|CoAP MID |16|1 |Bi|0 |MSB(9) |LSB |
+===================+==+==+==+==============+=============+============+
Figure 6: Management Rule 2
Minaburo, et al. Expires 21 April 2026 [Page 19]
Internet-Draft SCHC for CoAP October 2025
+-------------------------------------------------------------------+
|RuleID M3 |
+-------------------+--+--+--+-----------+-------------+------------+
| FID |FL|FP|DI| TV | MO | CDA |
+-------------------+--+--+--+-----------+-------------+------------+
|IPv6 Version |4 |1 |Bi|6 |equal |not-sent |
|IPv6 Traffic Class |8 |1 |Bi|1 |equal |not-sent |
|IPv6 Flow Label |20|1 |Bi|144470 |equal |not-sent |
|IPv6 Length |16|1 |Bi| |ignore |compute-* |
|IPv6 Next Header |8 |1 |Bi|17 |equal |not-sent |
|IPv6 Hop Limit |8 |1 |Bi|64 |equal |not-sent |
|IPv6 DevPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 DevIID |64|1 |Bi|::2 |equal |not-sent |
|IPv6 AppPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 AppIID |64|1 |Bi|::1 |equal |not-sent |
+===================+==+==+==+===========+=============+============+
|UDP DevPort |16|1 |Bi|3865 |equal |not-sent |
|UDP AppPort |16|1 |Bi|5683 |equal |not-sent |
|UDP Length |16|1 |Bi| |ignore |compute-* |
|UDP Checksum |16|1 |Bi| |ignore |compute-* |
+===================+==+==+==+===========+=============+============+
|CoAP Version |2 |1 |Bi|1 |equal |not-sent |
|CoAP Type |2 |1 |Up|2 |equal |not-sent |
|CoAP Type |2 |1 |Dw|0 |equal |not-sent |
|CoAP TKL |4 |1 |Bi|0 |equal |not-sent |
|CoAP Code |8 |1 |Dw|[2, 5, 7] |match-mapping|mapping-sent|
|CoAP Code |8 |1 |Up|69 |equal |not-sent |
|CoAP MID |16|1 |Bi|0 |MSB(9) |LSB |
|CoAP Uri-Path |8 |1 |Bi|c |equal |not-sent |
|CoAP Content-Format|8 |1 |Bi|application|equal |not-sent |
| | | | |/yang-ident| | |
| | | | |fiers+cbor-| | |
| | | | |seq | | |
+===================+==+==+==+===========+=============+============+
Figure 7: Management Rule 3
Minaburo, et al. Expires 21 April 2026 [Page 20]
Internet-Draft SCHC for CoAP October 2025
+----------------------------------------------------------------------+
|RuleID M4 |
+-------------------+--+--+--+--------------+-------------+------------+
| FID |FL|FP|DI| TV | MO | CDA |
+-------------------+--+--+--+--------------+-------------+------------+
|IPv6 Version |4 |1 |Bi|6 |equal |not-sent |
|IPv6 Traffic Class |8 |1 |Bi|1 |equal |not-sent |
|IPv6 Flow Label |20|1 |Bi|144470 |equal |not-sent |
|IPv6 Length |16|1 |Bi| |ignore |compute-* |
|IPv6 Next Header |8 |1 |Bi|17 |equal |not-sent |
|IPv6 Hop Limit |8 |1 |Bi|64 |equal |not-sent |
|IPv6 DevPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 DevIID |64|1 |Bi|::2 |equal |not-sent |
|IPv6 AppPrefix |64|1 |Bi|fe80::/64 |equal |not-sent |
|IPv6 AppIID |64|1 |Bi|::1 |equal |not-sent |
+===================+==+==+==+==============+=============+============+
|UDP DevPort |16|1 |Bi|3865 |equal |not-sent |
|UDP AppPort |16|1 |Bi|5683 |equal |not-sent |
|UDP Length |16|1 |Bi| |ignore |compute-* |
|UDP Checksum |16|1 |Bi| |ignore |compute-* |
+===================+==+==+==+==============+=============+============+
|CoAP Version |2 |1 |Bi|1 |equal |not-sent |
|CoAP Type |2 |1 |Up|2 |equal |not-sent |
|CoAP TKL |4 |1 |Bi|0 |equal |not-sent |
|CoAP Code |8 |1 |Up|[68, 128, 129,|match-mapping|mapping-sent|
| | | | | 132, 160] | | |
|CoAP MID |16|1 |Bi|0 |MSB(9) |LSB |
+===================+==+==+==+==============+=============+============+
Figure 8: Management Rule 4
5. OSCORE
5.1. Compression Rules
6. DTLS
6.1. Compression Rules
7. Example CORECONF usage in Python
7.1. Deletion cases
* Delete root element:
Minaburo, et al. Expires 21 April 2026 [Page 21]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc'): None
}
CORECONF REQ: iPATCH /c
{
(5100): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1811913ecf6
RES: 2.04 Changed
* Delete a specific rule:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule', 0, 3): None
}
CORECONF REQ: iPATCH /c
{
(5101, 0, 3): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1831913ed0003f6
RES: 2.04 Changed
* Delete a specific protocol field entry:
Minaburo, et al. Expires 21 April 2026 [Page 22]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry', 0, 3, 'fid-ipv6-version', 1, 'di-bidirectional'): None
}
CORECONF REQ: iPATCH /c
{
(5105, 0, 3, 5068, 1, 5018): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913f100031913cc0119139af6
RES: 2.04 Changed
* Delete a specific key:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/rule-status', 0, 3): None
}
CORECONF REQ: iPATCH /c
{
(5137, 0, 3): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1831914110003f6
RES: 2.04 Changed
* Delete a list element:
Minaburo, et al. Expires 21 April 2026 [Page 23]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry/target-value/value', 0, 3, 'fid-ipv6-version', 1, 'di-bidirectional', 0): None
}
CORECONF REQ: iPATCH /c
{
(5120, 0, 3, 5068, 1, 5018, 0): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a18719140000031913cc0119139a00f6
RES: 2.04 Changed
* Delete a multiple list elements:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry/target-value/value', 0, 3, 'fid-ipv6-trafficclass', 1, 'di-bidirectional', 1): None
}
CORECONF REQ: iPATCH /c
{
(5120, 0, 3, 5065, 1, 5018, 1): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a18719140000031913c90119139a01f6
RES: 2.04 Changed
* Delete an unknown entry:
Minaburo, et al. Expires 21 April 2026 [Page 24]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry', 2, 3, 'fid-ipv6-version', 1, 'di-bidirectional'): None
}
CORECONF REQ: iPATCH /c
{
(5105, 2, 3, 5068, 1, 5018): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913f102031913cc0119139af6
RES: 4.00 Bad Request
* Delete a protected key:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/rule-id-value', 0, 3): None
}
CORECONF REQ: iPATCH /c
{
(5135, 0, 3): None
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a18319140f0003f6
RES: 4.00 Bad Request
7.2. Update cases
* Update protected key:
Minaburo, et al. Expires 21 April 2026 [Page 25]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/rule-id-value', 0, 3): 5
}
CORECONF REQ: iPATCH /c
{
(5135, 0, 3): 5
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a18319140f000305
RES: 2.04 Changed
* Update a specific key:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/rule-status', 0, 3): 'status-candidate'
}
CORECONF REQ: iPATCH /c
{
(5137, 0, 3): 5096
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a18319141100031913e8
RES: 2.04 Changed
7.3. Addition cases
* Add a new entry:
Minaburo, et al. Expires 21 April 2026 [Page 26]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry', 0, 3, 'fid-ipv6-appprefix', 1, 'di-bidirectional'): {
'field-length': 64,
'target-value': [{'index': 0, 'value': '/oAAAAAAAAA='}],
'matching-operator': 'ietf-schc:mo-equal',
'comp-decomp-action': 'ietf-schc:cda-not-sent'
}
}
CORECONF REQ: iPATCH /c
{
(5105, 0, 3, 5057, 1, 5018): {
7: 64,
13: [{1: 0, 2: b'\xfe\x80\x00\x00\x00\x00\x00\x00'}],
9: 5083,
1: 5015
}
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913f100031913c10119139aa40718400d81a201000248fe80000000000000091913db01191397
RES: 2.04 Changed
* Add a list element (auto-indexed)
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry/target-value', 0, 3, 'fid-ipv6-flowlabel', 1, 'di-bidirectional'): {
'index': 4, 'value': 'vLw='
}
}
CORECONF REQ: iPATCH /c
{
(5118, 0, 3, 5061, 1, 5018): {
1: 4, 2: b'\xbc\xbc'
}
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913fe00031913c50119139aa201040242bcbc
RES: 2.04 Changed
Minaburo, et al. Expires 21 April 2026 [Page 27]
Internet-Draft SCHC for CoAP October 2025
* Add a list element (explicit index):
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry/target-value', 0, 3, 'fid-ipv6-flowlabel', 1, 'di-bidirectional'): {
'index': 7, 'value': 'vLw='
}
}
CORECONF REQ: iPATCH /c
{
(5118, 0, 3, 5061, 1, 5018): {
1: 7, 2: b'\xbc\xbc'
}
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913fe00031913c50119139aa201070242bcbc
RES: 2.04 Changed
* Add a new key–value pair element:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry/target-value', 0, 3, 'fid-ipv6-payload-length', 1, 'di-bidirectional'): [
{'index': 0, 'value': 'UA=='},
{'index': 1, 'value': 'VQ=='}
]
}
CORECONF REQ: iPATCH /c
{
(5118, 0, 3, 5064, 1, 5018): [
{1: 0, 2: b'\x50'}, {1: 1, 2: b'\x55'}
]
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913fe00031913c80119139a82a20100024150a20101024155
RES: 2.04 Changed
* Add a new rule:
Minaburo, et al. Expires 21 April 2026 [Page 28]
Internet-Draft SCHC for CoAP October 2025
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule', 5, 3): {
'rule-status': 'ietf-schc:status-active',
'rule-id-value': 10,
'rule-id-length': 5,
'rule-nature': 'ietf-schc:nature-compression'
}
}
CORECONF REQ: iPATCH /c
{
(5101, 5, 3): {36: 5094, 34: 10, 33: 5, 35: 5088}
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1831913ed0503a418241913e618220a18210518231913e0
RES: 2.04 Changed
* Add an entry into an unknown rule:
YANG REQ: iPATCH /c
{
('/ietf-schc:schc/rule/entry', 250, 8, 'fid-ipv6-payload-length', 1, 'di-bidirectional'): {
'field-length': 16,
'matching-operator': 'ietf-schc:mo-ignore',
'comp-decomp-action': 'ietf-schc:cda-value-sent'
}
}
CORECONF REQ: iPATCH /c
{
(5105, 250, 8, 5064, 1, 5018): {7: 16, 9: 5084, 1: 5016}
}
REQ: iPATCH /c
(Content-Format: application/yang-identifiers+cbor-seq)
a1861913f118fa081913c80119139aa30710091913dc01191398
RES: 4.00 Bad Request
8. Normative References
Minaburo, et al. Expires 21 April 2026 [Page 29]
Internet-Draft SCHC for CoAP October 2025
[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/info/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/info/rfc9363>.
[RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann,
C., and M. Richardson, "Encoding of Data Modeled with YANG
in the Concise Binary Object Representation (CBOR)",
RFC 9254, DOI 10.17487/RFC9254, July 2022,
<https://www.rfc-editor.org/info/rfc9254>.
[I-D.ietf-core-comi]
Veillette, M., Van der Stok, P., Pelov, A., Bierman, A.,
and C. Bormann, "CoAP Management Interface (CORECONF)",
Work in Progress, Internet-Draft, draft-ietf-core-comi-20,
6 May 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-core-comi-20>.
[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.toutain-schc-universal-option]
Lampin, Q., Minaburo, A., Tiloca, M., and L. Toutain,
"Options representation in SCHC YANG Data Models", Work in
Progress, Internet-Draft, draft-toutain-schc-universal-
option-01, 14 April 2025,
<https://datatracker.ietf.org/doc/html/draft-toutain-schc-
universal-option-01>.
[I-D.toutain-schc-sid-allocation]
Minaburo, A. and L. Toutain, "SCHC Sid Allocation", Work
in Progress, Internet-Draft, draft-toutain-schc-sid-
allocation-01, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-toutain-schc-
sid-allocation-01>.
Minaburo, et al. Expires 21 April 2026 [Page 30]
Internet-Draft SCHC for CoAP October 2025
Appendix A. YANG DM
rpc duplicate-rule { input { container from { uses ietf-schc:rule-id-
type; } container to { uses ietf-schc:rule-id-type; } } output { leaf
status { type string; } } }
Appendix B. Acknowledgments
The authors sincerely thank
This work was supported by the Sweden’s Innovation Agency VINNOVA
within the EUREKA CELTIC-NEXT project CYPRESS.
Authors' Addresses
Ana Minaburo
Consultant
Rue de Rennes
35510 Cesson-Sevigne
France
Email: anaminaburo@gmail.com
Laurent Toutain
IMT Atlantique
CS 17607, 2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: Laurent.Toutain@imt-atlantique.fr
Javier A. Fernandez
IMT Atlantique
CS 17607, 2 rue de la Chataigneraie
35510 Cesson-Sevigne Cedex
France
Email: javier-alejandro.fernandez@imt-atlantique.fr
Corentin Banier
IMT Atlantique
CS 17607, 2 rue de la Chataigneraie
35576 Cesson-Sevigne Cedex
France
Email: corentin.banier@imt-atlantique.fr
Minaburo, et al. Expires 21 April 2026 [Page 31]
Internet-Draft SCHC for CoAP October 2025
Marion Dumay
Orange
Email: marion.dumay@orange.com
Minaburo, et al. Expires 21 April 2026 [Page 32]