| Internet-Draft | SID Extension | November 2026 |
| Fernandez, et al. | Expires 6 May 2027 | [Page] |
TBD: to focus on sid extension to allow some manipulations of a CORECONF datastore without the need to get the full YANG DM.¶
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 6 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
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 [RFC6241] and RESTCONF [RFC8040] respectively. More recently, a new serialization format has been published, allowing a more compact representation of the information. This new format, CORECONF [I-D.ietf-core-comi], 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 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. [RFC7951] 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 Figure 1, 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.¶
<CODE BEGINS> 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.";
}
}
}
}
<CODE ENDS>
The YANG tree regarding this Data Model is given in Figure 2. The tree displays the module hierarchy. For the module "sensor", a container "sensorObject" contains two leaves ("statusLED", "battery") and a list ("sensorReadings").¶
$ pyang -f tree sensor.yang
module: sensor
+--rw sensorObject
+--rw statusLED? enumeration
+--rw battery? battery-level
+--rw sensorReadings* [index]
+--rw index uint8
+--rw sensorValue? uint32
An example of data, serialized with JSON, and conforming to the YANG Data Model, is given in Figure 3. 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.¶
{
"sensor:sensorObject": {
"statusLED": "green",
"battery": "sensor:med-level",
"sensorReadings": [
{
"index": 0,
"sensorValue": 42
},
{
"index": 1,
"sensorValue": 22
}
]
}
}
JSON notation is verbose for constrained networks and objects. To optimize the size of the representation, [RFC9254] 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. [I-D.ietf-core-sid] 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.¶
Figure 4 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.¶
$ pyang --sid-generate-file=60000:100 --sid-list sensor.yang SID Assigned to --------- -------------------------------------------------- 60000 module sensor 60001 identity battery-indicator-base-type 60002 identity high-level 60003 identity low-level 60004 identity med-level 60005 data /sensor:sensorObject 60006 data /sensor:sensorObject/battery 60007 data /sensor:sensorObject/sensorReadings 60008 data /sensor:sensorObject/sensorReadings/index 60009 data /sensor:sensorObject/sensorReadings/sensorValue 60010 data /sensor:sensorObject/statusLED File sensor@unknown.sid created Number of SIDs available : 100 Number of SIDs used : 11
To perform the allocation, the pyang utility generates a .sid file in the JSON format, resulting in a YANG Data Model specified in [I-D.ietf-core-sid]. Figure 5 gives an excerpt.¶
{
"assignment-range": [
{
"entry-point": 60000,
"size": 100
}
],
"module-name": "sensor",
"module-revision": "unknown",
"item": [
{
"namespace": "module",
"identifier": "sensor",
"status": "unstable",
"sid": 60000
},
{
"namespace": "identity",
"identifier": "battery-indicator-base-type",
"status": "unstable",
"sid": 60001
},
...
The serialization in CBOR of the JSON example in Figure 3 is given in Figure 6. 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).¶
b'a119ea65a305000119ea640282a2010002182aa201010216'
Diagnostic notation:
{60005:
{5: 0,
1: 60004,
2: [
{1: 0,
2: 42},
{1: 1,
2: 22}
]
}
}
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 Table 1 summarizes some YANG types when coded in JSON ([RFC7951]) or CBOR ([RFC8949]).¶
| 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 [RFC9595] (see Figure 7). The augmentation is specified in the YANG module of Appendix A.¶
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. Appendix A) 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 ([RFC9595]).¶
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.¶
...
{
"namespace": "data",
"identifier": "/sensor:sensorObject",
"status": "unstable",
"sid": 60005
},
{
"namespace": "data",
"identifier": "/sensor:sensorObject/battery",
"status": "unstable",
"sid": 60006,
"ietf-sid-file-extension:type": {
"base-type": "ietf-sid-file-extension:identityref",
"identityref": 60001
}
},
{
"namespace": "data",
"identifier": "/sensor:sensorObject/sensorReadings",
"status": "unstable",
"sid": 60007
},
{
"namespace": "data",
"identifier": "/sensor:sensorObject/sensorReadings/index",
"status": "unstable",
"sid": 60008,
"ietf-sid-file-extension:type": {
"base-type": "ietf-sid-file-extension:uint8"
}
},
{
"namespace": "data",
"identifier": "/sensor:sensorObject/sensorReadings/sensorValue",
"status": "unstable",
"sid": 60009,
"ietf-sid-file-extension:type": {
"base-type": "ietf-sid-file-extension:uint32"
}
}
...
The module below augments the "ietf-sid-file" module of [RFC9595] using the structure augmentation of [RFC8791]. It adds the type information to each SID item and a key-mapping at the "sid-file" level.¶
<CODE BEGINS> 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
<mailto:laurent.toutain@imt-atlantique.fr>
Javier A. Fernandez
<mailto:javier-alejandro.fernandez@imt-atlantique.fr>
Vojtěch Vilímek
<mailto:vojtech.vilimek@nic.cz>";
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.";
}
}
}
}
}
<CODE ENDS>