| Internet-Draft | CORECONF | December 2024 |
| Bormann | Expires 6 June 2025 | [Page] |
This short paper provides an overview over the CORECONF architecture for employing YANG models in managing IoT devices. CORECONF is based on CoAP as a transfer protocol and YANG-CBOR as its data representation format, analogous to the way the original RESTCONF was defined to use HTTP and YANG-XML or YANG-JSON, and the way NETCONF uses SSH and YANG-XML.¶
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 June 2025.¶
Copyright (c) 2024 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.¶
This short paper provides an overview over the CORECONF architecture for employing YANG models in managing IoT devices. CORECONF is based on CoAP [RFC7252] as a transfer protocol and YANG-CBOR [RFC9254] as its data representation format, analogous to the way the original RESTCONF [RFC8040] was defined to use HTTP [STD97] [STD98] and YANG-XML [RFC7950] or YANG-JSON [RFC7951], and the way NETCONF [RFC6241] uses SSH [RFC4251] and YANG-XML [RFC7950]. The mapping of the CORECONF interactions to CoAP is described in [I-D.ietf-core-comi]. In support of CORECONF, early contributions exist for supporting YANG metadata [RFC7952] in YANG-CBOR [I-D.bormann-cbor-yang-metadata] and for a significant performance optimization further shedding the text-based heritage of YANG [I-D.bormann-cbor-yang-standin].¶
One definition of the Internet of Things is that it aims to connect devices ("Things") via the Internet that are embedded in everyday physical items, making them "available for interaction over a network, thereby enabling digital interaction with the physical world for humans, services, and/or other Things" [REST-IOT].¶
The number of Internet nodes that could be called "Things" in this sense has been steadily growing, and is currently estimated to be on the order of 20 billion, possibly doubling in the next eight years [IOT-SCALE].¶
While Things vary wildly in their technical characteristics, the scale of their deployment creates a practical limit to the power resources available to them: If we were willing to spend 1 % of the global electricity generation just on the connectedness of those Things, we would have a total power budget of about 35 GW for all of them [POWER], leaving less than 2 W on average for each of them. Since there will be many Things that need significantly more than 2 W (and 1 % is maybe too spendy at an energy cost of several dollars per year per Thing), the majority of the Things will need to get by with significantly less than 1 W average sustained power each. If operation from primary batteries is essential to the function of the Thing and battery lifetimes of a few years are desired, this upper boundary shrinks to the order of a few 10s or 100s of µW (for a single CR2032 button cell or 2 AA batteries, respectively).¶
Together with the need to also limit the non-energy per-device cost of ownership at this scale, this turns a significant part of the Things into devices with low resources available to them, or constrained devices [RFC7228] [I-D.ietf-iotops-7228bis].¶
Architectures that aim to support IoT therefore need to be able to accommodate constrained (low-resource) devices, even if not all IoT devices are subject to the same constraints.¶
In the late 1980s, at a time when the Internet Protocol Suite was still in active competition with OSI-based proposals, the IETF converged on a simple network management solution, SNMP (Simple Network Management Protocol, [RFC1067]).¶
As with the proposals it initially competed with [RFC1095], SNMP based its data modeling language on ASN.1 (standardized as [X.208] at the time, also known as ISO 8824, previously as the X.409 component of the X.400 messaging standardization project). SNMP employed ASN.1 macros as a textual convention to create the SMIv2 data modeling language as a specialization of ASN.1's eponymous datatype declaration language [STD58]. (In ISO, ASN.1 macros were not much later deprecated in favor of ASN.1 Information Objects, which could not easily be adapted to SNMP's needs; as a result, SNMP continued to stay tied to the 1988 version of ASN.1.) SMIv2 has been criticized for requiring significant, non-trivial transformations of the intended information model [RFC3444] into the limited expressiveness of its generic data model (such as constructing conceptual tables from columnar data objects, see Section 7.1 of [RFC6643] for a description of recovering the structure in an inverse process).¶
With its data model specification language, SNMP imported the concept of ASN.1 Object Identifiers (OIDs), identifiers represented as sequences of unsigned integers, each of which addresses one level of a hierarchy of potentially delegated registries. The representation of OIDs in ASN.1's Basic Encoding Rules (BER, [X.209]) can be reasonably efficient, and the more human-readable presentation is a simple sequence of decimal unsigned integers separated by dots. OIDs' delegation technique allows anyone to coin OIDs, once they have received the delegation of an OID prefix ("arc") somewhere in the OID hierarchy. This keeps OIDs popular in many environments, such as in the IETF Security area, but also makes it hard to enforce any structure or semantics on namespaces represented by OIDs.¶
When IETF standardization of network management for IoT began in earnest in the early 2010s, SNMP was already in the process of being obsoleted by NETCONF [RFC6241] for many applications, in particular those involving remote configuration and not just monitoring. However, the simplicity and low resource requirements of the SNMP protocol compared to the XML-based NETCONF [SNMP-NETCONF] were a good match for constrained nodes, and SNMP MIBs (SMIv2 modules) were widely available for many areas of application relevant to IoT. This caused initial efforts in the IoT network management space to be based on SNMP (for example, the 6LoWPAN MIB [RFC7388]).¶
At the same time, the NETCONF protocol ([RFC6241], originally [RFC4741]) was getting established in the wider Internet, and with it the modeling language YANG [RFC6020]. Both efforts were closely tied to the idiosyncrasies of XML, which was popular at the time as a framework for text-based data representation formats, even though its predecessor SGML was originally created for document interchange [ISO 8879:1986].¶
In addition to allowing the monitoring of state data, NETCONF was specifically addressing the configuration of network devices, which was supported by SNMP implementations only in a limited way. NETCONF was designed to allow "the functionality of the management protocol to closely mirror the native functionality of the device" (Section 1 of [RFC4741]).¶
"The YANG data modeling language [RFC6020] has been developed for specifying NETCONF data models [...]" (Section 1.2 of [RFC6241]). Instead of employing the ASN.1 macro language used for SMIv2, YANG has been designed as a new (directly human-readable) computer language, initially with an XML-based representation format and thus generic data model (which we call YANG-XML).¶
Since YANG was created, the popularity of XML has faded away towards an increased popularity of JSON [STD90]. A JSON-based representation (which we call YANG-JSON, [RFC7951]) has been added to YANG with YANG 1.1 [RFC7950], for use as an alternative format that can be used with the RESTCONF protocol [RFC8040]. This has to work around both JSON's own interoperability problems [RFC7493] and the need to be bug-compatible with XML idiosyncrasies (for instance, see Section 6.10 of [RFC7951]).¶
Both YANG-XML and YANG-JSON build an identifier from names that resemble XML QNames (Qualified Names, i.e., colon-separated pairs of an optional prefix and a name; the prefix is usually registered). Instance-identifiers, i.e., pointers into a data tree, are constructed by separating a sequence of (qualified) names and index values with slash characters and square brackets, respectively. This is similar in concept as, but dramatically less efficient (both in space and processing time) than, the ASN.1 BER representation of OIDs known from SNMP.¶
The Constrained Application Protocol (CoAP, [RFC7252]) was designed as an application protocol for constrained nodes that is based on the Representational State Transfer [REST] architecture it has in common with HTTP. Initially, CoAP provided the usual basic complement of methods known from HTTP (GET, PUT, POST, DELETE). This was later extended by three additional methods: FETCH to perform the equivalent of a GET with additional parameters sent in the body of the request, and PATCH/iPATCH (idempotent PATCH) for updating a resource based on data in the body of the request [RFC8132].¶
CoAP's "observe" extension can be used to automatically obtain updates to a previously obtained representation of a resource [RFC7641]. The "block-wise" extension enables the transfer of data items that would not fit into (or are otherwise considered too large for) a single packet [RFC7959].¶
Independent of the discussion here, CoAP is already used by ecosystem-specific IoT management protocols such as OMA's Lightweight M2M (LwM2M) [LWM2M].¶
In 2012, Ersue, Romascanu and Schönwälder described eight IoT use cases and derived requirements for "Management of Networks of Constrained Devices" [COMAN].¶
The CORECONF effort was started in 2013 by van der Stok as "CoAP Management Interfaces" (COMI) [I-D.draft-vanderstok-core-comi-00], initially focused on the simpler SNMP ecosystem, replacing just the SNMP protocol (and its security solution) by CoAP, but keeping the data model. This enabled a device to share code and complexity between the network management and the device's application protocol.¶
Veillette and Pelov, among others, joined the effort soon with the "Constrained Objects Language" (CoOL) proposal [I-D.draft-veillette-core-cool-00]. At the time, the management community had started work on RESTCONF [I-D.draft-bierman-netconf-restconf-00], replacing the custom NETCONF protocol by a simplified REST-based architecture (i.e., employing HTTP), which lent itself to realizing a further simplified variant over CoAP as well. CoOL provided a first representation of YANG data structures in the Concise Binary Object Representation (CBOR) format ([RFC7049], now [STD94]). This allowed leaving behind the inefficient text-based representation formats on which YANG-XML (and later YANG-JSON) were built.¶
CoOL also pioneered the idea of a Fully-qualified data node ID
(FQDNID), which was a 31-bit integer standing in for the (text-based)
YANG data name.
The intention was to annotate YANG models by information that would
allow deriving FQDNIDs and related numbers.
The CoAP protocol would be extended by a Fields Option, which would
extend the URI by descending into the YANG tree based on a list of
FQDNIDs.
(This was later replaced by a special syntax that could be used within
the request URI, and ultimately by switching to CoAP's FETCH and
iPATCH methods [RFC8132] instead of GET/PUT, supplying the identifying
information in the CoAP request payload.)¶
Discussion about the best way to derive an efficient form of the YANG data name dominated the early discussion about CORECONF. Briefly, a hash-based approach was favored [I-D.draft-vanderstok-core-comi-05], but it turned out to be too hard to manage the collisions during model evolution, and hash values also didn't provide a main benefit of a more structured allocation of integer IDs: Since related IDs usually occur in a cluster, a simple delta encoding of the IDs can provide excellent encoding efficiency. A hierarchical delta encoding of IDs is the basis of today's YANG-CBOR representation [RFC9254].¶
To obtain an integer ID that exhibits good locality, boosting the benefits from delta-encoding, the community arrived at large (63-bit) unsigned integers. These integers are called YANG SIDs, YANG Schema Item iDentifiers, and can identify YANG schema nodes, YANG identities, YANG modules, or YANG features. The huge linear SID space is managed by employing a hierarchy of IANA registries [RFC9595], first carving up the large space into million-plus "mega-ranges", then, for an individual YANG model, allocating out of a chosen mega-range a SID range of, say, 100 integers. Each YANG model can in turn assign its individual SIDs from its SID range automatically (or even have them assigned automatically after the fact via a designated expert) or make use of an optimized assignment method tailored to the individual model [I-D.toutain-lpwan-sid-allocation].¶
The complete CORECONF architecture is built from four specifications:¶
YANG-CBOR [RFC9254], published July 2022. This maps YANG data into CBOR as a representation format, similar to how YANG-XML [RFC7950] maps into XML and YANG-JSON [RFC7951] maps into JSON. It is itself quite efficient, but carries data in text form that YANG modules (such as those exported from [RFC6991]) define as text-based (such as date/time or IP/MAC addresses). [I-D.bormann-cbor-yang-standin] proposes a remedy. Discussion is ongoing on whether this should be added in the transparent way the current document chooses (so it can be seamlessly applied to existing modules such as those from [RFC6991]) and/or by adding information to the YANG modules in a future YANG extension. [I-D.bormann-cbor-yang-metadata] proposes a way to represent YANG metadata [RFC7952], which essentially offer compatibility to the use of XML attributes in YANG-XML, efficiently and in a much less contorted way than that defined for JSON.¶
YANG-SID [RFC9595], published July 2024. This defines the registration and assignment processes for YANG-SIDs, the efficient binary unsigned integer representation for the text-based names found in YANG-XML and YANG-JSON, as well as a representation format ("SID file") for recording the mapping between YANG names and YANG SIDs that applies to each YANG module in use. These detailed processes need to take into account that YANG SIDs will be needed for many existing YANG modules, as well as YANG modules that are newly being developed and stay in this stage for a while.¶
Both YANG-CBOR and YANG-SID are designed so they can be used in any YANG environment, including outside CORECONF, e.g., in a RESTCONF environment to provide an efficient binary representation there as well.¶
COMI (CoAP Management Interface for CORECONF, [I-D.ietf-core-comi]). COMI employs YANG-CBOR, YANG-SID, and CoAP to provide simplified network management operations for constrained devices. The datastore model supported today is that of a single unified datastore (with potential later extensions possible; e.g., for obtaining some of the benefits discussed in Section 2 of [RFC8342]). As a replacement for SNMP's traps and special YANG notification protocols, COMI employs CoAP's "observe" mechanism, applied to "event stream resources". A potential extension to be added in a separate document could handle the remaining problem of how to control the amount of data that may be in a response to a request operating on a non-trivial data tree, potentially including, but not limited to, pagination [I-D.ietf-netconf-list-pagination].¶
Revision -16 has passed Working Group Last Call (WGLC) on 2023-09-15.
This (and previous revisions) has been implemented in several
research environments and, during discussions in conjunction with
the May 2024 T2TRG interim meeting in Paris, was considered to meet
the goals these environments planned to achieve.
Based on implementation experience, the WG has since explored a
number of further rounds of simplification, one of which is still
outstanding; completion is considered imminent.¶
Constrained YANG Module Library [I-D.ietf-core-yang-library].
This document describes a simplified constrained version of the
YANG library [RFC8525] that provides information about the
YANG modules, datastores, and datastore schemas used by a
constrained network management server (e.g., a CORECONF server).
This document has passed Working Group Last Call (WGLC) already in
2020, but has been in hibernation since, while the other parts of
CORECONF were completed.
With renewed discussion about the "big" YANG library
[I-D.ietf-netconf-yang-library-augmentedby], some fallout can be expected for the constrained
version as well.
(Note that basic resource discovery is already provided in the CoRE
ecosystem by /.well-known/core, the Link format employed there
[RFC6690], as well as the CoRE Resource Directory [RFC9176].)¶
In summary, CORECONF makes the use of YANG models accessible for managing low-resource devices. Beyond this immediate objective, there is a more general discussion about the use of data/interaction modeling languages for IoT in general, not just for network management.¶
For instance, IETF's ASDF WG has specified the Semantic Definition Format (SDF, [I-D.ietf-asdf-sdf]). SDF describes Things in terms of their interaction opportunities ("affordances"), structured into properties, actions, and events, as well as the data models behind these.¶
It is just a convention that YANG is used for modeling network management affordances and SDF for application-level affordances. To potentially cross-pollinate between these techniques, Kiesewalter explored bidirectional automatic translation between SDF and YANG based forms of a data/interaction model [I-D.kiesewalter-asdf-yang-sdf]. To obtain productive interworking between YANG, other relevant modeling techniques, and different fields of application, one discussion that will become necessary is how to consolidate support for the rather different evolution patterns used by network management specifications and application interactions (APIs).¶
CORECONF uses CoAP, which can be protected using DTLS [RFC6347] [RFC9147] or OSCORE [RFC8613] with EDHOC [RFC9528]. While both SNMP [STD62] [STD78] and NETCONF/RESTCONF [STD91] came with elaborate network-management-focused security data models, CORECONF acknowledges that the security models for network management of constrained devices will often need to align with application security models, such as [RFC9200] or the specific security model used in an IoT ecosystem and its approach to commissioning [NORDIC-COMMISSIONING].¶
This document has no IANA actions.¶