Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

YANG SID Discovery Using the Domain Name System
draft-toutain-core-sid-encoding-00

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Authors	Sandoche Balakrichenan , Alexander Pelov , Laurent Toutain
	Last updated	2026-07-01
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	On agenda	core at IETF-126
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Nits v3 Search email archive

draft-toutain-core-sid-encoding-00

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.

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:

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

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

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

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[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/rfc/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/rfc/rfc9595>.

6.2. Informative References

[IANA-PEN] IANA, "Private Enterprise Numbers",
<https://www.iana.org/assignments/enterprise-numbers>.

[IANA-YANG-SID]
IANA, "YANG SID Mega-Range Registry",
<https://www.iana.org/assignments/yang-sid/yang-
sid.xhtml>.

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

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]

YANG SID Discovery Using the Domain Name System draft-toutain-core-sid-encoding-00

YANG SID Discovery Using the Domain Name System
draft-toutain-core-sid-encoding-00