RFC 9997

YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders

📅 published July 2026, from ietf

YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders ✨

RFC 9997 🎀 Part 1 of 2

Okay bestie, here's the header tea. This is RFC 9997, titled YANG-CBOR: Allocating SID Ranges for Private Enterprise Number (PEN) Holders. It was written by C. Bormann from Universität Bremen TZI, and it's a Standards Track doc, so it's an actual Internet standard 💅. It came out in July 2026, and its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋.

Abstract ✨

YANG-CBOR (RFC 9254, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)") defines YANG Schema Item iDentifiers (YANG SIDs), which are globally unique 63-bit unsigned integers used to identify YANG items. RFC 9595 ("YANG Schema Item iDentifier (YANG SID)") defines ways to allocate these SIDs using IANA registries 🧚.

So this spec takes those SID allocation mechanisms and uses them to hand out ranges of 100 000 SIDs (representation size 64 bits) to each holder of an IANA Private Enterprise Number (PEN) with a value below 1 000 000. Holders of PENs below 100 000 also get ranges of 10 000 SIDs (representation size 32 bits) 🌸.

Status of This Memo ✨

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Info about the current status of this doc, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9997.

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 🔥.

Table of Contents 💜

1.  Introduction
2.  Example: SID Range Allocation for Holder of PEN 32473
3.  Discussion
4.  IANA Considerations
5.  Security Considerations
6.  References
  6.1.  Normative References
  6.2.  Informative References
Acknowledgments
Author's Address

1. Introduction 🌈

Okay so, YANG-CBOR [RFC9254] defines YANG Schema Item iDentifiers (YANG SID), which are globally unique 63-bit unsigned integers used to identify YANG items. Then [RFC9595] shows the ways to allocate these SIDs using IANA registries. Bestie, it's a whole system 😭.

The vibe here is that the spec takes those allocation tricks and hands out ranges of 100 000 SIDs (representation size 64 bits) to each holder of an IANA Private Enterprise Number (PEN) with a value under 1 000 000. PEN holders with values under 100 000 also get 10 000 SIDs each (representation size 32 bits) 🍓.

IANA already set aside a mega-range of 100 billion SIDs (representation size 64 bits) for the SID numbers 300 000 000 000 to 399 999 999 999.

IANA also set aside a mega-range of 1 billion SIDs (representation size 32 bits) for the SID numbers 3 000 000 000 to 3 999 999 999.

PENs get registered in [IANA.enterprise-numbers] through a low-threshold, low-overhead registration process. At the time of writing (about 38 years after the registry was created), around 66 000 PENs are registered. In this document, the registrant for a PEN is called the "PEN holder" 🦋.

This spec makes the following SID ranges available to certain (current or future) PEN holders, to be allocated in a scheme the holder defines:

  • The holder of a PEN ppp ppp (< 1 000 000) can use the SID numbers 3pp ppp p00 000 to 3pp ppp p99 999.
  • The holder of a PEN pp ppp (< 100 000) can also use the smaller SID numbers 3 ppp pp0 000 to 3 ppp pp9 999.

2. Example: SID Range Allocation for Holder of PEN 32473 🎀

[RFC5612] allocated Enterprise Number 32473 "for use in examples in RFCs, books, documentation, and the like". It's the example number, bestie 🙈.

If this Enterprise Number had an actual PEN holder, this spec would give that holder control over these SID ranges:

  • 3*03 247 3*00 000 up to 3*03 247 3*99 999, and
  • 3 *324 73*0 000 up to 3 *324 73*9 999.

(Quick note: the plaintext version of this doc shows * characters around the digits that spell out the PEN. In the other renditions, those digits show up in boldface instead 💅.)

Since Enterprise Number 32473 is meant for documentation, the SIDs in those two ranges are also available for use in documentation. Iconic, right? 👑

3. Discussion 💖

