core working group J. A. Fernandez Internet-Draft M. Gudi Intended status: Standards Track L. Toutain Expires: 6 May 2027 Institut MINES TELECOM; IMT Atlantique V. Vilímek CZ.NIC 2 November 2026 SID Extension to efficiently manipulate YANG Data Models draft-toutain-core-sid-extension-00 Abstract TBD: to focus on sid extension to allow some manipulations of a CORECONF datastore without the need to get the full YANG DM. 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 6 May 2027. Copyright Notice 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. Fernandez, et al. Expires 6 May 2027 [Page 1] Internet-Draft SID Extension November 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 2 3. JSON serialization . . . . . . . . . . . . . . . . . . . . . 5 4. CBOR Serialization . . . . . . . . . . . . . . . . . . . . . 6 5. Conversion between JSON and CBOR . . . . . . . . . . . . . . 9 5.1. YANG Data Model of the SID Extension . . . . . . . . . . 10 6. Navigating the CORECONF Structure . . . . . . . . . . . . . . 12 6.1. YANG Data Model of the key mapping . . . . . . . . . . . 12 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 Appendix A. YANG Module for the SID File Extension . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. 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 [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. 2. 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. [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. Fernandez, et al. Expires 6 May 2027 [Page 2] Internet-Draft SID Extension November 2026 * 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. 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."; Fernandez, et al. Expires 6 May 2027 [Page 3] Internet-Draft SID Extension November 2026 } 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 Fernandez, et al. Expires 6 May 2027 [Page 4] Internet-Draft SID Extension November 2026 "Contains measurements from attached sensors."; leaf index { type uint8; description "Identifies the sensor reading."; } leaf sensorValue { type uint32; description "Contains the integer sensor measurement."; } } } } Figure 1: Example of a YANG Data Model for sensors 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 Figure 2: YANG tree associated to the DM. 3. JSON serialization 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. Fernandez, et al. Expires 6 May 2027 [Page 5] Internet-Draft SID Extension November 2026 { "sensor:sensorObject": { "statusLED": "green", "battery": "sensor:med-level", "sensorReadings": [ { "index": 0, "sensorValue": 42 }, { "index": 1, "sensorValue": 22 } ] } } Figure 3: JSON serialization of the example data. 4. CBOR Serialization 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. Fernandez, et al. Expires 6 May 2027 [Page 6] Internet-Draft SID Extension November 2026 $ 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 Figure 4: SID allocation for the example module. 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. Fernandez, et al. Expires 6 May 2027 [Page 7] Internet-Draft SID Extension November 2026 { "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 }, ... Figure 5: Excerpt of the .sid file. 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). Fernandez, et al. Expires 6 May 2027 [Page 8] Internet-Draft SID Extension November 2026 b'a119ea65a305000119ea640282a2010002182aa201010216' Diagnostic notation: {60005: {5: 0, 1: 60004, 2: [ {1: 0, 2: 42}, {1: 1, 2: 22} ] } } Figure 6: CBOR serialization of the example data. 5. 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 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 | +-------------------------------------------+---------+------------+ Table 1: YANG basic types in JSON and CBOR. Fernandez, et al. Expires 6 May 2027 [Page 9] Internet-Draft SID Extension November 2026 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. 5.1. 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. 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. Fernandez, et al. Expires 6 May 2027 [Page 10] Internet-Draft SID Extension November 2026 ... { "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" } } ... Figure 7: SID file with the type extension. Fernandez, et al. Expires 6 May 2027 [Page 11] Internet-Draft SID Extension November 2026 6. Navigating the CORECONF Structure As we saw, the CORECONF data is structured as a tree. The Figure 8 gives an example for the example module described in Figure 1. The numbers are the SIDs associated to the YANG Data Model. [I-D.ietf-core-comi] defines how queries are made on this structure to get the full tree or a sub tree. sensorObject 60005 battery LED | sensorReadings +----------+----------+ | | | 60006 60010 60007 | +-----------+----------+-----------+ index | | | | sensorValue +---------+ +----------+ +----------+ +----------+ | | | | | | | | 60008 60009 60008 60009 60008 60009 60008 60009 Figure 8: SIDs in the CORECONF tree of the example module. 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 [I-D.ietf-core-comi], accessing a specific element within a YANG list requires providing the corresponding list keys in the request (e.g., FETCH). While Figure 8 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. 6.1. 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. Fernandez, et al. Expires 6 May 2027 [Page 12] Internet-Draft SID Extension November 2026 "ietf-sid-file-extension:key-mapping": { "entry": [ { "list-sid": 60007, "key-sids": [60008] } ] } Figure 9: key-mapping of the SID file. 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. 7. Normative References [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-22, 2 November 2026, . [I-D.ietf-core-sid] Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-24, 22 December 2023, . Fernandez, et al. Expires 6 May 2027 [Page 13] Internet-Draft SID Extension November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data Structure Extensions", RFC 8791, DOI 10.17487/RFC8791, June 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [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, . [RFC9595] Veillette, M., Ed., Pelov, A., Ed., Petrov, I., Ed., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", RFC 9595, DOI 10.17487/RFC9595, July 2024, . Fernandez, et al. Expires 6 May 2027 [Page 14] Internet-Draft SID Extension November 2026 Appendix A. YANG Module for the SID File Extension 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. 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"; } Fernandez, et al. Expires 6 May 2027 [Page 15] Internet-Draft SID Extension November 2026 // 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 { Fernandez, et al. Expires 6 May 2027 [Page 16] Internet-Draft SID Extension November 2026 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."; } Fernandez, et al. Expires 6 May 2027 [Page 17] Internet-Draft SID Extension November 2026 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."; Fernandez, et al. Expires 6 May 2027 [Page 18] Internet-Draft SID Extension November 2026 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."; } } } } } Figure 10: YANG module extending the SID file Authors' Addresses Fernandez, et al. Expires 6 May 2027 [Page 19] Internet-Draft SID Extension November 2026 Javier A. Fernandez Institut MINES TELECOM; IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: javier-alejandro.fernandez@imt-atlantique.fr Manoj Gudi Institut MINES TELECOM; IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: manoj.gudi@imt-atlantique.net Laurent Toutain Institut MINES TELECOM; IMT Atlantique 2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Email: Laurent.Toutain@imt-atlantique.fr Vojtěch Vilímek CZ.NIC Milesovska 1136/5 13000 Praha Czech Republic Email: vojtech.vilimek@nic.cz Fernandez, et al. Expires 6 May 2027 [Page 20]