RFC 8525
YANG Library
RFC 8525: YANG Library ✨
Okay bestie, let's get into it! 🎀 This is RFC 8525, the spec for the YANG Library. It's an IETF Standards Track doc, dated March 2019, and it's ISSN 2070-1721. 💖
It's the Obsoletes: 7895 one, so it replaces RFC 7895 and takes over as the current version. 🦋 The authors are A. Bierman (YumaWorks), M. Bjorklund (Tail-f Systems), J. Schoenwaelder (Jacobs University), K. Watsen (Watsen Networks), and R. Wilton (Cisco Systems). Main character energy, honestly. 👑
Quick note on the title block: the RFC number is 8525, the title is "YANG Library", and it's from the Internet Engineering Task Force (IETF) stream. 🌸
Abstract
Okay so the big idea here is a YANG library that tells you which YANG modules, datastores, and datastore schemas a network management server is using. 🧚 It also has simple caching so clients don't have to keep re-fetching all of this info. It's giving efficiency! 💅
This version is NMDA-friendly (NMDA is the Network Management Datastore Architecture), because it lists every datastore the server supports along with the schema each one uses. Honestly so iconic. ✨
This document obsoletes RFC 7895. 🥀➡️🦋
Status of This Memo
Ngl this section is a bit formal, but the vibe is: this is an Internet Standards Track document. 🎀
It's a product of the IETF, so it represents the IETF community's consensus. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). 💜 More info on Internet Standards is in Section 2 of RFC 7841.
To check the current status, errata, or leave feedback, go to https://www.rfc-editor.org/info/rfc8525. 🔥
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood when it was published. Read those carefully, bestie, because they spell out your rights and restrictions. 📜
If you extract Code Components from this doc, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license. 🫶
Table of Contents
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Objectives ......................................................5
3. YANG Library Data Model .........................................6
4. YANG Library YANG Module ........................................8
5. IANA Considerations ............................................20
6. Security Considerations ........................................21
7. References .....................................................22
7.1. Normative References ......................................22
7.2. Informative References ....................................23
Appendix A. Summary of Changes from RFC 7895 .....................25
Appendix B. Example YANG Library Instance for a Basic Server .....25
Appendix C. Example YANG Library Instance for an Advanced Server .27
Authors' Addresses ................................................321. Introduction 🌸
Okay so there's a real need for a standard way to show which YANG modules [RFC7950], datastores [RFC8342], and datastore schemas [RFC8342] a network management server is using. 💅
This doc defines the YANG module "ietf-yang-library" to provide exactly that. This version is compatible with NMDA [RFC8342]. The previous version, defined in [RFC7895], is not NMDA-compatible, because it assumes every datastore has the exact same schema. That's not necessarily true in NMDA, since dynamic configuration datastores can have their own schema. 😭 Also, the operational state datastore can support non-configurable YANG modules on top of the ones that regular configuration datastores support. Wild, right? 🙈
The old YANG library definitions are still around for backwards-compatibility reasons, but they've been marked deprecated. For backwards compatibility, an NMDA-supporting server SHOULD populate the deprecated "/modules-state" tree in a backwards-compatible way. ✨ The new "/yang-library" tree gets ignored by legacy clients, but it has all the data NMDA-aware clients need (and those clients ignore "/modules-state"). 🦋
The recommended way to fill "/modules-state" is to report the YANG modules with "config true" data nodes that you can configure through conventional configuration datastores, plus the YANG modules with "config false" data nodes that come back through a NETCONF <get> operation or equivalent. 🍓
The YANG library info can be different on every server, and it can change at runtime or across a server reboot. 🧚 If a server speaks multiple network management protocols to reach its datastores, each protocol may have its own conceptual instance of the YANG library. Multi-protocol servers, iykyk. 💜
If a server uses a large number of YANG modules, the YANG library contents can get pretty big. But the contents change super rarely, so clients really need to be able to cache them and easily tell whether the cache is stale. 🫶
1.1. Terminology
Okay so the BCP 14 key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" mean what BCP 14 [RFC2119] [RFC8174] says, but only when they show up in ALL CAPS like here. 🎀
The following terms are defined in [RFC7950]:
- module
- submodule
- data node
This document uses the phrase "implement a module" as defined in Section 5.6.5 of [RFC7950]. 🌈
The following terms are defined in [RFC8342]:
- datastore
- datastore schema
- configuration
- conventional configuration datastore
- operational state
- operational state datastore
- dynamic configuration datastore
- client
- server
The following terms are used within this document:
- YANG library: A collection of YANG modules, submodules, datastores, and datastore schemas used by a server.
- YANG library content identifier: A server-generated identifier of the contents of the YANG library.
Tree diagrams in this document use the notation defined in [RFC8340]. 💖
2. Objectives 🎯
Here's what a client app needs for each YANG module in the library so it can fully use the YANG data modeling language: 👑
- name: The name of the YANG module.
- revision: If defined in the YANG module or submodule, the revision is derived from the most recent revision statement within the module or submodule.
- submodule list: The name and (if defined) revision of each submodule used by the module must be identified.
- feature list: The name of each YANG feature supported by the server must be identified.
- deviation list: The name of each YANG module with deviation statements affecting a given YANG module must be identified.
A client app also needs this for each datastore the server supports: 🌸
- identity: The YANG identity for the datastore.
- schema: The schema (i.e., the set of modules) implemented by the datastore.
To pick one design out of several options for the YANG library data model, these criteria were used: ✨
- The information must be efficient for a client to consume. Since the size of the YANG library can be quite large, it should be possible for clients to cache the YANG library information.
- A dynamic configuration datastore must be able to implement a module or feature that is not implemented in the conventional configuration datastores.
- It must be possible to not implement a module or feature in <operational>, even if it is implemented in some other datastore. This is required for transition purposes; a server that wants to implement <operational> should not have to implement all modules at once. 🦋
- A given module can only be implemented in one revision in all datastores. If a module is implemented in more than one datastore, the same revision is implemented in all these datastores. 💅
- Multiple revisions can be used for import, if import-by revision is used.
- It must be possible to use the YANG library by schema mount [RFC8528]. 🧚
Part 1 of 5 done, bestie! 🌈 More parts coming, so stay tuned. 💜
3. YANG Library Data Model ✨
okay so the "ietf-yang-library" YANG module is the one that tells you everything a server is running: the modules, submodules, datastores, and datastore schemas it supports 💅 All of its data nodes are "config false", which means you can only read them from the operational state datastore. no editing allowed, bestie 🔒
Here's the big picture in Figure 1 🦋
+-----------+
| datastore |
+-----------+
|
| has a
V
+-----------+ +--------+ +------------+
| datastore | union of | module | consists of | modules + |
| schema |----------->| set |--------------->| submodules |
+-----------+ +--------+ +------------+
Figure 1So following the NMDA, every datastore gets an associated datastore schema 🌸 A datastore schema is a union of module sets, and each module set is a collection of modules and submodules, including the ones used for imports. Multiple datastores can point at the same datastore schema, and individual datastore schemas can share module sets too 👑 A super common example is the operational state datastore schema, which is a superset of the schema that regular configuration datastores use. it's giving layers 🧁
Below is the YANG tree diagram for "ietf-yang-library". The deprecated "/modules-state" tree is left out of it 🙈
module: ietf-yang-library
+--ro yang-library
+--ro module-set* [name]
| +--ro name string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro namespace inet:uri
| | +--ro location* inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? revision-identifier
| | | +--ro location* inet:uri
| | +--ro feature* yang:yang-identifier
| | +--ro deviation* -> ../../module/name
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro namespace inet:uri
| +--ro location* inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
+--ro schema* [name]
| +--ro name string
| +--ro module-set* -> ../../module-set/name
+--ro datastore* [name]
| +--ro name ds:datastore-ref
| +--ro schema -> ../../schema/name
+--ro content-id string
notifications:
+---n yang-library-update
+--ro content-id -> /yang-library/content-idThe "/yang-library" container holds the whole YANG library, and it has these child nodes 🎀
/yang-library/module-setholds entries that represent module sets. The list/yang-library/module-set/moduleenumerates the modules in each module set. A module is listed together with its submodules (if it has any), a set of features, and any deviation modules. The list/yang-library/module-set/import-only-modulelists all modules (and their submodules) that are only used for imports. The server gets to decide which module set a module goes into 🫶 This revision of the YANG library doesn't attach any meaning to which module set a module is listed in./yang-library/schemahas an entry for each datastore schema the server supports. All conventional configuration datastores share the same "schema" list entry. A dynamic configuration datastore can use a different datastore schema from the conventional ones, so it might need its own "schema" entry 🌈 A "schema" entry has a leaf-list of references to entries in the "module-set" list, and the schema is the union of all modules in all of those referenced module sets./yang-library/datastorehas one entry per datastore the server supports. Each entry names its datastore schema by referencing an entry in the "schema" list. Every supported conventional configuration datastore gets its own entry, and they all point at the same "schema" list element ⭐/yang-library/content-idis the YANG library content identifier. It's an implementation-specific identifier that represents the current YANG library information on one particular server. The value of this leaf MUST change whenever the information in the YANG library changes. There's no requirement that identical information always produces the same "content-id" value. This is what lets a client fetch all the schema information once, cache it, and only go back for it when this leaf's value has changed 💖 If the value does change, the server also generates a "yang-library-update" notification 🔔
Quick heads-up: the content identifier only has to change when the library changes. It doesn't have to be the same every time the same info shows up, so don't assume it's a hash of the content 🙈
Now, for a NETCONF server that implements the NETCONF extensions to support the NMDA [RFC8526], a change in the YANG library content identifier gives a new value for the :yang-library:1.1 capability defined in [RFC8526] 🦋 So if that server implements NETCONF notifications [RFC5277] and the "netconf-capability-change" notification [RFC6470], then a "netconf-capability-change" notification gets generated every time the YANG library content identifier changes 💜
4. YANG Library YANG Module 🧚
okay now the actual module. "ietf-yang-library" imports definitions from "ietf-yang-types" and "ietf-inet-types", which are defined in [RFC6991], and from "ietf-datastores", which is defined in [RFC8342] 🌸 The module itself is written in YANG version 1.1, but the YANG library can support YANG modules written in any version of YANG, so don't panic if you've got an older one 🍓
<CODE BEGINS> file "ietf-yang-library@2019-01-04.yang"
module ietf-yang-library {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library";
prefix yanglib;
import ietf-yang-types {
prefix yang;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 6991: Common YANG Data Types";
}
import ietf-datastores {
prefix ds;
reference
"RFC 8342: Network Management Datastore Architecture
(NMDA)";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:netconf@ietf.org>
Author: Andy Bierman
<mailto:andy@yumaworks.com>
Author: Martin Bjorklund
<mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
Author: Kent Watsen
<mailto:kent+ietf@watsen.net>
Author: Robert Wilton
<mailto:rwilton@cisco.com>";
description
"This module provides information about the YANG modules,
datastores, and datastore schemas used by a network
management server.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8525; see
the RFC itself for full legal notices.";
revision 2019-01-04 {
description
"Added support for multiple datastores according to the
Network Management Datastore Architecture (NMDA).";
reference
"RFC 8525: YANG Library";
}
revision 2016-04-09 {
description
"Initial revision.";
reference
"RFC 7895: YANG Module Library";
}
/*
* Typedefs
*/
typedef revision-identifier {
type string {
pattern '\d{4}-\d{2}-\d{2}';
}
description
"Represents a specific date in YYYY-MM-DD format.";
}
/*
* Groupings
*/
grouping module-identification-leafs {
description
"Parameters for identifying YANG modules and submodules.";
leaf name {
type yang:yang-identifier;
mandatory true;
description
"The YANG module or submodule name.";
}
leaf revision {
type revision-identifier;
description
"The YANG module or submodule revision date. If no revision
statement is present in the YANG module or submodule, this
leaf is not instantiated.";
}
}
grouping location-leaf-list {
description
"Common leaf-list parameter for the locations of modules and
submodules.";
leaf-list location {
type inet:uri;
description
"Contains a URL that represents the YANG schema
resource for this module or submodule.
This leaf will only be present if there is a URL
available for retrieval of the schema for this entry.";
}
}
grouping module-implementation-parameters {
description
"Parameters for describing the implementation of a module.";
leaf-list feature {
type yang:yang-identifier;
description
"List of all YANG feature names from this module that are
supported by the server, regardless whether they are defined
in the module or any included submodule.";
}
leaf-list deviation {
type leafref {
path "../../module/name";
}
description
"List of all YANG deviation modules used by this server to
modify the conformance of the module associated with this
entry. Note that the same module can be used for deviations
for multiple modules, so the same entry MAY appear within
multiple 'module' entries.
This reference MUST NOT (directly or indirectly)
refer to the module being deviated.
Robust clients may want to make sure that they handle a
situation where a module deviates itself (directly or
indirectly) gracefully.";
}
}okay so this is where the module sets come in and it's lowkey the most iconic part of the whole YANG library 🎀✨ here's the next chunk, straight from the source
grouping module-set-parameters {
description
"A set of parameters that describe a module set.";
leaf name {
type string;
description
"An arbitrary name of the module set.";
}
list module {
key "name";
description
"An entry in this list represents a module implemented by the
server, as per Section 5.6.5 of RFC 7950, with a particular
set of supported features and deviations.";
reference
"RFC 7950: The YANG 1.1 Data Modeling Language";
uses module-identification-leafs;
leaf namespace {
type inet:uri;
mandatory true;
description
"The XML namespace identifier for this module.";
}
uses location-leaf-list;
list submodule {
key "name";
description
"Each entry represents one submodule within the
parent module.";
uses module-identification-leafs;
uses location-leaf-list;
}
uses module-implementation-parameters;
}
list import-only-module {
key "name revision";
description
"An entry in this list indicates that the server imports
reusable definitions from the specified revision of the
module but does not implement any protocol-accessible
objects from this revision.
Multiple entries for the same module name MAY exist. This
can occur if multiple modules import the same module but
specify different revision dates in the import statements.";
leaf name {
type yang:yang-identifier;
description
"The YANG module name.";
}
leaf revision {
type union {
type revision-identifier;
type string {
length "0";
}
}
description
"The YANG module revision date.
A zero-length string is used if no revision statement
is present in the YANG module.";
}
leaf namespace {
type inet:uri;
mandatory true;
description
"The XML namespace identifier for this module.";
}
uses location-leaf-list;
list submodule {
key "name";
description
"Each entry represents one submodule within the
parent module.";
uses module-identification-leafs;
uses location-leaf-list;
}
}
}
grouping yang-library-parameters {
description
"The YANG library data structure is represented as a grouping
so it can be reused in configuration or another monitoring
data structure.";
list module-set {
key "name";
description
"A set of modules that may be used by one or more schemas.
A module set does not have to be referentially complete,
i.e., it may define modules that contain import statements
for other modules not included in the module set.";
uses module-set-parameters;
}
list schema {
key "name";
description
"A datastore schema that may be used by one or more
datastores.
The schema must be valid and referentially complete, i.e.,
it must contain modules to satisfy all used import
statements for all modules specified in the schema.";
leaf name {
type string;
description
"An arbitrary name of the schema.";
}
leaf-list module-set {
type leafref {
path "../../module-set/name";
}
description
"A set of module-sets that are included in this schema.
If a non-import-only module appears in multiple module
sets, then the module revision and the associated features
and deviations must be identical.";
}
}
list datastore {
key "name";
description
"A datastore supported by this server.
Each datastore indicates which schema it supports.
The server MUST instantiate one entry in this list per
specific datastore it supports.
Each datastore entry with the same datastore schema SHOULD
reference the same schema.";
leaf name {
type ds:datastore-ref;
description
"The identity of the datastore.";
}
leaf schema {
type leafref {
path "../../schema/name";
}
mandatory true;
description
"A reference to the schema supported by this datastore.
All non-import-only modules of the schema are implemented
with their associated features and deviations.";
}
}
}
/*
* Top-level container
*/
container yang-library {
config false;
description
"Container holding the entire YANG library of this server.";
uses yang-library-parameters;
leaf content-id {
type string;
mandatory true;
description
"A server-generated identifier of the contents of the
'/yang-library' tree. The server MUST change the value of
this leaf if the information represented by the
'/yang-library' tree, except '/yang-library/content-id', has
changed.";
}
}
/*
* Notifications
*/
notification yang-library-update {
description
"Generated when any YANG library information on the
server has changed.";
leaf content-id {
type leafref {
path "/yanglib:yang-library/yanglib:content-id";
}
mandatory true;
description
"Contains the YANG library content identifier for the updated
YANG library at the time the notification is generated.";
}
}
/*
* Legacy groupings
*/
grouping module-list {
status deprecated;
description
"The module data structure is represented as a grouping
so it can be reused in configuration or another monitoring
data structure.";
grouping common-leafs {
status deprecated;
description
"Common parameters for YANG modules and submodules.";
leaf name {
type yang:yang-identifier;
status deprecated;
description
"The YANG module or submodule name.";
}
leaf revision {
type union {
type revision-identifier;
type string {
length "0";
}
}
status deprecated;
description
"The YANG module or submodule revision date.
A zero-length string is used if no revision statement
is present in the YANG module or submodule.";
}
}
grouping schema-leaf {
status deprecated;
description
"Common schema leaf parameter for modules and submodules.";
leaf schema {
type inet:uri;
description
"Contains a URL that represents the YANG schema
resource for this module or submodule.
This leaf will only be present if there is a URL
available for retrieval of the schema for this entry.";
}
}
list module {
key "name revision";
status deprecated;
description
"Each entry represents one revision of one module
currently supported by the server.";
uses common-leafs {
status deprecated;
}
uses schema-leaf {
status deprecated;
}
leaf namespace {
type inet:uri;
mandatory true;
status deprecated;
description
"The XML namespace identifier for this module.";
}
leaf-list feature {
type yang:yang-identifier;
status deprecated;
description
"List of YANG feature names from this module that are
supported by the server, regardless of whether they are
defined in the module or any included submodule.";
}
list deviation {
key "name revision";
status deprecated;
description
"List of YANG deviation module names and revisions
used by this server to modify the conformance of
the module associated with this entry. Note that
the same module can be used for deviations for
multiple modules, so the same entry MAY appear
within multiple 'module' entries.
The deviation module MUST be present in the 'module'
list, with the same name and revision values.
The 'conformance-type' value will be 'implement' for
the deviation module.";
uses common-leafs {
status deprecated;
}
}
leaf conformance-type {
type enumeration {
enum implement {
description
"Indicates that the server implements one or more
protocol-accessible objects defined in the YANG module
identified in this entry. This includes deviation
statements defined in the module.
For YANG version 1.1 modules, there is at most one
'module' entry with conformance type 'implement' for a
particular module name, since YANG 1.1 requires that
at most one revision of a module is implemented.
For YANG version 1 modules, there SHOULD NOT be more
than one 'module' entry for a particular module
name.";
}
enum import {
description
"Indicates that the server imports reusable definitions
from the specified revision of the module but does
not implement any protocol-accessible objects from
this revision.
Multiple 'module' entries for the same module name MAY
exist. This can occur if multiple modules import the
same module but specify different revision dates in
the import statements.";
}
}
mandatory true;
status deprecated;
description
"Indicates the type of conformance the server is claiming
for the YANG module identified by this entry.";
}
list submodule {
key "name revision";
status deprecated;
description
"Each entry represents one submodule within the
parent module.";
uses common-leafs {
status deprecated;
}
uses schema-leaf {
status deprecated;
}
}
}
}
/*
* Legacy operational state data nodes
*/ container modules-state {
config false;
status deprecated;
description
"Contains YANG module monitoring information.";
leaf module-set-id {
type string;
mandatory true;
status deprecated;
description
"Contains a server-specific identifier representing
the current set of modules and submodules. The
server MUST change the value of this leaf if the
information represented by the 'module' list instances
has changed.";
}
uses module-list {
status deprecated;
}
}
/*
* Legacy notifications
*/
notification yang-library-change {
status deprecated;
description
"Generated when the set of modules and submodules supported
by the server has changed.";
leaf module-set-id {
type leafref {
path "/yanglib:modules-state/yanglib:module-set-id";
}
mandatory true;
status deprecated;
description
"Contains the module-set-id value representing the
set of modules and submodules supported at the server
at the time the notification is generated.";
}
}
}
<CODE ENDS>5. IANA Considerations 📋
okay so IANA gets a little housekeeping here 🧹✨ RFC 7895 already registered one URI in the "IETF XML Registry" [RFC3688], and this document takes over that entry 💅 It also changes the Registrant Contact over to the IESG, following Section 4 of [RFC3688] 🫶
URI: urn:ietf:params:xml:ns:yang:ietf-yang-library
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.And there's a second registration, this time for a YANG module in the "YANG Module Names" registry [RFC6020] 🦋
name: ietf-yang-library
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library
prefix: yanglib
reference: RFC 85256. Security Considerations 🔐
bestie, this section is serious 🚨 The YANG module in this document is a schema for data that's meant to be reached through network management protocols like NETCONF [RFC6241] or RESTCONF [RFC8040] 💻 On NETCONF, the lowest layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242] 🔒 On RESTCONF, the lowest layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446] 🛡️
The Network Configuration Access Control Model (NACM) [RFC8341] is the bouncer here 🚪💅 It lets you restrict particular NETCONF or RESTCONF users to a preset subset of the protocol operations and content available to them 🎀
Some of the readable data nodes in this module may be sensitive or vulnerable depending on the network environment 👀 So it's really important to control read access (for example, via get, get-config, or notification) to these data nodes 🙈 Here are the subtrees and data nodes, plus how sensitive or vulnerable they are:
The/yang-librarysubtree can help an attacker figure out a server's capabilities and any implementations with known bugs 💀 The set of YANG modules a server supports can reveal the kind of device and who made it 🏭 Some of this is already visible to every NETCONF user through the NETCONF<hello>message (or similar messages in other management protocols), but this module can expose extra details that could help an attacker 😬
Server vulnerabilities can be tied to particular modules, module revisions, module features, or even module deviations 🧩 For example, if a certain operation on a certain data node is known to crash a server or badly degrade the device's performance, then the module list information can help an attacker find server implementations with that defect and launch a denial-of-service attack on the device 📉💔
7. References 📚
7.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/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)",
RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[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/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.7.2. Informative References 🧚
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<https://www.rfc-editor.org/info/rfc5277>.
[RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
February 2012, <https://www.rfc-editor.org/info/rfc6470>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<https://www.rfc-editor.org/info/rfc7895>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
YANG Data Model for Hardware Management", RFC 8348,
DOI 10.17487/RFC8348, March 2018,
<https://www.rfc-editor.org/info/rfc8348>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "NETCONF Extensions to Support the Network
Management Datastore Architecture", RFC 8526,
DOI 10.17487/RFC8526, March 2019,
<https://www.rfc-editor.org/info/rfc8526>.
[RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount",
RFC 8528, DOI 10.17487/RFC8528, March 2019,
<https://www.rfc-editor.org/info/rfc8528>.Appendix A. Summary of Changes from RFC 7895 🦋
this doc is basically a glow-up of [RFC7895] 💖 Here's everything that changed:
- Renamed the document title from "YANG Module Library" to "YANG Library" ✨
- Added a brand-new top-level
/yang-librarycontainer to hold the entire YANG library, covering module sets, schemas, and datastores 🎀 - Refactored the
/modules-statecontainer into a new/yang-library/module-setlist 🌸 - Added a new
/yang-library/schemalist and a new/yang-library/datastorelist 🧚 - Added a set of new groupings as replacements for the deprecated groupings 🔥
- Added a
yang-library-updatenotification as a replacement for the deprecatedyang-library-changenotification 🫶 - Deprecated the
/modules-statetree 🥀 - Deprecated the
/module-listgrouping 💀 - Deprecated the
/yang-library-changenotification 😭
Okay bestie, picking up right where we left off 💖 This is the last stretch, and it's all about the example YANG library instances, which are basically the cutest little "here's what a real server looks like" showcases 🦋
Appendix B. Example YANG Library Instance for a Basic Server ✨
B. Basic Server Example 🌸
Okay so this example shows the YANG library of a basic server that's running the "ietf-interfaces" [RFC8343] and "ietf-ip" [RFC8344] modules in the <running>, <startup>, and <operational> datastores, plus the "ietf-hardware" [RFC8348] module in the <operational> datastore. Iconic setup, honestly 💅
Quick heads up: newline characters in leaf values were added just so it's easier to read. Not a big deal, just a formatting thing 🎀
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<module-set>
<name>config-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace>
</module>
<module>
<name>ietf-ip</name>
<revision>2018-02-22</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-ip
</namespace>
</module>
<import-only-module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
</import-only-module>
<import-only-module>
<name>ietf-inet-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-inet-types
</namespace>
</import-only-module>
</module-set>
<module-set>
<name>state-modules</name>
<module>
<name>ietf-hardware</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-hardware
</namespace>
</module>
<import-only-module>
<name>ietf-inet-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-inet-types
</namespace>
</import-only-module>
<import-only-module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
</import-only-module>
<import-only-module>
<name>iana-hardware</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:iana-hardware
</namespace>
</import-only-module>
</module-set>
<schema>
<name>config-schema</name>
<module-set>config-modules</module-set>
</schema>
<schema>
<name>state-schema</name>
<module-set>config-modules</module-set>
<module-set>state-modules</module-set>
</schema>
<datastore>
<name>ds:startup</name>
<schema>config-schema</schema>
</datastore>
<datastore>
<name>ds:running</name>
<schema>config-schema</schema>
</datastore>
<datastore>
<name>ds:operational</name>
<schema>state-schema</schema>
</datastore>
<content-id>75a43df9bd56b92aacc156a2958fbe12312fb285</content-id>
</yang-library>Appendix C. Example YANG Library Instance for an Advanced Server 🧚
C. Advanced Server Example 👑
This one is the glow-up version 🌈 It extends the Appendix B example by using modules from [RFC8345] and [RFC8349] to show a slightly more advanced server that:
- Has a module with features that are only enabled in <operational>. The "ietf-routing" module is supported in <running>, <startup>, and <operational>, but the "multiple-ribs" and "router-id" features are only enabled in <operational>. So the "router-id" leaf may be read but not configured. Main character energy 🫶
- Supports a dynamic configuration datastore "example-ds-ephemeral", with only the "ietf-network" and "ietf-network-topology" modules configurable via a notional dynamic configuration protocol ✨
- Shows an example of datastore-specific deviations. The "example-vendor-hardware-deviations" module is included in the schema for <operational> to remove data nodes that the server can't support 🙈
- Shows how module-sets can be used to organize related modules together 🗂️
Same deal as before: newline characters in leaf values are only there for formatting reasons 🎀
<yang-library
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
xmlns:ex-ds-eph="urn:example:ds-ephemeral">
<module-set>
<name>config-state-modules</name>
<module>
<name>ietf-interfaces</name>
<revision>2018-02-20</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-interfaces
</namespace>
</module>
<module>
<name>ietf-ip</name>
<revision>2018-02-22</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-ip
</namespace>
</module>
<module>
<name>ietf-routing</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-routing
</namespace>
</module>
<import-only-module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
</import-only-module>
<import-only-module>
<name>ietf-inet-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-inet-types
</namespace>
</import-only-module>
</module-set>
<module-set>
<name>config-only-modules</name>
<module>
<name>ietf-routing</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-routing
</namespace>
</module>
</module-set>
<module-set>
<name>dynamic-config-state-modules</name>
<module>
<name>ietf-network</name>
<revision>2018-02-26</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-network
</namespace>
</module>
<module>
<name>ietf-network-topology</name>
<revision>2018-02-26</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-network-topology
</namespace>
</module>
<import-only-module>
<name>ietf-inet-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-inet-types
</namespace>
</import-only-module>
</module-set>
<module-set>
<name>state-only-modules</name>
<module>
<name>ietf-hardware</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-hardware
</namespace>
<deviation>example-vendor-hardware-deviations</deviation>
</module>
<module>
<name>ietf-routing</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-routing
</namespace>
<feature>multiple-ribs</feature>
<feature>router-id</feature>
</module>
<module>
<name>example-vendor-hardware-deviations</name>
<revision>2018-01-31</revision>
<namespace>
urn:example:example-vendor-hardware-deviations
</namespace>
</module>
<import-only-module>
<name>ietf-inet-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-inet-types
</namespace>
</import-only-module>
<import-only-module>
<name>ietf-yang-types</name>
<revision>2013-07-15</revision>
<namespace>
urn:ietf:params:xml:ns:yang:ietf-yang-types
</namespace>
</import-only-module>
<import-only-module>
<name>iana-hardware</name>
<revision>2018-03-13</revision>
<namespace>
urn:ietf:params:xml:ns:yang:iana-hardware
</namespace>
</import-only-module>
</module-set>
<schema>
<name>config-schema</name>
<module-set>config-state-modules</module-set>
<module-set>config-only-modules</module-set>
</schema>
<schema>
<name>dynamic-config-schema</name>
<module-set>dynamic-config-state-modules</module-set>
</schema>
<schema>
<name>state-schema</name>
<module-set>config-state-modules</module-set>
<module-set>dynamic-config-state-modules</module-set>
<module-set>state-only-modules</module-set>
</schema>
<datastore>
<name>ds:startup</name>
<schema>config-schema</schema>
</datastore>
<datastore>
<name>ds:running</name>
<schema>config-schema</schema>
</datastore>
<datastore>
<name>ex-ds-eph:ds-ephemeral</name>
<schema>dynamic-config-schema</schema>
</datastore>
<datastore>
<name>ds:operational</name>
<schema>state-schema</schema>
</datastore>
<content-id>14782ab9bd56b92aacc156a2958fbe12312fb285</content-id>
</yang-library>Authors' Addresses 💌
Andy Bierman YumaWorks
Email: andy@yumaworks.com
Martin Bjorklund Tail-f Systems
Email: mbj@tail-f.com
Juergen Schoenwaelder Jacobs University
Email: j.schoenwaelder@jacobs-university.de
Kent Watsen Watsen Networks
Email: kent+ietf@watsen.net
Robert Wilton Cisco Systems
Email: rwilton@cisco.com
That's the whole thing, bestie 🦋✨ Every example, every module, every address, all there. Periodt 💜
📦 where this page comes from
- ietf: rfc8525 2019-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms