]> Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France javier-alejandro.fernandez@imt-atlantique.fr

Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France manoj.gudi@imt-atlantique.net

Institut MINES TELECOM; IMT Atlantique

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

CZ.NIC

Milesovska 1136/5 13000 Praha Czech Republic vojtech.vilimek@nic.cz

core working group TBD: to focus on sid extension to allow some manipulations of a CORECONF datastore without the need to get the full YANG DM.

Introduction The YANG modeling language is very popular for node configuration and retrieving the state of a device. XML and JSON are also two popular formats to serialize data in conformance with the data model, notably used by NETCONF and RESTCONF respectively. More recently, a new serialization format has been published, allowing a more compact representation of the information. This new format, CORECONF , is based on CBOR and introduces an integer YANG identifier, named SID, instead of a string. The mapping between strings and integers is kept in a .sid file usually generated by tools such as pyang. This document presents some extensions to the sid file, itself defined in YANG, that make it easier to convert between CBOR and JSON, as well as to manipulate YANG Data Models in a constrained environment, without referencing the full YANG module.

YANG Data Model YANG is a modeling language to structure information and check its conformity. Each element of a YANG Data Model is identified through a unique identifier. YANG is based on a hierarchical approach. During the serialization phase, data is represented either in XML or JSON. In this document we will use the JSON representation. indicates how to form a JSON structure conforming to a YANG Data Model: Leaves are represented as JSON objects, the key being the leaf name. Lists are defined through arrays. Identityref is a string containing the identifier in the YANG naming hierarchy for an identity. The YANG Data Model, in , is used to illustrate how data will be serialized. It defines a container representing a physical object able to perform several measurements. The physical object is battery powered, has a status LED able to change color, and a list of attached sensors returning an integer value.

file "sensor.yang" module sensor { yang-version 1.1; namespace "http://sensorexample.in/sensor-example"; prefix sen1; organization "Internet Engineering Task Force (IETF), CORE Working Group."; contact "CORE Working Group."; description "An illustrative YANG module used to demonstrate the serialization of a physical object with battery status, an LED indicator, and attached sensors."; revision 2026-11-02 { description "Initial revision."; reference "draft-toutain-core-sid-extension-00"; } identity battery-indicator-base-type { description "Base identity for battery level indicators."; } identity high-level { base battery-indicator-base-type; description "Indicates a high battery level."; } identity med-level { base battery-indicator-base-type; description "Indicates a medium battery level."; } identity low-level { base battery-indicator-base-type; description "Indicates a low battery level."; } typedef battery-level { type identityref { base battery-indicator-base-type; } description "Represents the battery level using an identity."; } container sensorObject { description "Represents a physical object containing sensors."; leaf statusLED { type enumeration { enum green { value 0; description "Green LED indicator."; } enum yellow { value 1; description "Yellow LED indicator."; } enum red { value 2; description "Red LED indicator."; } } description "Indicates the status LED color."; } leaf battery { type battery-level; description "Indicates the battery level."; } list sensorReadings { key "index"; description "Contains measurements from attached sensors."; leaf index { type uint8; description "Identifies the sensor reading."; } leaf sensorValue { type uint32; description "Contains the integer sensor measurement."; } } } } ]]>

The YANG tree regarding this Data Model is given in . The tree displays the module hierarchy. For the module "sensor", a container "sensorObject" contains two leaves ("statusLED", "battery") and a list ("sensorReadings").

JSON serialization An example of data, serialized with JSON, and conforming to the YANG Data Model, is given in . Embedded JSON Objects allow to represent the hierarchy. The key of the outer JSON Object is composed of the module name and the container name. The embedded JSON Object associated to this contains the leaves as keys. The YANG list is represented by a JSON array.

CBOR Serialization JSON notation is verbose for constrained networks and objects. To optimize the size of the representation, defines a CBOR serialization, also used in CORECONF. YANG ASCII identifiers are replaced by unique numbers. In CORECONF, the map keys are positive integers, called SID, which replace the ASCII identifiers and are unique. defines the allocation process. Module developers may ask for a SID range from their authority. For example, for an IETF module, the IANA will allocate a SID range. shows an example of this conversion. The range is arbitrarily fixed between 60000 and 60099. Note that the module, the identities, and the leaves have an assigned SID.

To perform the allocation, the pyang utility generates a .sid file in the JSON format, resulting in a YANG Data Model specified in . gives an excerpt.

