]> Acklio

1137A avenue des Champs Blancs 35510 Cesson-Sevigne Cedex France ana@ackl.io

Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Laurent.Toutain@imt-atlantique.fr

schc Working Group blabla

Introduction RFC9363 defines a YANG Data Model for SCHC rules. specifies the process for SID allocation and management. This document discuss of the SID allocation for RFC9363.

SCHC YANG Data Model The version @2023-01-18 of the SCHC YANG Data Model published in the RFC 9363 contains 136 SIDs (92 for identities, 2 for features and 42 for data). indicates that the SID range for the YANG Data Model specified in RFC is between 1000 and 59 000 and that the maximum request pool SHOULD NOT exceed 1000. The draft also gives some pre allocated values. Since SIDs will be used either to represent unique identity contained in the data model and also leaves (data) forming this data model, it could be wise to distinguish between identifiers and data. Data structures are delta encoded and included as a CBOR element, the size depends on the value. Deltas between -24 and +23 are encoded on a single byte. Deltas between -256 and +255 use 2 bytes and larger values corresponding to the RFC SID range will be encoded into 3 bytes. To optimize the CORECONF representation delta should be smaller as possible for the more frequent leaves. On the other hand identities are included in the CORECONF representation and for the RFC SID range the size is constant and equal to 3 bytes.

Example

The example in gives a CORECONF structure transposed the CBOR diagnostic notation and its equivalent in RESTCONF with JSON. For readability and compactness, this example is edited and do not encode a full rule as defined in RFC9363. The default SID numbering produced by pyang is used, starting from 5000 for SCHC Data Model defined in RFC9363 and 2000000 for an experimental module for OAM. We can see the delta encoding. The first SID 5095 represents "ietf-schc:schc". "/ietf-schc:schc/rule" which is coded with a +1 since SID 5096 has been assigned. "/ietf-schc:schc/rule/entry" is coded with a delta of 4. Then a list of Field Description follows. +1 represents the leaf "ietf-schc:schc/rule/entry/comp-decomp-action" and the value assigned to that key contains the SID of "ietf-schc:cda-not-sent" identity. Note that the second element contains a "field-id" belonging to the "ietf-schc-oam" module and the associate SID is 2000003.

Recommendation for SID values The SCHC YANG Data Model defined in RFC 9363 will probably be augmented, to include for instance access control data. To keep a compact representation, delta values must be kept as small as possible. The LPWAN working group should not use the automatic SID numbering and provide a more optimal allocation scheme for augmentation of the SCHC YANG Data Model. A first recommendation is to avoid merging data and identity in order to limit the delta encoding. The distance between these two sections can be 255 SID to allow deltas on 2 bytes. The second recommendation is to leave some unused SID around SCHC rules to allow augmentation.

SID value impact To study the impact of SIDs size and delta size, we will take three scenarii, which cover the original Data Model defined in and some augmentations, rules regarding these scenarii are listed in the annex: sor-9363 contains only parameters defined in with IPv6, UDP and CoAP fields. This is a set of 7 rules: 2 for compression and 5 for fragmentation. sor-oam adds to the previous set of rules, a compression rule for ICMP messages. This add new identities for ICMPv6 fields, but the rule structure is not modified. sor-oam+ac augments to the previous set of rule with access control nodes. This requires an augmentation with Access Control DM and includes new nodes in the rule Data Model. For this three group of Set of Rule, we applied four different allocation methods for the SIDs: SIDs are located in the million range for the 3 YANG modules (1000 000 for basic model based on RFC9363, 2 000 000 for OAM and 3 000 000 for Access Control), SIDs are located in the IETF range (5000:500, 5500:50, 6000:50) and in the alphabetical order, SIDs are manually allocated regarding their frequency occurrences in the rule, tens of the main used SID for RFC9363 are allocated in the IESG range (CDA: compute, LSB, Match Mapping, not sent, value-send, MO: equal, ignore, match, MSB, and bidirectional). The following table shows the results:

The most important result, is the factor 10 between CBOR and JSON (without indentation) size which proves the efficiency of encoding. 2 kilo-byte of information to represent 8 rules (3 compression and 5 fragmentation rules). The IETF-grouped has a impact on the rule size, even when no augmentation is perform. This is the case for rfc9363 compatible rules and OAM addition. Figure shows the alphabetical order allocation with pyang.

"Rule-id-value", "rule-id-length", "rule-nature" present in all rules have a delta higher than 23. On the other hand, other elements such are matching-operator-value or comp-decomp-action-value which are not present in all rules have a smaller delta. Figure {#Allocation} gives the manual SID allocation used in this document. This lead to a reduction of about 20 bytes (a mean of 5 bytes for the 8 rules in the example) when no augmentation is perform. In case of augmentation with the last example including access control, this leads to 50 bytes. Manual allocation allows also to use some other space, the last scenario takes 10 values (1%) from the IESG space for the most frequent identity.

Administrative process The allocation process proposed in is slightly enhanced: the SCHC WG requests IANA for a larger pool of SIDs than originally needed for a single Data Model (for instance 500 SIDs) the SCHC WG MAY request IESG review for a small amount of SIDs the WG manages the space as presented in . If a module is validated by the WG and request a WG allocation, the SID are allocated in the space and a sid file is issue for this module. The result is a better allocation of the space, proposes a minimum of 50 SIDs per module, but looking at the existing models, the effective number is smaller. Using a common pool, allows a better utilization.

This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.This document obsoletes RFC 6536. This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules. Acklio Institut MINES TELECOM; IMT Atlantique This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules. This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules. Trilliant Networks Inc. Acklio Google Switzerland GmbH Universität Bremen TZI Sandelman Software Works YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit unsigned integers used to identify YANG items, as a more compact method to identify YANG items that can be used for efficiency and in constrained environments (RFC 7228). This document defines the semantics, the registration, and assignment processes of YANG SIDs for IETF managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. // The present version (-20) is intended to address all IESG // feedback. It has significantly progressed from -16, which was the // original submission to the IESG. Acklio Institut MINES TELECOM; IMT Atlantique Institut MINES TELECOM; IMT Atlantique The framework for SCHC defines an abstract view of the rules, formalized with through a YANG Data Model. In its original description rules are static and share by 2 entities. The use of YANG authorizes rules to be uploaded or modified in a SCHC instance and leads to some possible attacks, if the changes are not controlled. This document summarizes some possible attacks and define augmentation to the existing Data Mode, to restrict the changes in the rule. Cisco Universitat Politecnica de Catalunya Universitat Politecnica de Catalunya IMT-Atlantique Concordia University NIC Labs, Universidad de Chile The present document updates the SCHC (Static Context Header Compression and fragmentation) protocol RFC8724 and the corresponding Yang Module RFC9363. It defines a SCHC Compound ACK message format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by accumulating bitmaps of several windows in a single SCHC message (i.e., the SCHC Compound ACK). Both message format and procedure are generic, so they can be used, for instance, by any of the four Low Power Wide Area Networks (LPWANs) technologies defined in RFC8376, being Sigfox, LoRaWAN, NB- IoT and IEEE 802.15.4w.

Set of Rules

SID Allocation

Security Considerations TBD

IANA Considerations TBD