CORE Working Group S. Salakrichenan Internet-Draft Afnic Intended status: Standards Track A. Pelov Expires: 2 January 2027 L. Toutain IMT Atlantique 1 July 2026 YANG SID Discovery Using the Domain Name System draft-toutain-core-sid-encoding-00 Abstract CORECONF is an interface for managing YANG-modeled data using CBOR. It replaces verbose YANG schema item identifiers with compact 64-bit integers called Schema Item iDentifiers (SIDs). Interpreting a SID requires two resources: the YANG module definition and the SID dictionary (the .sid file) that maps each integer to the corresponding YANG schema item. Pre-loading every possible YANG module and its SID dictionary is not practical as the set of deployed modules grows; a dynamic discovery mechanism is therefore needed. This document specifies a DNS reverse-lookup mechanism analogous to ip6.arpa that maps a SID to a DNS name under the sid.yt. tree (where "yt" stands for YANG Tracker). Resolving that name returns TXT records pointing to the authoritative repository for the corresponding YANG module. 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 2 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Salakrichenan, et al. Expires 2 January 2027 [Page 1] Internet-Draft SID DNS Discovery July 2026 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Relationship to RFC 9595 . . . . . . . . . . . . . . . . 5 3. SID Encoding in the DNS . . . . . . . . . . . . . . . . . . . 5 3.1. Decimal Representation and Zero-Padding . . . . . . . . . 5 3.2. Digit Reversal . . . . . . . . . . . . . . . . . . . . . 6 3.3. Zone Structure and Delegation . . . . . . . . . . . . . . 7 3.4. TXT Records . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. entry_point . . . . . . . . . . . . . . . . . . . . . 9 3.5. Resolution Procedure . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction CORECONF [RFC9254] is an interface for managing YANG-modeled data using CBOR. It replaces verbose YANG schema item identifiers with compact 64-bit integers called Schema Item iDentifiers (SIDs) [RFC9595]. Interpreting a SID requires two resources: the YANG module definition, and the SID dictionary (the .sid file) that maps each integer to its corresponding YANG schema item (data node, identity, feature, or notification). Pre-loading every possible YANG module and its SID dictionary is not practical as the set of deployed modules grows; a dynamic discovery mechanism is therefore needed. This document describes a reverse-lookup mechanism analogous to ip6.arpa [RFC3596] that maps a SID to a DNS name under the sid.yt. tree. Resolving that name returns TXT records carrying the YANG module name, URI templates, or RDF base URLs pointing to the semantic description of the module. Salakrichenan, et al. Expires 2 January 2027 [Page 2] Internet-Draft SID DNS Discovery July 2026 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Terminology SID: A non-negative 63-bit integer that uniquely identifies a YANG schema item (module, data node, identity, feature) as defined in [RFC9595]. SID name: The owner name produced by encoding a SID as a sequence of DNS labels. A SID name is formed by zero-padding the SID to 20 decimal digits, reversing the digit order so that the least- significant digit becomes the leftmost label, and joining the digits with dots. The result is exactly 20 single-digit labels and is independent of any specific zone. For example, SID 2550 produces the SID name `0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0`. fully qualified SID DNS name: The fully qualified domain name (FQDN) used to query the DNS for information about a given SID. It is formed by appending the applicable zone apex to the SID name. For example, the SID name `0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0` under the zone apex `sid.yt.` yields the fully qualified SID DNS name `0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sid.yt.`. The zone apex may vary depending on the administrative structure, but the SID name component remains constant for a given SID. .sid file: A JSON document that records the mapping between YANG schema items (module, data nodes, identities, features, notifications, and RPCs) and their assigned SID integers for a given YANG module. The format and assignment procedures are defined in [RFC9595]. mega-range: A contiguous block of SIDs of size 10^6 administered by a single organization. For example, the IANA YANG SID mega-range covers SIDs 0 to 999 999. entry-point SID: The lowest SID of a module, assigned to the module node itself. It serves as the canonical identifier for the module in the DNS. zone operator: The organization responsible for managing the DNS zone corresponding to a given SID mega-range. Salakrichenan, et al. Expires 2 January 2027 [Page 3] Internet-Draft SID DNS Discovery July 2026 PEN (Private Enterprise Number): A unique integer assigned by IANA to an organization for use in network management protocols. PENs were originally introduced for identifying organizations in SNMP MIB modules and are maintained in the IANA Private Enterprise Numbers registry [IANA-PEN]. In this document, PENs are used to derive deterministic SID sub-ranges for organizations that wish to deploy YANG modules independently of any SDO. module repository: An entity that supplies YANG module definitions to module users, as defined in [RFC9595]. A module repository may be an official entity (e.g., IANA for IETF modules) or an unofficial entity (e.g., the YANG Catalog). In this document, the URL of the module repository entry for a given SID is carried in the `repository` TXT key, allowing a client to retrieve the YANG module definition after resolving the SID via DNS. Not all module repositories act as permanent records; those that do not MUST reference the module owner as the stable source. SID repository: An entity that supplies SID assignments to SID users, usually in the form of a .sid file, as defined in [RFC9595]. A SID repository is the authoritative source for the mapping between YANG schema items and their assigned SID integers for a given YANG module. In this document, the `repository` TXT key carried in a DNS TXT record points to the SID repository entry for the corresponding module, enabling a client to retrieve the .sid file needed to decode a received SID. The SID repository and the module repository may be the same entity or different entities. collapsed block record: A DNS TXT record whose owner name contains 19 single-digit labels instead of the usual 20, formed by omitting the units-digit label from a SID name. A collapsed block record applies to all ten SIDs in the corresponding decade (i.e., all SIDs sharing the same 19 most-significant digits) and is used as a zone management optimisation to publish a common `entry_point` value for a contiguous block of SIDs belonging to the same YANG module without requiring one TXT record per SID. enrichment record: A DNS TXT record that carries supplementary information about a YANG module beyond what the authoritative repository provides. Enrichment records are additive and never replace or override repository metadata. Examples include pointers to SDF (Semantic Definition Format) files, transformation rules, or RDF mappings that enable integration with non-YANG ecosystems. Unlike the mandatory `status` and `repository` keys, enrichment records are optional and their keys are not defined in this document. Salakrichenan, et al. Expires 2 January 2027 [Page 4] Internet-Draft SID DNS Discovery July 2026 2.1. Relationship to RFC 9595 [RFC9595] defines the YANG Schema Item iDentifier (SID) - a unique integer assigned to each item in a YANG module - and specifies the .sid file format that records the mapping between YANG schema items and their assigned SID integers. [RFC9595] also defines the SID assignment and registration process by which module authors obtain SID ranges from IANA or other registrars. This process produces a static artifact (the .sid file) that is created at module development time and distributed alongside the YANG module. This document addresses a complementary and strictly runtime problem: given a SID integer received in a CORECONF message, how does the receiver dynamically discover which YANG module it belongs to and where to obtain the corresponding .sid file? It specifies a DNS- based reverse-lookup mechanism for this purpose. This document does not define SID values, .sid file formats, or SID assignment procedures; those remain entirely within the scope of [RFC9595]. Conversely, [RFC9595] does not define any discovery mechanism; a receiver that relies solely on [RFC9595] must obtain .sid files through manual configuration or out-of-band means. This document fills that gap. The dependency is strictly one-directional: SIDs MUST be assigned and registered in accordance with [RFC9595] before they can be published in the DNS zone defined by this document. 3. SID Encoding in the DNS 3.1. Decimal Representation and Zero-Padding A YANG SID is a non-negative integer in the range 0 to 2^64 - 1 (= 18 446 744 073 709 551 615). Expressed in base 10, the maximum value requires exactly 20 decimal digits. Every SID MUST therefore be zero-padded on the left to exactly 20 characters before any DNS manipulation. The resulting 20-digit string is the basis for constructing the SID name (Section 2). SID 2550 --> 00000000000000002550 (20 digits) SID 1 --> 00000000000000000001 (20 digits) Decimal notation is deliberately chosen over hexadecimal. SIDs are assigned and communicated as plain decimal integers in the IANA registry [IANA-YANG-SID]. Keeping decimal notation ensures that a DNS name can be verified by inspection against the registry without any base conversion. Salakrichenan, et al. Expires 2 January 2027 [Page 5] Internet-Draft SID DNS Discovery July 2026 The 20-digit padding has a second benefit: it guarantees that every SID name contains exactly the same number of single-digit labels (20 digit labels followed by the zone labels), which simplifies zone delegation arithmetic as described in Section 3.3. 3.2. Digit Reversal Following the same principle as ip6.arpa [RFC3596] for IPv6 addresses, the 20 digits are reversed (least-significant digit first) and each digit becomes one DNS label. The labels are joined with dots to form the SID name. The zone apex is then appended to produce the fully qualified SID DNS name. Example for SID 2550: canonical (20 digits): 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 5 5 0 <-- most significant least --> reversed (SID name): 0 5 5 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 fully qualified SID DNS name: 0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sid.yt. The zone apex sid.yt. has been chosen to deploy a testbed rapidly. The .yt ccTLD (Mayotte) was available and allowed quick experimentation. A dedicated entry under arpa., such as sid.arpa., could be more appropriate for a production deployment, following the precedent set by ip6.arpa. for IPv6 reverse lookups. Without reversal, all SIDs in the same mega-range (e.g., 0 to 999 999) would share a common suffix in DNS. Reversal maps the administratively meaningful high-order digits to the leftmost labels, where DNS delegation cuts can be applied. The following Python snippet illustrates the encoding: def sid_name(sid: int) -> str: digits = f"{sid:020d}" # zero-pad to 20 decimal digits return ".".join(reversed(digits)) def sid_fqdn(sid: int, zone: str) -> str: return sid_name(sid) + f".{zone}." Salakrichenan, et al. Expires 2 January 2027 [Page 6] Internet-Draft SID DNS Discovery July 2026 3.3. Zone Structure and Delegation The DNS tree under sid.yt. mirrors the administrative structure of SID mega-range allocation: sid.yt. | +-- [SDO mega-ranges] | +-- 0 - 999 999 ietf.sid.yt. | +-- 1 000 000 - 1 999 999 sdo2.sid.yt. | +-- ... | +-- [Registrar mega-ranges] | +-- 50 000 000 - 50 999 999 afnic.sid.yt. | +-- ... | +-- [PEN sub-ranges] +-- PEN < 100 000 (5 digits) : | 3 000 000 000 - 3 999 999 999 (10 000 SIDs per PEN) | +-- PEN < 1 000 000 (6 digits) : 300 000 000 000 to 399 999 999 999 (100 000 SIDs per PEN) The root zone sid.yt. is managed by a central authority (Section 2) that delegates sub-zones to the different mega-range administrators using NS records. The owner name of each NS record is the common reversed-digit suffix shared by all SIDs in the corresponding mega- range. The number of fixed labels in the NS owner name equals the number of most-significant digits that are identical across all SIDs in the range when zero-padded to 20 digits. For a mega-range of size 10^6, this is always 14 fixed labels in the fully qualified SID DNS name. The root zone therefore delegates: ; IETF mega-range (SIDs 0 - 999 999) 0.0.0.0.0.0.0.0.0.0.0.0.0.0.sid.yt. IN NS ns1.ietf.yt. ; first SDO mega-range (SIDs 1 000 000 - 1 999 999) 1.0.0.0.0.0.0.0.0.0.0.0.0.0.sid.yt. IN NS ns1.sdo2.yt. Any organization that requests a mega-range from the root authority receives the NS delegation for the corresponding 14-label suffix, and becomes responsible for managing TXT records within its sub-zone. Some companies may wish to deploy YANG modules independently of any SDO. The IANA Private Enterprise Number (PEN) registry [IANA-PEN], originally designed to identify organizations in SNMP MIB modules, Salakrichenan, et al. Expires 2 January 2027 [Page 7] Internet-Draft SID DNS Discovery July 2026 provides a pre-existing namespace for this purpose. Each PEN holder receives a deterministic SID sub-range whose boundaries are derived from the decimal digits of the PEN value, as shown in the table above. However, PEN assignments were made on a first-come-first-served basis with no structural grouping, so there is no administrative hierarchy that maps naturally to a DNS delegation tree. Furthermore, the current registry provides no mechanism to verify that a claimant is the legitimate owner of a given PEN. A dedicated governance entity responsible for managing PEN-based SID allocations and authenticating ownership SHOULD therefore be established before this mechanism is deployed at scale. The two PEN sub-ranges are delegated from sid.yt. to this governance entity as follows: ; PEN < 100 000 (SIDs 3 000 000 000 - 3 999 999 999) 3.0.0.0.0.0.0.0.0.0.0.sid.yt. IN NS ns1.pen-reg.yt. ; PEN < 1 000 000 (SIDs 300 000 000 000 - 399 999 999 999) 3.0.0.0.0.0.0.0.0.sid.yt. IN NS ns1.pen-reg.yt. One can also imagine that some registrars deliver SID ranges directly to their customers, in addition to the PEN mechanism. As an illustrative example, Afnic is assumed to have been allocated the 50 million mega-range (SIDs 50 000 000 to 50 999 999). The corresponding delegation from sid.yt. is: ; Afnic mega-range (SIDs 50 000 000 - 50 999 999) 5.0.0.0.0.0.0.0.0.0.0.0.0.sid.yt. IN NS ns1.afnic.yt. Afnic then sub-delegates portions of this range to its member organizations and manages the associated TXT records on their behalf. 3.4. TXT Records A fundamental property of YANG SIDs is that once a SID has been validated and published, its meaning MUST NOT change. An allocated SID can only be deprecated, never reassigned or redefined. DNS records that publish SID information MUST reflect this immutability: a TXT record set for a given owner name is written once and never modified, except to mark the SID as deprecated. As a consequence, only a minimal set of information is stored in the DNS. Detailed metadata — module name, namespace URI, SID file, contact information — are held in the module repository and SID repository (Section 2) and MUST NOT be duplicated in the DNS as Salakrichenan, et al. Expires 2 January 2027 [Page 8] Internet-Draft SID DNS Discovery July 2026 duplicated data would become inconsistent over time. The role of the DNS is solely to provide a stable, immutable pointer to the authoritative repository. Nevertheless, the DNS MAY carry information that enriches the data model beyond what the authoritative repository provides. For instance, a TXT record may point to an SDF (Semantic Definition Format) file that augments the YANG data model and enables better integration with non-YANG ecosystems. Similarly, TXT records may carry pointers to transformation rules or mappings that allow a YANG object to be converted into another data model representation. Such enrichment records Section 2 are additive: they never replace or override the information held in the authoritative repository. TXT records carry key=value pairs (one pair per TXT RR). The following example shows the records for the entry-point SID 2550: ; Zone: ietf.yt 0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "status=active" 0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "repository=https://yang-catalog.example.org/sid/2550" When a SID is deprecated, only the status value changes; no other field is ever modified. The repository URL SHOULD then point to information about the successor, if one exists. The defined TXT keys are: | Key | Status | Description | |:-------------|:-------|:------------| | status | MUST | active or deprecated | | repository | MUST | URL of the official repository entry for this SID | | entry_point | MUST | Entry-point SID of the module (decimal integer); used to link a non- entry-point SID back to its module | | urn | MAY | Namespace URI of the YANG module (e.g., urn:ietf:params:xml:ns:yang:ietf-schc) | * entry_point MUST be present for all SIDs except the entry-point SID itself, which identifies the module root. 3.4.1. entry_point The entry_point key identifies the lowest SID of the YANG module to which a given SID belongs. It is present in every TXT record set except when the queried SID is itself the entry-point SID (i.e., the SID assigned to the module node itself). Salakrichenan, et al. Expires 2 January 2027 [Page 9] Internet-Draft SID DNS Discovery July 2026 When the queried SID equals the entry_point value, the record describes the module root and the repository key points directly to the module's authoritative entry. When the queried SID differs from the entry_point value, the client MUST follow up with a query on the entry-point SID to obtain the module-level information. ; Zone: ietf.yt ; SID 2550 - entry-point of ietf-schc (no entry_point key: this IS the module root) 0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "status=active" 0.5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "repository=https://yang-catalog.example.org/sid/2550" ; SIDs 2550-2559: complete block, collapsed record {{terminology}} by dropping the first (units) label. ; The 19-label name covers all ten SIDs in the decade. 5.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "entry_point=2550" ; SID 2560: individual record (units digit = 0, tens digit = 6) 0.6.5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN TXT "entry_point=2550" 3.5. Resolution Procedure A gateway receiving a CORECONF message containing a SID resolves it as follows: 1. Compute the SID name for the received SID (Section 3.1. 2. Reverse the digits and join them with dots (Section 3.2). 3. Append the appropriate zone apex sid.yt. to obtain the fully qualified SID DNS name, or use a cached NS referral for the appropriate sub-zone if available. 4. Query the DNS for TXT records at the fully qualified SID DNS name. The response MUST be handled as follows: * If the response is NXDOMAIN, the SID is not registered in the DNS. The resolution MUST be considered failed and the client SHOULD fall back to out-of-band means to obtain the .sid file. * If the response contains neither a repository key nor an entry_point key, the record is malformed. The resolution MUST be considered failed. * If the response contains both a repository key and an entry_point key, the repository key takes precedence and the client proceeds to step 5. Salakrichenan, et al. Expires 2 January 2027 [Page 10] Internet-Draft SID DNS Discovery July 2026 * If the response contains a repository key only, proceed to step 5. * If the response contains an entry_point key only, compute the fully qualified SID DNS name for the entry-point SID value using steps 1-2 and issue a new TXT query for it. The entry_point indirection MUST NOT be followed more than once; if the response to this second query does not contain a repository key, the resolution MUST be considered failed. 5. Dereference the repository URI to retrieve the module repository or SID repository entry (Section 2) for the corresponding YANG module, and obtain the .sid file needed to decode the received SID. 4. Security Considerations DNS responses for SID records SHOULD be protected using DNSSEC [RFC4033] to prevent an attacker from redirecting a gateway to a malicious module description URI. The URI obtained from the repository TXT key MUST be retrieved over HTTPS. Clients MUST validate the server TLS certificate before processing any returned document. Zone operators SHOULD sign SID DNS records using DNSSEC [RFC4033] to prevent an attacker from redirecting a client to a malicious repository URI. Clients SHOULD validate DNSSEC signatures before processing TXT record responses. The immutability of SID assignments provides an additional security property: a TXT record set for a given owner name is written once and never replaced, except to mark the SID as deprecated. This limits the attack surface for record substitution attacks, as no legitimate update operation ever silently replaces an existing record with different content. The security of the entire SID DNS infrastructure depends on the integrity of the sid.yt. root zone. The central authority MUST therefore apply the same security controls required of any DNS registry operator, including strict access controls on NS delegations and DNSSEC signing of the root zone. 5. IANA Considerations This document requests no action from IANA at this time. Salakrichenan, et al. Expires 2 January 2027 [Page 11] Internet-Draft SID DNS Discovery July 2026 Future versions may request registration of the sid.yt. DNS tree and of the TXT key names defined in Section 3.4. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", STD 88, RFC 3596, DOI 10.17487/RFC3596, October 2003, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . 6.2. Informative References [IANA-PEN] IANA, "Private Enterprise Numbers", . [IANA-YANG-SID] IANA, "YANG SID Mega-Range Registry", . Salakrichenan, et al. Expires 2 January 2027 [Page 12] Internet-Draft SID DNS Discovery July 2026 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . Acknowledgements This work is supported by the SCHC chair from Afnic and IMT Atlantique. Authors' Addresses Sandoche Balakrichenan Afnic 7 avenue du 8 mai 1945 78280 Guyancourt France Email: sandoche.balakrichenan@afnic.fr Alexander Pelov IMT Atlantique 2 rue de la Châtaigneraie 35576 Cesson-Sévigné France Email: alexander.pelov@imt-atlantique.fr Laurent Toutain IMT Atlantique 2 rue de la Châtaigneraie 35576 Cesson-Sévigné France Email: laurent.toutain@imt-atlantique.fr Salakrichenan, et al. Expires 2 January 2027 [Page 13]