]> Afnic

7 avenue du 8 mai 1945 Guyancourt 78280 France sandoche.balakrichenan@afnic.fr

IMT Atlantique

2 rue de la Châtaigneraie Cesson-Sévigné 35576 France alexander.pelov@imt-atlantique.fr

IMT Atlantique

2 rue de la Châtaigneraie Cesson-Sévigné 35576 France laurent.toutain@imt-atlantique.fr

Internet CORE Working Group YANG SID DNS CoRECONF IoT CBOR 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.

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

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 when, and only when, they appear in all capitals, as shown here.

Terminology

SID:

A non-negative 63-bit integer that uniquely identifies a YANG schema item (module, data node, identity, feature) as defined in .

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 .

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.

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

Relationship to RFC 9595 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. 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 . Conversely, does not define any discovery mechanism; a receiver that relies solely on 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 before they can be published in the DNS zone defined by this document.

SID Encoding in the DNS

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 (). 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 . Keeping decimal notation ensures that a DNS name can be verified by inspection against the registry without any base conversion. 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 .

Digit Reversal Following the same principle as ip6.arpa 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: 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: 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}." ]]>

Zone Structure and Delegation The DNS tree under sid.yt. mirrors the administrative structure of SID mega-range allocation: The root zone sid.yt. is managed by a central authority () 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: 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 , originally designed to identify organizations in SNMP MIB modules, 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: 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 then sub-delegates portions of this range to its member organizations and manages the associated TXT records on their behalf.

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 () and MUST NOT be duplicated in the DNS as 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 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: 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.

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

Resolution Procedure A gateway receiving a CORECONF message containing a SID resolves it as follows:

1. Compute the SID name for the received SID (.
2. Reverse the digits and join them with dots ().
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.
   • 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 () for the corresponding YANG module, and obtain the .sid file needed to decode the received SID.

Security Considerations DNS responses for SID records SHOULD be protected using DNSSEC 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 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.

IANA Considerations This document requests no action from IANA at this time. Future versions may request registration of the sid.yt. DNS tree and of the TXT key names defined in .

References Normative References This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK] The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). YANG Schema Item iDentifiers (YANG SIDs) are globally unique 63-bit unsigned integers used to identify YANG items. SIDs provide a more compact method for identifying those YANG items that can be used efficiently, notably in constrained environments (RFC 7228). This document defines the semantics, registration processes, and assignment processes for YANG SIDs for IETF-managed YANG modules. To enable the implementation of these processes, this document also defines a file format used to persist and publish assigned YANG SIDs. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References A URI Template is a compact sequence of characters for describing a range of Uniform Resource Identifiers through variable expansion. This specification defines the URI Template syntax and the process for expanding a URI Template into a URI reference, along with guidelines for the use of URI Templates on the Internet. [STANDARDS-TRACK] IANA IANA

Acknowledgements This work is supported by the SCHC chair from Afnic and IMT Atlantique.