The serialization in CBOR of the JSON example in is given in . Compared to the compacted representation of the JSON structure (152 Bytes), the CORECONF structure is 24 bytes long. Although the size is different, the structure remains the same. It is composed of embedded CBOR Maps (equivalent of JSON Object). The first key is a SID (60005 corresponds to the container). Embedded CBOR Maps use a delta notation to encode the keys. The key 5 corresponds to SID 60005+5, thus to the leaf "statusLED". Key 2 in the second CBOR Map corresponds to the YANG list "sensorReadings", and the elements of the list are stored in a CBOR Array. Note that in this example, the enum for "statusLED" (60005+5) is an integer and the identityref for "battery" (60005+1) is also an integer pointing to the SID "med-level" (60004).

Conversion between JSON and CBOR Even if the conversion between CBOR and JSON formats might look obvious, including data compatible with a YANG Data Model is not so trivial. The reason is that JSON uses ASCII identifiers for readability and CBOR prefers integers for compactness. The summarizes some YANG types when coded in JSON () or CBOR (). YANG JSON CBOR int8, int16, int32, uint8, uint16, uint32 number +int, -int int64, uint64 string +int, -int decimal64 string CBOR Tag 4 binary base64 byte array bits string array boolean boolean boolean identityref string +int enumeration string +int The conversion from CBOR to JSON is not direct, since the YANG type needs to be considered. For instance, an integer could be converted into a number, an enum, or an identityref. Note that for union, the conversion is simple since some CBOR Tags may be used to indicate how the integer is converted, but outside of the union, for a single value, there is no such clue. In the other direction, a JSON string may correspond to a 64-bit integer, an enumeration, or an identityref. To perform the conversion, the YANG type must be known, but do not appear in the SID file, a converter has to refer directly to the YANG model, which is a more complex structure to parse. SID extension propose to add this information directly in the sid file but augmenting the YANG Data Model that defines it (see ). The augmentation is specified in the YANG module of .

YANG Data Model of the SID Extension The "type" container is added to each SID item that is a leaf. When the "type" container is not present, the node is not a leaf and there is no need for type conversion. Its "base-type" leaf identifies the YANG built-in type of the leaf. The sid-extension data model (cf. ) defines an identityref for each YANG built-in type. If the model uses a derived type, defined by a typedef, "base-type" gives the built-in type it derives from, since a typedef is not an item of the .sid file (). For a type derived from an identityref, "base-type" is "identityref" and the "identityref" leaf gives the SID of the base identity. In the CBOR notation, a pair "{ ...., SID1: value1, ...}" in the CBOR Map is resolved by a first lookup in the .sid file for SID1, which returns that the type is "identityref", and a second lookup for value1 in the "identity" namespace, which returns the ASCII identifier. For an enumeration, the "enumerate" container associates a value ("enum-value") with its name ("enum-name"). For bits, the "bits" container associates a position ("bit-position") with its name ("bit-name"). The container "type" may contain several structures reflecting a union, disambiguated by CORECONF through the use of CBOR tags.

Navigating the CORECONF Structure As we saw, the CORECONF data is structured as a tree. The gives an example for the example module described in . The numbers are the SIDs associated to the YANG Data Model. defines how queries are made on this structure to get the full tree or a sub tree.

Requesting the SID corresponding to the module (60005) will return the full tree. Requesting "battery" leaf (60006) will return the leaf and the associated value, while requesting "sensorReadings" (60007) will return the subtree with all its values. Going deeper in this sub-tree imposes the use of keys. For instance, to get a specific "sensorValue" one must provide the key "index" (60008). In , accessing a specific element within a YANG list requires providing the corresponding list keys in the request (e.g., FETCH). While illustrates a simple case involving a single list, a data model may contain several nested lists, and each list may require one or more keys. Determining which keys are required at each level normally requires knowledge of the YANG Data Model.

YANG Data Model of the key mapping To avoid requiring constrained devices to parse and store the full YANG Data Model, we propose to embed a footprint of the Data Model into the SID file through a key-mapping object. This object associates each list SID with the SIDs of its key leaf nodes, preserving their order as defined in the YANG Data Model.