Here's the big picture. This doc assigns two mega-ranges as an extremely-low-threshold (zero-interaction) way for a PEN holder to get a number space for the YANG SIDs in their YANG modules. If an entity that needs that number space doesn't already have a PEN, it can get one through a very low-threshold process. Still, using the values in these mega-ranges isn't always the recommended move for a module author 🧚:

  • In the larger of the two spaces, each SID number needs a representation size of 64 bits ("64-bit SIDs"). (This bigger representation size for the absolute value of the SID matters comparatively little, thanks to the delta-encoding YANG-CBOR uses for SIDs.)
  • For holders of PENs with values under 100 000 in the "Private Enterprise Numbers (PENs)" registry, there's another smaller space of SID numbers that need a representation size of 32 bits ("32-bit SIDs"). By or around 2040, PENs with values under 100 000 will likely be used up. The expectation is that there will be enough chances by then to request SID ranges inside mega-ranges that other registrants already got, so this mechanism is less needed 😭.
  • This document does not define infrastructure for finding the YANG module behind a SID in one of its ranges. Sure, each PEN holder can build that infrastructure, but even then, the problem of how to find it for a given SID is still there. (Search engines might help a little 🔍.) On the flip side, in some cases that relative obscurity is exactly what a PEN holder wants from this mechanism.

If obscurity isn't the goal, one or both of the following approaches are encouraged:

  • The PEN holder can run a public repository where their YANG models live next to the applicable SID files. Setting one up can be easy with a popular git forge such as, at the time of writing, GitHub 💜.
  • Implementations that use PEN-based SIDs can make information easier to find by providing a form of a YANG library [RFC8525], possibly a constrained version [core-yang-library] ✨.

Relying on the PEN registry might theoretically trigger a land grab of PEN assignments by prospective YANG module writers. But PENs have been around for decades (see Section 3.1.4 of [RFC1065], which is still in force with no technical changes as Section 3.1.4 of RFC 1155 [STD16]), and no such land grab has happened for the other allocations that come along with getting a PEN. So the worry is kind of overblown, honestly 🙄.

Part 1 of 2. Part 2 picks up at Section 4 (IANA Considerations) with the Table 1 mega-range details, the Reserved for Documentation ranges, the security stuff, and the References 🦋.

6.1. Normative References 📚

okay bestie, these are the docs you have to have read before this stuff makes sense 🫶

[IANA.enterprise-numbers] IANA, "Private Enterprise Numbers (PENs)", https://www.iana.org/assignments/enterprise-numbers.

[IANA.yang-sid] IANA, "YANG SIDs", https://www.iana.org/assignments/yang-sid.

[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, https://www.rfc-editor.org/info/rfc9254.

[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, https://www.rfc-editor.org/info/rfc9595.

6.2. Informative References 🌸

these ones are the extra-cute background reads. good to know, not strictly required 💅

[core-yang-library] Veillette, M. and I. Petrov, "Constrained YANG Module Library", Work in Progress, Internet-Draft, draft-ietf-core-yang-library-03, 11 January 2021, https://datatracker.ietf.org/doc/html/draft-ietf-core-yang-library-03.

[RFC1065] McCloghrie, K. and M. Rose, "Structure and identification of management information for TCP/IP-based internets", RFC 1065, DOI 10.17487/RFC1065, August 1988, https://www.rfc-editor.org/info/rfc1065.

[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, https://www.rfc-editor.org/info/rfc5612.

[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., and R. Wilton, "YANG Library", RFC 8525, DOI 10.17487/RFC8525, March 2019, https://www.rfc-editor.org/info/rfc8525.

[STD16] Internet Standard 16, https://www.rfc-editor.org/info/std16. At the time of writing, this STD comprises the following:

Acknowledgments 🫶

this doc was inspired by the convo between the authors of [RFC9254] and [RFC9595] about how to handle Rob Wilton's feedback. the group chat that made this happen deserves all the credit 💜

Author's Address ✨

Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
📦 where this page comes from