YANG Schema Item iDentifier (YANG SID)
Extracted elements (27)
If the YANG data type changes in a new revision of a published module such that the resulting CBOR encoding changes, implementations will be aided significantly if a new SID is assigned. SID reassignment on type change is not required but strongly recommended for CBOR compatibility.
SIDs are assigned sequentially in alphabetical order to minimize serialization overhead, particularly when the delta between a reference SID and the current SID is used by protocols (such as YANG-CBOR) to reduce message size. Locality of assignment enables efficient use of the SID delta mechanism.
SIDs are encoded as 63-bit unsigned integers rather than 64-bit to allow easier manipulation on platforms that might lack 64-bit unsigned arithmetic. The loss of a single bit of range is not significant given the size of the remaining space.
Early Allocation (BCP 100) is the expected mechanism for most IETF documents to obtain stable SID values before RFC publication, since changing SID values during IETF document processing is difficult. Experimental SID ranges may be used prior to working group adoption.
If another '.sid' file has already allocated SIDs for a YANG module (e.g., for older or newer versions), YANG items MUST be assigned the same SIDs as in the other '.sid' file. All SIDs from an older version of a '.sid' file must still be present in the current version.
A published '.sid' file MUST NOT contain SID assignments with a status of 'unstable'. When sid-file-status is 'published', the item list MUST NOT contain entries with status 'unstable'.
All SIDs present in a previous version of a '.sid' file that was in active use MUST be present in the new version as well. When a new revision requires more SIDs than initially allocated, a new SID range MUST be added to the 'assignment-range' item.
Any 63-bit unsigned integer either (1) is unassigned as a SID or (2) immutably maps to EXACTLY one YANG name. Only the transition from unassigned to that immutable mapping is defined (Objective 1, MUST).
Once a module is declared stable, its SID assignments SHOULD be declared stable as well. SID status can only transition from 'unstable' to 'stable', and possibly from 'stable' to 'obsolete'.
RPC or action 'input' and 'output' YANG items MUST always be assigned SIDs even if they don't contain further YANG items, because other modules can augment the given module and those SIDs might be necessary.
SID assignment SHOULD be automated. The recommended process sorts items alphabetically (namespace descending, identifier ascending) then assigns SIDs sequentially from the entry point to minimize serialization overhead when using the SID delta mechanism.
The creation of a new version of the '.sid' file SHOULD be performed using an automated tool.
The experimental SID range (60,000 to 99,999) MUST NOT be used in operational deployments, since these SIDs are not globally unique and their interoperability is therefore limited.
The 'item' list MUST include a mapping entry for each YANG item defined by the YANG module. The YANG-SID ranges specified by all 'assignment-range' entries MUST NOT overlap.
The '.sid' file MUST NOT be published as part of the RFC: the IANA registry is authoritative, and a link to it is to be inserted in the RFC.
The SID management system MUST be independent of any module versioning (Objective 3). This ensures SID assignments remain stable across YANG module revisions.
A '.sid' file is a JSON-encoded file (per RFC 7951 rules) defined by the 'ietf-sid-file' YANG module. It contains: module-name (mandatory), module-revision, sid-file-version, sid-file-status (unpublished/published), dependency-revision list, assignment-range list (entry-point + size), and item list mapping namespace+identifier to SID values.
A YANG SID (YANG Schema Item iDentifier) is a globally unique 63-bit unsigned integer used to identify YANG items including identities, data nodes, RPCs, actions, notifications, YANG modules, and features. The limitation to 63 bits (uint64 range 0..9223372036854775807) allows easier manipulation on platforms lacking 64-bit unsigned arithmetic.
The 'item' list in a '.sid' file maps YANG items to SIDs using three fields: namespace (enumeration: module=0, identity=1, feature=2, data=3), identifier (yang-identifier or schema-node-path), and sid (mandatory). The list key is namespace+identifier with a uniqueness constraint on sid.
The 'sid-file-version' leaf (uint32, default 0) distinguishes updates to a '.sid' file for a given YANG module revision, such as updates from new processing or errata. Version numbering starts at 0 for each new YANG module revision and increases monotonically.
New IANA registry 'IETF YANG-SID Modules' records individual SID allocations per YANG module. Each entry contains the module name, URI for the .yang file, URI for the .sid file (stored by IANA), and count of allocated SIDs. Allocation policy is Expert Review; all SIDs in the .sid file MUST be within ranges allocated in 'IETF YANG-SID Ranges'.
New IANA registry 'IETF YANG-SID Ranges' records SID range assignments to YANG modules. The first million SIDs are subdivided: 0-999 (IESG Approval), 1,000-59,999 and 100,000-299,999 (RFC + Expert Review for IETF modules), 60,000-99,999 (Experimental Use, MUST NOT be used in operational deployments), 300,000-999,999 (Reserved). SID range size SHOULD be a multiple of 50 and at least 33% above current item count.
New IANA registry 'YANG-SID Mega-Ranges' records delegation of SID block management to third parties (SDOs or registrars). Each entry contains entry-point, block size (SHOULD be 1,000,000 SIDs), allocation policy (Public/Private/both), and organization contact. Allocation policy is Expert Review. Initial entry: IANA, entry-point 0, size 1,000,000, Public.
New media type 'application/yang-sid+json' registered in the IANA Media Types registry. File extension is '.sid', encoding is binary (UTF-8). Also registers CoAP Content-Format ID 260 in the CoRE Parameters registry.
'.sid' files may employ dereferenceable identifiers that could cause implementations to automatically perform remote access. This gives an attacker potential information from or control over such accesses, with security and privacy implications.
SIDs map semantic concepts to integers; if the source of the mapping is not trusted, an attacker who can control the mapping introduces new security risks. Developers and systems processing '.sid' files are advised to only import them from authoritative sources — IANA is the authoritative source for IETF-managed YANG modules. Systems such as network management systems must take extra care to ensure they process '.sid' files only from appropriately authoritative sources.
The 'sid' typedef is defined as uint64 with range 0..9223372036854775807, representing a 63-bit unsigned integer. SID value 0 is reserved to internally signify the absence of a SID number and MUST NOT occur in interchange.