The "key-mapping" container is added at the "sid-file" level. It contains a list of "entry" objects. Each entry gives, in "list-sid", the SID of a YANG list and, in "key-sids", the array of the SIDs acting as YANG keys for that YANG list. The "key-mapping" container indicates: that a SID is a YANG list, since its value appears as the "list-sid" of an entry. the number of elements in the corresponding "key-sids" array indicates how many items are involved as a YANG list key. The value for these items can be taken from the request. the array also indicates, in the order of the YANG keys, which SIDs contain the value that must be compared to the YANG list key sent in the request. With the information contained in the "key-mapping" structure, it is possible to browse any CORECONF structure and return the appropriate requested SID without the need to go back to the original YANG file.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). This document describes YANG mechanisms for defining abstract data structures with YANG. YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for 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. Trilliant Networks Inc. IMT Atlantique 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 (–24) is intended to address the remaining // IESG comments. Trilliant Networks Inc. consultant IMT Atlantique YumaWorks Universität Bremen TZI This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks.

YANG Module for the SID File Extension The module below augments the "ietf-sid-file" module of using the structure augmentation of . It adds the type information to each SID item and a key-mapping at the "sid-file" level.

file "ietf-sid-file-extension@2026-07-19.yang" module ietf-sid-file-extension { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-sid-file-extension"; prefix sid-ext; import ietf-sid-file { prefix sid; reference "RFC 9595"; } import ietf-yang-structure-ext { prefix sx; reference "RFC 8791"; } organization "Personal contribution"; contact "Editor: Laurent Toutain Javier A. Fernandez Vojtěch Vilímek "; description "Augmentation of ietf-sid-file to add type information per item and key-mapping at the sid-file level."; revision 2026-07-19 { description "IETF 126 Hackathon refinements."; reference "draft-toutain-core-sid-extension-00"; } revision 2026-04-28 { description "Initial revision."; reference "draft-toutain-core-sid-extension-00"; } // it may be better if NETMOD created a YANG Module // with identities for built-in types identity yang-base-type { description "Base identity for all YANG built-in types."; } identity anydata { base yang-base-type; description "YANG built-in type anydata."; } identity anyxml { base yang-base-type; description "YANG built-in type anyxml."; } identity binary { base yang-base-type; description "YANG built-in type binary."; } identity boolean { base yang-base-type; description "YANG built-in type boolean."; } identity decimal64 { base yang-base-type; description "YANG built-in type decimal64."; } identity empty { base yang-base-type; description "YANG built-in type empty."; } identity identityref { base yang-base-type; description "YANG built-in type identityref."; } identity instance-identifier { base yang-base-type; description "YANG built-in type instance-identifier."; } identity int8 { base yang-base-type; description "YANG built-in type int8."; } identity int16 { base yang-base-type; description "YANG built-in type int16."; } identity int32 { base yang-base-type; description "YANG built-in type int32."; } identity int64 { base yang-base-type; description "YANG built-in type int64."; } identity leafref { base yang-base-type; description "YANG built-in type leafref."; } identity string { base yang-base-type; description "YANG built-in type string."; } identity uint8 { base yang-base-type; description "YANG built-in type uint8."; } identity uint16 { base yang-base-type; description "YANG built-in type uint16."; } identity uint32 { base yang-base-type; description "YANG built-in type uint32."; } identity uint64 { base yang-base-type; description "YANG built-in type uint64."; } identity union { base yang-base-type; description "YANG built-in type union."; } typedef yang-type { type identityref { base yang-base-type; } description "An identityref that selects one of the YANG built-in types defined in this module."; } // --- Augmentation 1: within the grouping, via its point of use --- sx:augment-structure "/sid:sid-file/sid:item" { // This augmentation targets the expanded list inside the /sid:sid-file/sid:item, // the /sid:sid-file is sx:structure, not grouping (even through it is defined inside grouping) description "Adds type information to each SID item."; container type { description "Type information of the YANG node identified by the SID."; leaf base-type { type yang-type; description "YANG built-in type of the node."; } leaf identityref { type uint64; description "SID of the referenced identity."; } container enumerate { description "Enumeration item information, used when the SID identifies an enumeration item."; leaf enum-value { type uint32; description "Value of the enumeration item."; } leaf enum-name { type string; description "Name of the enumeration item."; } } container bits { description "Bit item information, used when the SID identifies a bit item."; leaf bit-position { type uint32; description "Position of the bit item."; } leaf bit-name { type string; description "Name of the bit item."; } } } } // --- Augmentation 2: at the sid-file level, excluding items --- sx:augment-structure "/sid:sid-file" { description "Adds key-mapping at the sid-file level."; container key-mapping { description "Maps each list SID to the ordered list of SIDs of its key leaves."; list entry { key "list-sid"; description "Key information for one YANG list."; leaf list-sid { type sid:sid; description "SID of the list node."; } leaf-list key-sids { type sid:sid; ordered-by user; description "SIDs of the key leaves, in key order."; } } } } } ]]>