YANG Module Tags
updates
- rfc-8407 — Guidelines for Authors and Reviewers of Documents Containing YANG Data Models
Extracted elements (22)
Tags were chosen over a rigid classification structure because they are more flexible and can more easily adapt over time as technologies evolve, analogous to '#hashtags' widely used on the internet.
The document intentionally does not impose structure on tag values beyond the registered prefix, in order to avoid arbitrarily restricting what designers, implementers, and users can express with tags.
A non-NMDA state module ('ietf-module-tags-state') is provided for implementations that do not yet support the Network Management Datastore Architecture (NMDA); its container and list are marked deprecated.
This document updates RFC 8407 (Guidelines for Authors and Reviewers of YANG Data Models) by adding Section 6 guidance requiring that standard module-tag extension usage for IETF modules reference registered IANA tags.
All tags SHOULD begin with a prefix indicating who owns their definition, using prefixes registered in the IANA 'YANG Module Tag Prefixes' registry.
For IETF standardized modules, new tags used in module-tag extension statements MUST be assigned in the IANA 'IETF YANG Module Tags' registry.
IANA-assigned tags in the 'IETF YANG Module Tags' registry must conform to Net-Unicode as defined in RFC 5198 and shall not need normalization.
If a module is defined in an IETF Standards Track document, any design-time tags indicated using the module-tag extension MUST be IETF tags (i.e., registered with IANA).
Implementation-time tags added by an implementation SHOULD be IETF tags (registered) or vendor-specific tags.
Tag values may contain any YANG type 'string' characters except carriage returns, newlines, and tabs.
Any tag not starting with 'ietf:', 'vendor:', or 'user:' is reserved for future use; such tags are not invalid but reserved in the context of specifications.
IETF tags have the prefix 'ietf:' and must all be registered with IANA in the 'IETF YANG Module Tags' registry defined in Section 7.2.
The 'ietf-module-tags' YANG module defines a 'module-tags' container with a 'module' list keyed by name, each entry having 'tag' and 'masked-tag' leaf-lists of type 'tag'.
The 'module-tag' extension statement takes a 'tag' argument and is used by module authors to indicate tags that SHOULD be added automatically by the system with origin set to 'system' per RFC 8342.
The operational state view of the tag list is constructed by: (1) adding system tags, (2) adding user-configured tags, (3) removing any tag equal to a masked-tag entry.
To remove a tag from the operational datastore, a user adds a matching 'masked-tag' entry for the given module in the ietf-module-tags configuration.
User tags have the prefix 'user:' and are defined by the user/administrator without registration. Using the 'user:' prefix is RECOMMENDED to help avoid collisions.
Vendor tags have the prefix 'vendor:' and are defined by the module implementer without registration. It is RECOMMENDED that vendors include extra identification (e.g., enterprise name) after the prefix to avoid collisions.
IANA created the 'IETF YANG Module Tags' subregistry within the 'YANG Module Tags' registry, with allocation policy IETF Review. Initial tags include ietf:network-element-class, ietf:network-service-class, ietf:sdo-defined-class, ietf:vendor-defined-class, ietf:user-defined-class, ietf:hardware, ietf:software, ietf:protocol, ietf:qos, ietf:network-service-app, ietf:system-management, ietf:oam, ietf:routing, ietf:security, ietf:signaling, and ietf:link-management.
IANA created the 'YANG Module Tag Prefixes' subregistry within the 'YANG Module Tags' registry, with allocation policy Specification Required (RFC 8126). Initial entries: 'ietf:', 'vendor:', and 'user:'.
The ietf-module-tags module is designed to be accessed via NETCONF over a secure transport (mandatory-to-implement: SSH). The document itself does not define any actions based on tag associations and therefore does not directly introduce new security considerations.
Users who define actions based on tag metadata must consider the security implications of those actions, including the potential for a tag to be 'masked' by another user.